View Full Version : ffvfw asp vs. xvid quality?
ReinerSchweinlin
24th September 2005, 13:25
Iīve been looking for some information about quality when comparing ffvfw and xvid. Asuming, I want to play back my MPEG4@ASP L5-Material on my KISS DP-500, is ffvfw an alternative to XVID?
In particular, Iīd like to compare this:
XVID (newst build), MPEG4@ASP L5 with 1 b-frame, max settings (trellis, Chroma search, max search quality)
vs
ffvfw (build of 09.20.2005) MPEG4 with 1 b-frame, everything else set to max quality.
Both with two-pass mode, target Bitrate between 1000 and 2000 kbit/s for usual resolutions (544 up to 720 in width).
My goal is to achieve max. Quality and so far, XVID is ahead of DIVX or other Codecs when it comes to best quality. Even in terms of speed, XVID outpasses most rivaling codecs. ffvfw seems to be very slow compared to xvid, but that would be fine if quality surpasses XVID.
Are there any links to comparisons or has someone done a test recently? My first tests donīt show much quality difference, but since the encoding takes quite a while, I only have tried two poor-Quality Sources so far.
IvS
27th September 2005, 00:46
I don't know of any recent public comparisons.
The ffmpeg mpeg-4 ASP encoder is definitely not very slow compared to xvid. You may be using settings that aren't comparable to the xvid settings and which result in very slow speed, or who knows, maybe the build is to blame or a bug in ffdshow.
ReinerSchweinlin
27th September 2005, 09:18
Yes, I was wondering, too. Using mencoder a few months ago, mpeg4 encoding was quite fast, so maybe Iīll try another build an play with the settings. Thanx for pointing this out.
stephanV
27th September 2005, 09:45
Iīve been looking for some information about
ffvfw (build of 09.20.2005) MPEG4 with 1 b-frame, everything else set to max quality.
What does this mean? If you are using some fancy motion estimation algorythms then yes, it will be slower. At default settings libav should be a bit faster.
ReinerSchweinlin
27th September 2005, 09:49
Yes, I assume that, too. The question ist, if libav kann be tweaked to extreme settings, so the quality would surpass the one of xvid. As I canīt find any comparrisons, I thought, Iīd ask here.
iradic
27th September 2005, 14:13
taken from http://thread.gmane.org/gmane.comp.video.mencoder.user/1196
Lavc
6fps 909.944 kbit/s PSNR: Y:45.28, Cb:47.61, Cr:48.48, All:46.02
15fps 908.248 kbit/s PSNR: Y:45.24, Cb:47.58, Cr:48.40, All:45.97
42fps 906.681 kbit/s PSNR: Y:44.43, Cb:47.32, Cr:48.20, All:45.28
54fps 905.553 kbit/s PSNR: Y:43.92, Cb:47.03, Cr:47.91, All:44.81
XviD
14fps 894.029 kbit/s, Average PSNR y : 44.80 dB, u : 47.72 dB, v : 48.41 dB
20fps 895.003 kbit/s, Average PSNR y : 44.66 dB, u : 47.68 dB, v : 48.41 dB
29fps 996.446 kbit/s, Average PSNR y : 44.19 dB, u : 46.95 dB, v : 47.63 dB
41fps 993.631 kbit/s, Average PSNR y : 43.67 dB, u : 45.88 dB, v : 46.58 dB
IgorC
27th September 2005, 15:05
There was comparison between Xvid and Libavcodec. Try to use search on this forum. Xvid was better even when for Libav was used 3 passes and very slow settings
ReinerSchweinlin
28th September 2005, 21:20
I did some tests, cause I couldn't find the comparison. When using default settings, libavcodec indeed is fast. Quality is not far away from xvid, though it seems to mess up sizes in 2-pass mode. Hm, have to try some more....
bond
1st October 2005, 10:57
btw ffvfw has now been incorporated to ffdshow, the name ffvfw is not used anymore
and yeah, the mpeg-4 asp codec used in ffdshow is the one from ffmpeg/libavcodec and is mpeg-4 asp compliant as xvid and divx are
ReinerSchweinlin
1st October 2005, 13:31
Yes, I know. When doing some tests with ffdshow an VD, I couldnīt find any way to do a two-pass encoding and input a resulting bitrate. Only the target size is offerde in the config-dialog. That makes comparison between ffmpeG/libavcodec and xvid a little time-consuming, since this given size isn't reliable in very low bitrates, which I am testing right now.
Anyone know of a different frontend able to tweak all I need where I can enter a bitrate? gulmencoder could do the job but itīs development stopped quite a while ago, so there are some things not implemented.
hellfred
1st October 2005, 14:06
Yes, I know. When doing some tests with ffdshow an VD, I couldnīt find any way to do a two-pass encoding and input a resulting bitrate. Only the target size is offerde in the config-dialog. That makes comparison between ffmpeG/libavcodec and xvid a little time-consuming, since this given size isn't reliable in very low bitrates, which I am testing right now.
Anyone know of a different frontend able to tweak all I need where I can enter a bitrate? gulmencoder could do the job but itīs development stopped quite a while ago, so there are some things not implemented.
You can encode both libavcodec and xvid with mencoder from the command line. There setting a bitrate is possible. There are some frontends for mencoder to help you geting started, too.
They are listed here (http://www.mplayerhq.hu/homepage/design5/projects.html). For win32, you can try MeWiG (http://mewig.sourceforge.net/) .
Hellfred
ReinerSchweinlin
1st October 2005, 15:36
Thanx, I didn#t take a look at this list for quite some time :) But AFAIK mencoder isnīt 100% the same as ffmpeg. Or am I mistaken on this one?
hellfred
2nd October 2005, 11:19
Thanx, I didn#t take a look at this list for quite some time :) But AFAIK mencoder isnīt 100% the same as ffmpeg. Or am I mistaken on this one?
Mencoder can encode using several codecs, one is libavcodec from ffmpeg project. So when using
mencoder -ovc lavc -lavcopts vcodec=mpeg4:vpass=1:...
you will use exactly the same codec as ffmpe/ffdshow.
When mencoder was linked agains libxvid, you can encode when starting mencoder like this
mencoder -ovc xvidenc -xvidencopts pass=1:...
The manpage give you an overview of the parameters to be set, in the documentation you will find some example comandlines to do two pass encodings, and the GUIs will help you assembling your comandlines, too.
Very fine readings are the encoding-tips.txt and encoding-guid.txt from mplayers source in DOCS/tech. You can read them online via the cvs web interface here (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/DOCS/tech/?cvsroot=MPlayer&sortby=date) .
Hellfred
ReinerSchweinlin
2nd October 2005, 16:49
Ah thanx for clearing things (sagt man das so?) :)
Iīve already done some tests with mencoder, so far, xvid wins. Iīll try some more and post results, if Iīm done.
hellfred
2nd October 2005, 19:59
Ah thanx for clearing things (sagt man das so?) :)
Iīve already done some tests with mencoder, so far, xvid wins. Iīll try some more and post results, if Iīm done.
Be aware, that win32 ports of mencoder/liavcodec used to have problems with sse instructions, resulting in blocks.
Therefore, the sse instructions are normally disabled in win32 builds of mplayer/mencoder.
If the libavcodec encoded clips expose too many blocks, you could try to use a linux live cdrom to check the reason for those block artefacts. Or you can get a faster encode there, as the sse instuction set is being used.
Hellfred
ReinerSchweinlin
2nd October 2005, 20:03
Ah, that explains, why my athlon xp-compile of mplayer doesn't use sse, Iīve always been wondering why. Thanx!
Playing aruund with me MEWIG, I found several bugs and flaws. Hitting a certain bitrate is almost not possible and switching on/off turbo Settings doenīt work, qaulity is very bad und so on...
So I tried gulmencoder again, which I used a while ago. Giving some options in the commandline, it passes the parameters somehow different to mencoder, resulting in a quite nice encode (test is "for the birds" from pixar in 200kbit/s - I know, very low, but I want to emphasise on flaws).
Now scanning through the mencoder readme.. maybe Ißll find some tweaking possibilities
Leak
2nd October 2005, 21:27
Ah thanx for clearing things up (sagt man das so?) :)
Naja, fast... siehe oben. :)
np: Mouse On Mars - Frosch (Live 04)
ReinerSchweinlin
2nd October 2005, 23:42
:) Mouse On Mars muss man mit einem URPS geniessen :) Blupp, biep, tschack :)
Ok, back on/to topic:
After trying to get gulmencoder to do as I want, I switched to CL. Right now, the 4th pass of a multipass-encoding is working, tweeked almost everything mencoder has to offer. First results are VERY promissing...
few minutes later.......
Well, seems that libav hase some potential I wasnīt aware of. SO far, I got better results with mencoder than with xvid/VD. Testclip still is "for the birds" in 720 width with only 200 kbit/s.... Still testing
hellfred
3rd October 2005, 16:49
Well, seems that libav hase some potential I wasnīt aware of. SO far, I got better results with mencoder than with xvid/VD. Testclip still is "for the birds" in 720 width with only 200 kbit/s.... Still testing
It would be nice if you could provide us with your findings at the end of testing, like comand line parameters for best visual experience, small clip, etc.
Hellfred
ReinerSchweinlin
3rd October 2005, 17:29
Of course :) WHen itīs done :)
Sagittaire
4th October 2005, 14:36
My goal is to achieve max. Quality and so far, XVID is ahead of DIVX or other Codecs when it comes to best quality. Even in terms of speed, XVID outpasses most rivaling codecs. ffvfw seems to be very slow compared to xvid, but that would be fine if quality surpasses XVID.
no, no and no ... XviD is certainely not by far better than DivX6 or libavcodec asp ... lol
ReinerSchweinlin
4th October 2005, 15:34
Whatīs ur point? If u have anything usefull to say, please do so. Flaming around isnīt helping.
bond
4th October 2005, 15:39
guys cool down :)
DeathTheSheep
4th October 2005, 23:25
I guess basically he's saying he believes that XviD is better than both DivX6 and ffvfw, but not by very much.
I'd have to say I agree with what looks better for each particular source.
For most DVD rips, XviD is claimed to be the "best ASP codec" but that view is very subjective.
A big advantage of ffvfw is its masking features (such as P-block masking, complexity masks, chrominance, etc) and quantizer noise shaping, both of which help visual quality at lower bitrates, and both of which are features XviD doesn't have.
XviD, however, is generally accepted as the best in maintaining detail and overall metric quality (PSNR), especially at lower quantizers (higher bitrate).
I hope I've given you a base you can use to choose.
Cheers,
ReinerSchweinlin
5th October 2005, 02:31
Yes, thatīs exactly my impression so far, too. My goal is to get familiar with the libav's features such as the masking (temporal and spacial, rate distortion, etc) in order to achieve a better quality in low-bitrate encodes. Before starting tests, xvid "won" every comparrison I did.
One thing I was wondering about:
When doing two-pass encoding, I accidently turned on all masking features in the first pass and switched them off completely in the second one (everything else standard with :vhq:) . This seemed to work quite well on my testclip (for the birds - pixar) in slow motion scenes at the beginning of the encoding. High-Motion seemed to make no difference compared to leaving everything to default vhq in 2-pass mode. But the one strange thing now is: The Credits at the end turn out sooo bad, it almost seems that the distribution-rate of bitrate degrades from the beginning of the test to the end.
Any ideas on this one?
CruNcher
5th October 2005, 02:31
@DeathTheSheep
Don't forget that libavcodec ASP is still the only one that supports AQ for B-Frames ;)
ReinerSchweinlin
5th October 2005, 02:59
U mean :naq: ?
Howīs impact on quality of this one? So far I see no difference. Isn't this just tuning the Block-quant to average frame-quant? Seems to have slight effect on filesize though. Maybe I have to use another testclip :)
aeternitas
11th October 2005, 18:56
no, no and no ... XviD is certainely not by far better than DivX6 or libavcodec asp ... lol
In all the testing ive done Divx is not as good as Xvid. This is made more clear at low bitrates than high. It may be your lack of correct xvid settings. Comeing from someone that uses VP6 or RV10 for anime encodes, your advice seems to be several years late.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.