Quantcast FFmpeg vs FFvfw vs Mencoder ? - Page 11 - digitalFAQ.com Forums [Archives]
  #201  
03-02-2004, 09:52 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Minimum syntax for DVD compatibility, simplified

Quote:
SIMPLE BATCH FILE WITH VARIABLE PARAMETERS
=================================
mencoder -include settings.ini -lavcopts vrc_eq=tex:vbitrate=9800:keyint=18 movie.vob -o movie.mpg

bbdmux movie.mpg 0xe0 movie.m2v

SETTINGS.INI
=========
of=mpeg=1
ovc=lavc=1
noskip=1
nosound=1
lavcopts=vcodec=mpeg2video:ildct=1:ilme=1:vstrict=-1:
vqblur=0:vrc_minrate=300:vrc_maxrate=9800:vrc_buf_ size=1835:autoaspect=1
This will be a simple to use command line, quality settings should be put on settings.ini (they're not set in this example), supports fractional framerates and interlaced encodes, and has all the needed parameters for DVD compatibility

Autoaspect will be default is you don't define aspect on the command-line.


Bilu
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #202  
03-03-2004, 07:11 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Posted our work at Doom9

http://forum.doom9.org/showthread.php?s=&threadid=71991


Bilu
Reply With Quote
  #203  
03-03-2004, 07:32 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Link to search on the MPlayer mailing lists, add to Favorites

Quote:

Bilu
Reply With Quote
  #204  
03-03-2004, 12:03 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
Minimum syntax for DVD compatibility, simplified

Quote:
SIMPLE BATCH FILE WITH VARIABLE PARAMETERS
=================================
mencoder -include settings.ini -lavcopts vrc_eq=tex:vbitrate=9800:keyint=18 movie.vob -o movie.mpg

bbdmux movie.mpg 0xe0 movie.m2v

SETTINGS.INI
=========
of=mpeg=1
ovc=lavc=1
noskip=1
nosound=1
lavcopts=vcodec=mpeg2video:ildct=1:ilme=1:vstrict=-1:
vqblur=0:vrc_minrate=300:vrc_maxrate=9800:vrc_buf_ size=1835:autoaspect=1
Hi bilu, is it really necessary ildct=1 and ilme=1 for every encode, or just for interlaced sources?. And if we encode in PAL, without fractional framerate, do we still need vstrict=-1?.
Quote:
Originally Posted by bilu
Autoaspect will be default is you don't define aspect on the command-line.
I don't understand this completely. If I frameserve to mencoder through an avs script, and in the script I already crop/resize/addborders/letterbox, do I need to include autoaspect?. What will it do then?. I've not used it till now, and I think my output got correct aspect, even with 16:9 encodes.
Nice idea Settings.ini , do we have to make a separate file named settings.ini, isn't it?. And we have to store it in mplayer directory, with codecs.conf, don't we?.

...keep us informed on feedback you all get at forum9, to improve our KDVD encodings
Reply With Quote
  #205  
03-03-2004, 12:15 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by digitall.doc
Hi bilu, is it really necessary ildct=1 and ilme=1 for every encode, or just for interlaced sources?. And if we encode in PAL, without fractional framerate, do we still need vstrict=-1?.
No need for none of those settings on PAL progressive
Quote:
I don't understand this completely. If I frameserve to mencoder through an avs script, and in the script I already crop/resize/addborders/letterbox, do I need to include autoaspect?. What will it do then?. I've not used it till now, and I think my output got correct aspect, even with 16:9 encodes.
No need for none of those settings on Avisynth sources
Quote:
Nice idea Settings.ini , do we have to make a separate file named settings.ini, isn't it?. And we have to store it in mplayer directory, with codecs.conf, don't we?.
Store it wherever you want, provided that you mention it in -include .
Well, not really tested since I put it on Mencoder's directory, but makes sense


Bilu
Reply With Quote
  #206  
03-03-2004, 12:16 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
About quality tests: these should be made with vqscale=2, so that rate control doesn't mess with filesizes.


Bilu
Reply With Quote
  #207  
03-03-2004, 12:26 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
No need for none of those settings on Avisynth sources
Well friend, your example was correct anyway, since in your command-line you used a vob file as a source
Quote:
Originally Posted by bilu
Store it wherever you want, provided that you mention it in -include.
Again, you're right. My questions where just to be sure I understood your way.
Reply With Quote
  #208  
03-03-2004, 01:03 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quality test results - fixed quantizer

11.482.354 default.m2v
11.312.817 mbd2.m2v
11.291.988 mbd2_mv0.m2v
10.347.085 mbd2_mv0_vle_vce.m2v
9.960.207 trell.m2v
9.539.090 all.m2v

Tests made using vqscale=2. Since these are rate-distortion parameters the smaller the file gets the better the parameters are.

And trellis quantization is a clear winner: mbd=2,mv0, vcelim=7 and vlelim=-4 together couldn't get even near trellis alone

All the *_mask parameters work around quantization, so they give absolutely no result here. Believe me, I tested

Also trellis-related parameters beside trell were no good here: cbp works around quantization, qprd crashes, qns is slow as hell even with the rest as default

alt increases filesize.

Filters
====
8.656.030 hqdn3d.m2v

This denoiser alone gives better results even then trellis and it's faster


Bilu
Reply With Quote
  #209  
03-03-2004, 02:21 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
Hi digitall,

as far as -include goes (and your .ini settings file) as long as you point to
it in your .BAT file, you can pretty much store your "options config" file
anywheres I've ben using this technique for the last week now (I had
posted how to write an .INI "options config" file last week, in my other
thread, which I changed for obvious reasons, the SUBJ title for w98/se/me

* MEncoder under W98 / SE / ME - (work in progress) ..

Later on, I'll be adding instructions on how to read in vdub --> avisynth
script, for even more flexibility (I was debuggin if over the weekend
to be sure it worked well) and I know RDS was on my tail about it
sorry rds, I've ben brain-storming other things, and I couldn't post sooner.
Anyways..

Now, W98/SE/ME do not have to suffer anymores (me for instance) and can
join in the fun

Well, I gotta get going for an apointment now, and I'm late. If I forget to
take care of the above, just remind me later on.. thanks.

Cheers guys,
-vhelp
Reply With Quote
  #210  
03-03-2004, 04:02 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
Tests made using vqscale=2. Since these are rate-distortion parameters the smaller the file gets the better the parameters are.
Sorry if making too much questions , but I'm trying to learn how to tweak this encoder. I understood if you use vqscale=2 (just for test purpose) and leave the rest to default (what default?. vrc_maxrate=9800, vrc_minrate=300, vrc_but_size=1835, vbitrate=...) this fixes quantizer to 2 (just Iframes quantizer, P and B frames will receive more, if you use B frames). So the rest of parameters you use just can have effect on bitrate and how quantitation is applied, isn't it? (I don't know a single word on mpeg encoding, that's why I ask things that maybe so clear to everybody, be patient). But what I didn't understand is why the better the parameters are (in terms of quality) the smaller the file will get. Could you explain me how. I thought that at fixed quantizer, the encoder played with bitrate to compress the film (the higher the better, and the bigger file size). But I see I was wrong

Yes, I like trellis a lot. But even if mbd and mv0 aren't better, can't we make use of all of them?. And I don't like the results I get with vcelim and vlelim with these parameters, seems to me that colours get poorer, more plain

Quote:
Originally Posted by bilu
8.656.030 hqdn3d.m2v

This denoiser alone gives better results even then trellis and it's faster
Sorry, lost again. I thought trellis was a way to apply quantitation, and not a denoiser. Can we then substitute trellis with hqdn3d?. What about your source, did it need a denoiser, doesn't hqdn3d make look the film too smooth? (I didn't test it).

