Quantcast FFmpeg vs FFvfw vs Mencoder ? - digitalFAQ.com Forums [Archives]
  #1  
02-14-2004, 06:41 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Hi,

Could someone make a summary of the differences between these encoders/codecs, in the rate control area, bugs, etc.?

I'm still trying to find if any of these is reliable for KDVDs in respect to max/min bitrate enforcement.


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
  #2  
02-14-2004, 07:28 AM
Razorblade2000 Razorblade2000 is offline
Free Member
 
Join Date: Aug 2002
Posts: 323
Thanks: 0
Thanked 0 Times in 0 Posts
AFAIK there is none

They all use the same encoder... libavcodec
Reply With Quote
  #3  
02-14-2004, 07:38 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
That's what I thought too until reading this Kwag's post:

http://www.kvcd.net/forum/viewtopic.php?p=62465#62465
Quote:
I agree with that, but FFMPEG has some serious issues on the stream, which render the muxing useless.
That apparently has been fixed in ffvfw, because I can mux every ffmpeg produced stream, without any underruns or overrruns.
Not so with ffmpeg
Bilu
Reply With Quote
  #4  
02-14-2004, 07:59 AM
Razorblade2000 Razorblade2000 is offline
Free Member
 
Join Date: Aug 2002
Posts: 323
Thanks: 0
Thanked 0 Times in 0 Posts
I just know that if you wanna compile mencoder, you have to download the libavcodec folder of ffmpeg
Reply With Quote
  #5  
02-14-2004, 11:28 AM
Latexxx Latexxx is offline
Free Member
 
Join Date: Jun 2002
Location: Tampere, Finland
Posts: 65
Thanks: 0
Thanked 0 Times in 0 Posts
They have different rate control algorithms.
Reply With Quote
  #6  
02-14-2004, 02:25 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Which one is better ?

Bilu
Reply With Quote
  #7  
02-14-2004, 03:03 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
My results of mencoder are in this moment much better!

(less blocks ... totally linear Q Curve, peaks wont get ofer 3000-4000kbit at 704x576/25fps)

But that could be a seetings reason ......
Reply With Quote
  #8  
02-14-2004, 08:52 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Rate-control related parameters in FFMPEG:
Quote:
3.3 Video Options -> http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC8

-b bitrate'
set the video bitrate in kbit/s (default = 200 kb/s)
`-bt tolerance'
set video bitrate tolerance (in kbit/s)
`-maxrate bitrate'
set max video bitrate tolerance (in kbit/s)
`-minrate bitrate'
set min video bitrate tolerance (in kbit/s)
`-bufsize size'
set ratecontrol buffere size (in kbit)
IMHO -bufsize and -bt may play a big role in VBR. Would like to know more about these.

Quote:
3.4 Advanced Video Options -> http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC9

`-qscale q'
use fixed video quantiser scale (VBR) .
To have a constant quality (but a variable bitrate), use the option '-qscale n' when 'n' is between 1 (excellent quality) and 31 (worst quality).

`-qmin q'
min video quantiser scale (VBR)
`-qmax q'
max video quantiser scale (VBR)
`-qdiff q'
max difference between the quantiser scale (VBR)
`-qblur blur'
video quantiser scale blur (VBR)
`-qcomp compression'
video quantiser scale compression (VBR)
I'd like to know a bit more about -qblur and -qcomp.
IMHO -qscale is obviously not recommended: fixed quantizers means all frames, simple or complex, are compressed with the same quantizer.
There is no way to respect a maximum bitrate if you CAN'T compress a frame enough to fit in the bitrate range because the fixed quantizer won't let you.

Example: try to fit 50% of 8 MB into 3 MB. You can't, you'd have to change from 50% from something else. That's why fixed quantizers bring no garantees!

Quote:
`-rc_eq equation'
set rate control equation (see section 3.8 FFmpeg formula evaluator). Default is tex^qComp.
`-rc_override override'
rate control override for specific intervals

3.8 FFmpeg formula evaluator -> http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC13
These can't be considered documented :/

EDIT: All my doubts in this post were gone after reading Mencoder docs. Read next post

Bilu
Reply With Quote
  #9  
02-14-2004, 09:55 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Rate-control related parameters for Mencoder

