FFMPEG vs FFVFW vs Mencoder ?
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. :roll: Bilu |
AFAIK there is none :-?
They all use the same encoder... libavcodec :D |
That's what I thought too until reading this Kwag's post:
http://www.kvcd.net/forum/viewtopic.php?p=62465#62465 Quote:
|
I just know that if you wanna compile mencoder, you have to download the libavcodec folder of ffmpeg :-?
|
They have different rate control algorithms.
|
Which one is better ? :D
Bilu |
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 ...... |
Rate-control related parameters in FFMPEG:
Quote:
Quote:
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:
EDIT: All my doubts in this post were gone after reading Mencoder docs. Read next post :) Bilu |
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> Code:
Code:
Conclusion: avoid -vqscale (to respect max/min bitrate) and use -vqsquish (if it works). Bilu |
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 ? :roll: Bilu |
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 |
Maybe not the Feedback that you want to hear but .... interesting that mencoder seems to encode more agressive :arrow: 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 http://www.digitalfaq.com/archives/i...2004/02/35.jpg |
What settings did you use?
Settings that may worth checking in Mencoder: Quote:
Bilu |
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 :roll: That's why I'm digging for the best parameters for you mates to test ;) C'mon, I know you're interested too :twisted: Cheers, Bilu |
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 |
@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 |
About the -vqcomp switch:
http://zebra.fh-weingarten.de/~maxi/.../msg00433.html Quote:
|
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 :roll: this means that it will try to encode each MB as no-motion if possible. Meaning less bitrate and better quality. Bilu |
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? |
Hi VM,
Completely agree with ou pal :D 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 |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.