@vhelp
thanx for your advises. I would also put in settings.ini the Notch inter/intra matrix. I'm willing totake a look at your GUI for mencoder friend.

@all,
again, thank you for being patient

EDIT: BTW bilu, did you take a look at your tests in bitrate viewer?, how did they perform?. And did you a visual comparison?, are the smaller files still "good looking"?.
Reply With Quote
  #211  
03-03-2004, 06:34 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Sorry if making too much questions , but I'm trying to learn how to tweak this encoder. I understood if you use vqscale=2 (just for test purpose) and leave the rest to default (what default?. vrc_maxrate=9800, vrc_minrate=300, vrc_but_size=1835, vbitrate=...) this fixes quantizer to 2 (just Iframes quantizer, P and B frames will receive more, if you use B frames). So the rest of parameters you use just can have effect on bitrate and how quantitation is applied, isn't it? (I don't know a single word on mpeg encoding, that's why I ask things that maybe so clear to everybody, be patient). But what I didn't understand is why the better the parameters are (in terms of quality) the smaller the file will get. Could you explain me how. I thought that at fixed quantizer, the encoder played with bitrate to compress the film (the higher the better, and the bigger file size). But I see I was wrong
From http://www.bretl.com/mpeghtml/mpeg2vc1.HTM :
Quote:
Data representing macroblocks of pixel values for a picture to be encoded are fed to both the subtractor and the motion estimator. The motion estimator compares each of these new macroblocks with macroblocks in a previously stored reference picture or pictures. It finds the macroblock in the reference picture that most closely matches the new macroblock. The motion estimator then calculates a motion vector (mv) which represents the horizontal and vertical displacement from the macroblock being encoded to the matching macroblock-sized area in the reference picture . Note that the motion vectors have 1/2 pixel resolution achieved by linear interpolation between adjacent pixels.