http://www.mplayerhq.hu/MPlayer/rele.../man_page.html

Section CODEC SPECIFIC ENCODING OPTIONS (MENCODER ONLY)

As you see, lots of stuff is related to FFMPEG, but it's better documented
There is some new neat stuff as well.

Code:
vqscale=<1-31>	 
Constant quantizer / constant quality encoding (se- lects fixed quantizer mode). A lower value means better quality but larger files (default: 0 (dis- abled)).	  
	 
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)	 
	 
vbitrate=<value>	 
specify bitrate (pass 1/2). Warning: 1kBit = 1000 Bits.	 
4-16000		  (in kbit)	 
16001-24000000	 (in bit)	 
800		  default
	 
vratetol=<value>	 
approximated filesize tolerance in kBit. 1000-100000 is a sane range. (warning: 1kBit = 1000 Bits) (default: 8000)	 

vrc_maxrate=<value>	 
maximum bitrate in kbit/sec (pass 1/2)	 

vrc_minrate=<value>	 
minimum bitrate in kbit/sec (pass 1/2)	 

vrc_buf_size=<value>	 
buffer size in kbit (pass 1/2). Note: vratetol should not be too large during the second pass or there might be problems if vrc_(min|max)rate is used.
	 
vqblur=<0.0-1.0>	 
quantizer blur (pass1) Larger values will average the quantizer more over time (slower change).	 
0.0	 qblur disabled	 
0.5	 (default)	 
1.0	 average the quantizer over all previous frames	 

vqblur=<0.0-99.0>	 
quantizer gaussian blur (pass2) Larger values will average the quantizer more over time (slower change) (default: 0.5)	 

vqcomp=<value>	 
quantizer compression, depends upon vrc_eq (pass 1/ 2) (default: 0.5)
The better documented stuff:

Code:
	 
vrc_eq=<equation>	 
main ratecontrol equation (pass 1/2):	 
1	 constant bitrate	 
tex	 constant quality	 
1+(tex/avgTex-1)*qComp	 approximately the equation of the old rate-control code	 
tex^qComp		  with qcomp 0.5 or something like that (default)	 

infix operators: +,-,*,/,^
	 
variables:	 
tex		  texture complexity	 
iTex,pTex	 intra, non intra texture complexity	 
avgTex		  average texture complexity	 
avgIITex		  average intra texture complexity in I frames	 
avgPITex		  average intra texture complexity in P frames	 
avgPPTex	 average non intra texture complexity in P frames	 
avgBPTex	 average non intra texture complexity in B frames	 
mv		  Bits used for motion vectors	 
fCode		  maximum length of motion vector in log2 scale	 
iCount		  number of intra macro blocks / number of macro blocks	 
var		  spatial complexity	 
mcVar		  temporal complexity	 
qComp		  qcomp from the command line	 
isI,		  is 1 if picture type is I/P/B else 0	 
Pi,E		  see your favorite math book	 

functions:	 
max(a,b),min(a,b)	 maximum / minimum	 
gt(a,b)		  is 1 if a>b, 0 otherwise	 
lt(a,b)		  is 1 if a<b, 0 otherwise	 
eq(a,b)		  is 1 if a==b, 0 otherwise	 
sin, cos, tan, sinh, cosh, tanh, exp, log, abs	 


vrc_override=<options>	 
User specified quality for specific parts (ending, credits, ..) (pass 1/2). The options are <start-frame>, <end-frame>, <quality>[/ <start-frame>, <end-frame>, <quality>[/...]]:	 

quality (2-31)		  quantizer	 
quality (-500-0)		  quality correction in %
Now the neat stuff

Code:
	 
vqsquish=<0,1>	 
specify how to keep the quantizer between qmin and qmax (pass 1/2):	 
0	 use clipping	 
1	 use a nice differentiable function (default)
Seems to me there are good reasons to choose Mencoder, particularly -vqsquish (if it works, of course )

Conclusion: avoid -vqscale (to respect max/min bitrate) and use -vqsquish (if it works).

Bilu
Reply With Quote
  #10  
02-14-2004, 10:21 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
FFVFW

Ratecontrol -> one pass CBR -> "Use continuous function to limit quantizers within qmin/qmax"

or

SQUISH.REG
========
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\GNU\ffvfw]
"ff1_rc_squish"=dword:00000001

Seems to be the same as -vqsquish.
Is FFMPEG the only one without this feature ?

Bilu
Reply With Quote
  #11  
02-14-2004, 10:59 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
I'd like to hear some feedback about:

FFMPEG -maxrate and -minrate being respected WITHOUT -qscale;

Mencoder -vrc_maxrate and -vrc_minrate being respected WITHOUT -vqscale;

Please post your experiences. Thanks.


Bilu
Reply With Quote
  #12  
02-15-2004, 06:02 AM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
Maybe not the Feedback that you want to hear but .... interesting that mencoder seems to encode more agressive sharper, more gibbs, etc. , FFvfw looks more easy and CCE got the best quality in underwaterscenes according to blocks.

All three samples got almost the same filesize but watch the behaviour of the Q curve! Another example the Bitrateviewers Q curve output does not say something exact according to quality, cause here does look ffvfw the best, but very near followed by CCE.

Pics are cropped an 200% Scaled, safed as Jpeg at 50% Quality

Reply With Quote
  #13  
02-15-2004, 07:23 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
What settings did you use?

Settings that may worth checking in Mencoder:
Quote:
-----------------------------------------------------------------------
-vqmin
-vqmax
-mbqmin (min macroblock quantizer)
-mbqmax (max macroblock quantizer)
-----------------------------------------------------------------------
-vqdiff (?)

maximum quantizer difference between I or P frames (pass 1/2) (default: 3)
-----------------------------------------------------------------------
-mbd=2

Macroblock decision algorithm (high quality mode), encode each macro block in all modes and choose the best. This is slow but results in better quality and file size.

0 use mbcmp (default)
1 select the MB mode which needs the fewest bits (=vhq)
2 select the MB mode which has the best rate distortion
-----------------------------------------------------------------------
-vqsquish=1 in 1-pass encodes
-----------------------------------------------------------------------
-scplx_mask=0.5

spatial complexity masking. Larger values help against blockiness, if no deblocking filter is used for decoding. Tip: Crop any black borders com- pletely as they will reduce the quality of the macro blocks (also applies without scplx_mask).

0.0 disabled (default)
0.0-0.5 sane range

-naq (?)

Normalize adaptive quantization (experimental). When using adaptive quantization (*_mask), the av- erage per-MB quantizer may no longer match the re- quested frame-level quantizer. Naq will attempt to adjust the per-MB quantizers to maintain the proper average.

-----------------------------------------------------------------------
-precmp=2
-cmp=2
-sucmp=2

motion estimation:

0 (SAD) sum of absolute differences, fast (default)
1 (SSE) sum of squared errors
2 (SATD) sum of absolute hadamard transformed dif- ferences
3 (DCT) sum of absolute dct transformed differences
4 (PSNR) sum of the squared quantization errors (don't use, low quality)
5 (BIT) number of bits needed for the block
6 (RD) rate distortion optimal, slow
7 (ZERO) 0
+256 use chroma too, doesn't work (correctly) with B frames currently

From the FFVFW tips:

Tip: SAD is fast, SATD is good
Tip2: when using SATD for full pel search you should use a larger diamond something like dia=2 or dia=4

-predia=<-99-6> Diamond type and size for motion estimation pre pass
-dia=<-99-6> Diamond type & size for motion estimation. Note: The sizes of the normal diamonds and shape adaptive ones dont have the same meaning

-3 shape adaptive (fast) diamond with size 3
-2 shape adaptive (fast) diamond with size 2
-1 experimental
1 normal size=1 diamond (default) =EPZS type diamond
2 normal size=2 diamond

From the FFVFW tips:
Tip: the shape adaptive stuff seems to be faster at the same quality
Note: the sizes of the normal diamonds and shape adaptive ones dont have the same meaning
-----------------------------------------------------------------------
-trell

Trellis searched quantization. This will find the optimal encoding for each 8x8 block. Trellis searched quantization is quite simple a optimal quantization in the PSNR vs bitrate sense (assuming that there would be no rounding errors introduced by the IDCT, which is obviously not the case) it simply finds a block for the minimum of error and lambda*bits.

lambda qp dependant constant
bits amount of bits needed to encode the block
error sum of squared errors of the quantization

-cbp

Rate distorted optimal coded block pattern will se- lect the coded block pattern which minimizes dis- tortion + lambda*rate this can only be used togeth- er with trellis quantization

-----------------------------------------------------------------------

Bilu
Reply With Quote
  #14  
02-15-2004, 02:21 PM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Anyone willing to test these?

-------------------
1-pass only

-vqsquish=1 in 1-pass encodes
-------------------
Independent, may improve quality

-mbd=2
-trell
-cbp
-------------------
Complementary, one adjusts spatial detail, the other readjusts the per-MB quantizer

-scplxmask=0.5
-naq
-------------------
Complementary,SATD is slower but better than default SAD, when using SATD we should use a larger diamond setting

-precmp=2
-cmp=2
-sucmp=2

-predia=-2
-dia=-2
-------------------
Per macroblock quantizer

-mbqmin
-mbqmax
-------------------


The reason why I'm asking others to test instead of testing myself is because my Windows PIII-850 machine has burned the motherboard (not really burned, just leaking components (condensers?) that stop it from booting. For about a month I was about to boot with a stronger power source, but not enough anymore.

I'm writing this on my company's PIII-500 laptop which I need too much to be operational to risk doing experiments.

I'm considering using an old Pentium 200 with 64 MB RAM for DVD-backups: learn to use FreeBSD (it's very fast), install Mencoder, learn to script and create a set-and-forget DVD5-DVD9 tool for my own use. It'll take time, of course, but it would be a good use for that machine