The motion estimator also reads this matching macroblock (known as a predicted macroblock) out of the reference picture memory and sends it to the subtractor which subtracts it, on a pixel by pixel basis, from the new macroblock entering the encoder. This forms a error prediction or residual signal that represents the difference between the predicted macroblock and the actual macroblock being encoded. This residual is often very small.
In english, this means that using rate-distortion settings like trellis to find the better macroblocks will make the error prediction even smaller.
And the better the macroblock gets predicted, the smaller the filesize will be
That's why I made this tests aiming at a fixed quantizer, so they wouldn't be affected by rate control.

Quote:
Yes, I like trellis a lot. But even if mbd and mv0 aren't better, can't we make use of all of them?. And I don't like the results I get with vcelim and vlelim with these parameters, seems to me that colours get poorer, more plain
Of course you can About vlelim and vcelim, plainer colours are more easily compressed. It's the only reason why you would use it.

Quote:
Sorry, lost again. I thought trellis was a way to apply quantitation, and not a denoiser. Can we then substitute trellis with hqdn3d?. What about your source, did it need a denoiser, doesn't hqdn3d make look the film too smooth? (I didn't test it).
Not quite a replacement, of course. Trellis keeps all the quality of the movie. But if you like this denoiser output, then you'll have faster and more efficient compression

Quote:
BTW bilu, did you take a look at your tests in bitrate viewer?, how did they perform?. And did you a visual comparison?, are the smaller files still "good looking"?.
In terms of Bitrate Viewer, that's how I learned that the mask parameters work through quantization
With lumi_mask=0.3 and dark_mask=0.3 this file got as small as 2Mb when not using fixed quantizer.
On Bitrate Viewer it showed a lot of quantizers 6 and 7 and still looked pretty
But when using fixed quantizer they didn't work at all.

This leaves us with a second conclusion: if you want to use mask parameters on a 2-pass encode, use them only on 2nd pass, and with naq.
Because they wouldn't have any effect at all during the 1st pass.And naq will allways help trying to keep things within average bitrate.

Visually all files looked good. And you really have to look at the output of this denoiser, it looks very nice to me


Bilu
Reply With Quote
  #212  
03-03-2004, 08:19 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quality test results - variable quantizer

Well, since I liked the denoiser output so much I didn't made the test with trellis related parameters like cbp or qns.

But I'll show you how to test: don't use naq. If it visually looks good and got much smaller then it's a good parameter

The winner here is scplx_mask=0.3 . It provided much better results than lumi_mask or dark_mask (tested on a panning trees scene, a bit dark) in terms of filesize. Tried scplx_mask=0.5 , but it's way too much and gets blocky.

Of course that when doing real encodes we should use naq. It will try to keep the average bitrate so that encoding filesize is still predictable.

Bilu
Reply With Quote
  #213  
03-03-2004, 09:59 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
My settings for 1-pass VBR encodes

Quote:
SETTINGS.BAT
==========
of=mpeg=1
ovc=lavc=1
vf=hqdn3d=1
noskip=1
nosound=1
lavcopts=vcodec=mpeg2video:ildct=1:ilme=1:vstrict=-1:
vqblur=0:vqmax=10:mbqmax=10:vrc_eq=tex:vrc_minrate =300:vrc_maxrate=9800:vrc_buf_size=1835:autoaspect =1:scplx_mask=0.3:naq=1

BATCH FILE
========
set menc=D:\kvcd\progs\mplayer
set bb=D:\kvcd\progs\bbtool
set movdir=D:\kvcd\samples
set outdir=D:\kvcd\result
set movie=%1
set gop=%2
if "%gop%"=="" set gop=15

cls
cd /d %movdir%
del /q /f %outdir%\%movie%.mpg
del /q /f %outdir%\%movie%.m2v
del /q /f %movdir%\*.log

%menc%\mencoder -include %menc%\settings.ini -lavcopts vbitrate=3000:keyint=%gop% %movdir%\%movie% -o %outdir%\%movie%.mpg

%bb%\bbdmux %outdir%\%movie%.mpg 0xe0 %outdir%\%movie%.m2v
del /q /f %outdir%\%movie%.mpg

USAGE
=====
NTSC -> encode.bat movie.vob 18
PAL -> encode.bat movie.vob
NOTE: You can notice that I've disabled B-frames and limited the maximum quantizer to 10. That's because I've tested with a very bitrate-demanding sample from an interlaced anime. The anime is done like this:

A B C
A AC C

Where A,B and C are normal fields and AC is a blend from the previous and next frame. So periodically you have an interlace frame because one of the fields is blended. Try to imagine bitrate peaks like 10080 kbps with vqscale=2. And blended fields. And high-action anime.

When trying to do a VBR encode at 3000 kbps I got lots of lose blocks in one scene. I realized then that it was an high-bitrate scene and B-frame compression was showing more info from the next field than the current one in some macroblocks.Those lose blocks looked like coming from the next frame. That in a high-action, blended field, interlaced anime is a complete disaster

When I disabled B-frames the problem stopped.
Probably that's the reason why this parameter exists:
Quote:
vb_strategy=<0-1>
strategy to choose between I/P/B frames (pass 2):
0 always use the maximum number of B frames (default)
1 avoid B frames in high motion scenes (will cause bitrate misprediction)
But that parameter is for 2-pass encodes only.
So this was the best solution I came up with so far.

Since trell also works with macroblocks, I'm testing trell with vmax_b_frames=2 with the same denoiser filter, just to see if trell can help with B-frames.

EDIT: It didn't help at all. So I'll use no B-frames in 1-pass encodes and try vb_strategy=1 in 2-pass encodes. If the bitrate misprediction caused by this parameter can't be compensated by the 2-pass algorithm then I'll abandon B-frames there as well.


Bilu
Reply With Quote
  #214  