I also want the Windows machine (when I upgrade it) to be free for other stuff. Anyway, it's just a plan: I still didn't check the hard drive limitations of that old Pentium board, may not handle the 20 GB disk I have reserved for it

But for that I need to know if I can make reliable DVD encodings with Mencoder, i.e. according to the specifications.
Quality would be nice too


That's why I'm digging for the best parameters for you mates to test
C'mon, I know you're interested too


Cheers,
Bilu
Reply With Quote
  #15  
02-15-2004, 05:47 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Hi Bilu,
You're on the right path when you ask about all the arguments like vqsquish, but the thing is I like man pages written with substance and mplayer ones just don't have it...
What should I try with vqsquish? vrc_minrate/vrc_maxrate, or vqmin/vqmax, or both and vqscale...
Damn, I'm just not sure if vqmin should have lower figure than vqmax or opposite.
I think I'm just not the guy that's going to discover how it's done.
Somebody had some more luck than myself?
Because most of my tests with these babies are giving me buffer underflows when encoding.
Cheers
__________________
Rui
Reply With Quote
  #16  
02-16-2004, 10:26 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
@rds_correia

-----------------------------------------------
-vqscale should be abandoned for good. Why encode with a fixed quantizer? How will an encoder limit the bitrate if the quantizer is fixed?
-----------------------------------------------
Everyone (1-pass OR 2-pass) should try these, they may improve quality:

For rate distortion:
-mbd=2
-trell
-cbp

To avoid blocks, -naq is to try to maintain the per-MB quantizer average with *_mask:

-scplxmask=0.5
-naq
-----------------------------------------------
If you want to limit quantizers you should use these:

-vqmin (min quantizer)
-vqmax (max quantizer)
-mbqmin (min per-MB quantizer)
-mbqmax (max per-MB quantizer)

If doing 1-pass and limiting quantizers you can use:

-vqsquish=1
-----------------------------------------------
If you want to try better motion estimation (slower) try:

-precmp=2
-cmp=2
-sucmp=2
-predia=-2
-dia=-2
-----------------------------------------------


About your buffer overflow problem, I don't know how stable the Windows port is.

About documentation, I'll do my best to try to get it for you guys
I DO want you to test!

Bilu
Reply With Quote
  #17  
02-17-2004, 11:08 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
About the -vqcomp switch:

http://zebra.fh-weingarten.de/~maxi/.../msg00433.html
Quote:
D. Richard Felker, III <dalias@xxxxxxxxxx> wrote:
>> >> According to an xvid page (http://roeder.goe.net/%7Ekoepi/xvid.shtml,
>> >> the "XViD Options Explained" PDF), the xvid codec supports such an
>> >> operation. The page says that I should set the "curve compression" to
>> >> 0 or 1 and the "payback delay" to 1. But these are the parameter
>> >> names in a different xvid gui, I can't find them in mencoder. So maybe
>> >> someone can tell me the equivalent mencoder options?
>> >
>> > The corresponding options for lavc are vqcomp, vqblur, vqsquish,
>> > vratetol, vrc_maxrate, vrc_minrate. However, the defaults are rather
>> > good.
>>
>> Nevertheless, I would be happy if you could explain them too.
>
> They're explained in the mplayer man page.

Yes. But an explanation like

vqcomp=<value>
quantizer compression, depends upon vrc_eq (pass 1/2)
(default: 0.5)

isn't really helpful if you aren't an MPEG developer.
Your explanation below is indeed very good. I think that this type of
explanation should be in the manpage.

>> > Increasing vqcomp (default is 0.5) to something near 1 will make
>> > quality more steady for the whole movie. Decreasing it will make
>> > bitrate more steady (close to constant bitrate).
>>
>> I increased vqcomp up to 1. But the bitrate was still exactly as
>> specified. That is why I'm thinking that some of the other options
>> have wrong values (maybe mencoder sets them, so the defaults in ffmpeg
>> don't apply).
>
> The bitrate will always be (almost) exactly as you specify. That's the
> way it works. What vqcomp affects is how those available bits get
> distributed among frames. With vqcomp=0, all frames will get
> approximately the same number of bits, whereas with vqcomp=1, they'll
> all get approximately the same quantizer (or at least that's how I
> understand it...). Putting vqcomp all the way up at 1 is probably not
> a great idea; in that case, you might as well use vqscale=whatever.

Based on your explanation of rate control, this means that with
vqscale=1 all frames with low quantizers get an increased quantizer
and all frames with high quantizers get a decreased quantizer, while
with vqscale=0 those with high bitrates get increased quantizers and
those with low bitrates get decreased quantizers during the second
pass. Is this correct?

Then there is a difference between vqscale=n and vqcomp=1. With
vqcomp=1 you get the best possible constant quantizer at the desired
bitrate while you have to specify the quantizer manually (bitrate is
ignored) in the vqscale=n mode.

> BTW, you still haven't told me whether you're using 1pass or 2pass
> encoding. If you're only doing 1pass, you should expect the output to
> look rather bad...

2-pass mode, of course.

--Nikolaus
Bilu
Reply With Quote
  #18  
02-17-2004, 11:37 AM
bilu bilu is offline
Free Member
 
Join Date: Jan 2004
Posts: 341
Thanks: 0
Thanked 0 Times in 0 Posts
Another interesting Mencoder switch:

-mv0

try to encode each MB with MV=<0,0> and choose the better one this has no effect if mbd=0


Translated into english this means that it will try to encode each MB as no-motion if possible. Meaning less bitrate and better quality.

Bilu
Reply With Quote
  #19  
02-17-2004, 05:17 PM
vmesquita vmesquita is offline
Invalid Email / Banned / Spammer
 
Join Date: May 2003
Posts: 3,726
Thanks: 0
Thanked 0 Times in 0 Posts
Looks like what we want is constant quantisizer, if the resulting filesize does not goes beyond the max or below the minimmum. In those cases (and only on those cases), we want the quantisizer to be shiftet up/down to respect max/min. And I don't see a way to do that using any of this options...
So looks like a 1-pass VBR quality based, respecting max/min is impossible with mencoder, unless some changes are made in the source code. Doesn't it?
Reply With Quote
  #20  
02-17-2004, 05:56 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Hi VM,
Completely agree with ou pal
I starting to sense that there is just no way.
It's just not the way these libavcodec based encoders were made to run.
Either you really want constant quality or average bitrate.
I am pretty sure by looking at different constant quality encodes done with q=2 and others with q=3 that, even if the encoders could switch from 2 to 3 and 3 to 2 when needed, you would actually see when it does the switch because of the big difference in the quality provided by those 2 values.
But nevertheless I think we could progress to a smooth change, like a real curve, between 2 and 3. Maybe that wouldn't be so agressive to the picture quality.
C ya
__________________
Rui
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 10:33 AM  —  vBulletin © Jelsoft Enterprises Ltd