03-04-2004, 04:48 AM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
NOTE: You can notice that I've disabled B-frames and limited the maximum quantizer to 10.
Did you try to adjust B frames quantitation through offset?. Although, from your explanation of the problem (B frames encoding info from next field), I'm afraid it won't solve it.
Quote:
Originally Posted by bilu
When trying to do a VBR encode at 3000 kbps I got lots of lose blocks in one scene.
You dropped the strategy employing vrc_maxrate=vbitrate... just for this test?. It works nice for me, but I still don't know if it makes file prediction impossible to be done...
Quote:
Originally Posted by bilu
Since trell also works with macroblocks, I'm testing trell with vmax_b_frames=2 with the same denoiser filter,...
Why not using trell?, is it because you like more the denoiser?.
Limiting vqmax and mbqmax, how does bitrate raise in your bitrate demanding test?, does it still respect vrc_maxrate?
I'm trying to figure out some basic parameters (applyable in majority of encodings), and will try to select a set of parameters to apply in specific situations (bitrate demanding film, dark film, slow motion film,...). But still stuck in basic parameters.
Also, already started to try to encode SKVCD with mencoder (maxrate 2500, avg vbitrate with formula), to substitute KVCD encodings with TMPGEnc. But get lots of blocks in fast scenes (well still beging, just 1 encode).
Reply With Quote
  #215  
03-04-2004, 06:50 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Tested mencoder for KVCD. I tried maxrate=2800, vbitrate=1211 (trying to fit a film on 1 CD), but got lots of blocks in transitions from slow to high action (in bitrate viewer there was a sharp raise in Q value at 29, and sharply down).
I tweaked a bit, lowering vqmax an mbqmax to 10, but still the same. Maxbitrate was respected more or less (max 3100 in BV), file size slightly higher. Tried again raising vbblur at 0.3 to avoid those sharp changes in Q value, to see if improved something, but didn't get better.
Still testing. I'll try not to use trellis...
Reply With Quote
  #216  
03-05-2004, 10:55 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by digitall.doc
Quote:
Originally Posted by bilu
When trying to do a VBR encode at 3000 kbps I got lots of lose blocks in one scene.
You dropped the strategy employing vrc_maxrate=vbitrate... just for this test?. It works nice for me, but I still don't know if it makes file prediction impossible to be done...
vrc_maxrate=vbitrate only works good for high-bitrates, that's what it was designed for.
About file size predition, still don't know since I've been working with very small samples ( VOBs < 50 MB)
Quote:
Quote:
Originally Posted by bilu
Since trell also works with macroblocks, I'm testing trell with vmax_b_frames=2 with the same denoiser filter,...
Why not using trell?, is it because you like more the denoiser?.
Limiting vqmax and mbqmax, how does bitrate raise in your bitrate demanding test?, does it still respect vrc_maxrate?
Trell is slower and doesn't bring as much compression as denoiser, but keeps all the details.
But since I like this denoiser output I don't have the need for trellis to encode on a PIII-500

Limiting vqmax and mbqmax forces the 1-pass VBR algorithm to compress more the scenes that are less bitrate-demanding to keep the average.
It respects the maxrate, but it isn't able to keep the average on small samples like the ones I'm testing, which is normal.
I have to start making tests with a minimum half movie to make sure about file size prediction.

Meanwhile I tested that scene again without using naq. As I knew, quantizers got raised since it's not trying to keep an avg bitrate through the naq parameter.
But the 1-pass VBR algorithm still tries to keep that average so the more bitrate-demanding scenes have more room to grow and overall quality gets much better.
Still I have to tune it decreasing scplx_mask=0.3 to 0.2 or 0.1, because although overall quality got much better, it's still a bit too blocky.

I think that naq is more appropriate for 1-pass CBR than 1-pass VBR.
Don't know yet about 2-pass VBR, probably is better to use it as well.
But it seems better to have a smaller mask than to use naq.


Bilu
Reply With Quote
  #217  
03-05-2004, 12:18 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Good news: problem was not B-frames, but the denoiser settings in the settings.ini file

I tried before
vf=hqdn3d=1

Now replaced them with the default values
vf=hqdn3d=4:3:6

And everything works like a charm

EDIT:Wrong again, tried lower bitrates and the B-frame shit comes back

Bilu
Reply With Quote
  #218  
03-05-2004, 01:09 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Hi bilu,
I don't know if you feel the same, but it seems to me that less people is posting in this forum... Don't say people is not testing, neither they dropped mencoder/ffvfw, it's just no posts.
I'm glad you solved your ghosting problem.
I'm still struggling with mencoder settings to get rid off blocks in low bitrate (as low as max 2800 avg 1211). I'll try without naq as you did. But there's a scene (film: Spirit, Disney, animation) where it's snowing, and snow becomes lots of blocks. I'm begining to feel lost.
Quote:
Originally Posted by bilu
vrc_maxrate=vbitrate only works good for high-bitrates, that's what it was designed for.
But you're using max 9800 and avg 3000, and maybe that can be considered high bitrate. You could give it a try (maybe you already did). The tests I did, in fast action and complex scenes, with vbitrate=vrc_maxrate=9800, avg bitrate still was about 2200 (even below your avg 3000)
Quote:
Originally Posted by bilu
Limiting vqmax and mbqmax forces the 1-pass VBR algorithm to compress more the scenes that are less bitrate-demanding to keep the average.
I didn't know that was the effect. I mean, I thought that in high bitrate scenes, when encoder finds that bitrate will go over maxrate, it raises quantizer in order to keep bitrate about maxrate. But if quantizer gets also to vqmax, and bitrate about maxrate, what does the encoder then?. I ask because in my SKVCD tests it happens that bitrate is at 3000 (maxrate 2800), quantizer at 15 (vqmax=15), and it mantains those values for a while. And I believe that happens in my snow-blocking scenes... And for less bitrate demanding scenes, I thought that encoder just lowered bitrate and mantained quantization... just a believe, I don't really know how it works.
Quote:
Originally Posted by bilu
I think that naq is more appropriate for 1-pass CBR than 1-pass VBR.
I'll give it a try in my SKVCD blocky test
BTW, did you give notch-matrix a try?. You could set it in ypur settings.ini file. You'll see that file size decrease, without loosing quality
Well friend, wait your feedback while making tests... tests... tests...
Reply With Quote
  #219  
03-05-2004, 01:10 PM
digitall.doc digitall.doc is offline
Free Member
 
Join Date: Jul 2003
Location: Valencia (España)
Posts: 741
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by bilu
EDIT:Wrong again, tried lower bitrates and the B-frame sh*t comes back

Bilu
Sad to read that
Reply With Quote
  #220  
03-05-2004, 01:16 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by digitall.doc
Quote:
Originally Posted by bilu
EDIT:Wrong again, tried lower bitrates and the B-frame sh*t comes back

Bilu
Sad to read that
One parameter to rule them all

preme=2

and the B-frame problem is no more

EDIT: Wrong again in a bigger sample the problem showed again.
Still this parameters is really good

Bilu
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
FFMPEG: Ffvfw VIDEO CODEC kwag Video Encoding and Conversion 364 08-12-2005 07:49 AM
FFMPEG: Curious about H.263 in ffvfw poerschr Video Encoding and Conversion 14 02-25-2004 07:54 PM
FFMPEG: Observation about ffvfw poerschr Video Encoding and Conversion 28 02-24-2004 05:50 PM
FFMPEG: Do ffvfw and mencoder/ffmpeg give the same results? Razorblade2000 Video Encoding and Conversion 4 02-06-2004 04:23 PM
FFMPEG: XMPEG 5.03 and ffvfw kwag Video Encoding and Conversion 2 02-05-2004 10:57 AM

Thread Tools



 
All times are GMT -5. The time now is 11:54 PM  —  vBulletin © Jelsoft Enterprises Ltd