x264 MUCH better quality than XviD?

[HeadBangeR77]

Hope i didnt come accross as a wanker, i am no expert by any means :( I have tried most combinations known to man with x264 and i just have to compromise i think.

I wouldn't say so. :D ;)
Since there are some H.264 gurus here, I asked them for sample encodes. I really don't know how they would come out in terms of quality throughout the whole film, since they were all sample specific. The truth is, with XviD you can retain some grain almost right out of the box, and with some knowledge on CQMs you can retain most of it. I think more codec-specific knowledge is needed to achieve similar effect with e.g. x264.

I'm planning to encode the whole film with very gentle deblocking, denoising, and some sharpening - will see how it comes out. ;)

cheers.

[Sharktooth]

You cant simply use RDO and expect to be able to keep grain...
Didnt you learn from Xvid? The higher the VHQ the lower the grain/noise the encoder keeps.
Look at the QuickTime trailers. Expecially 300 (the movie). There is a huge amount of noise and h.264 was perfectly able to keep it because the QuickTime encoder does not support advanced compression options (rate/distortion optimizations...).

[HeadBangeR77]

@ Sharktooth:
Excuse me, but to whom did you write the above?

In case it's addressed to me:
- I've marked Qpel helps with grain, and it's higher quarterpixel motion estimation precision, isn't it? ;)
- I agree that higher VHQ than 1 has negative effect on filmgrain, nevertheless I've managed to retain much of it in 2-pass encodes with VHQ=4 in the 2nd one.
- I was just wondering how setting motion estimation to fullpel or halfpell with x264, in order to aid the grain retention, would come out quality wise throughout the whole film, since I don't know and I'm not capable of doing a proper grainy encode with x264.

I've seen many QuickTime trailers and they are grainy (though I wouldn't use their H.264 unless they paid me for it :D), indeed. Now I know why - thanks. :)

[Gilron]

HDBR, I also tested Didee's SixOfNine - it was good but xvid in general did good grain-wise, no matter which matrix there was in use.

FGT sounds something interesting - I hope it will get implemented in h.264 encoders, at least I haven't been able to get good grain with x264 yet. There's always the option of adding noise after decoding but I wouldn't like to start adjusting noise parameters when I want to watch a movie. Just click and play. :)

For me, at low bit rates I've found h.264 is unbeatable - at higher bit rates the gap narrows and as the type of the movie also has an effect it becomes very hard to decide which one to use in general DVD backups. To sum it up - it seems to be more difficult to get a good encoding with x264 than with Xvid. But of course, this is just my opinion based on my experience. :)

Cheers!

[R3Z]

You cant simply use RDO and expect to be able to keep grain...
Didnt you learn from Xvid? The higher the VHQ the lower the grain/noise the encoder keeps.
Look at the QuickTime trailers. Expecially 300 (the movie). There is a huge amount of noise and h.264 was perfectly able to keep it because the QuickTime encoder does not support advanced compression options (rate/distortion optimizations...).

Thats all well and good, but when i turn off RDO and limit the motion estimation as well as vector range to stupidly low values it makes little difference.

I am not just limiting my tests to x264.

[Revgen]

Hi,

I noticed the interesting discussion about grain retention here and decided to post my results of my own testing I did some time ago. The driving factor behind the tests was the normal "which encoder to choose for my DVD backups". The source material in tests is ripped from DVD, encoded without resizing into anamorphic format with different kinds of encoder options (x264 and xvid) and then resized with Lanczos4 in AviSynth to normal AR. The encodings were based on MeGUI default profiles (changed matrices, switched deblocking off, tried deadzones etc.)

You can find the screenshots HERE (http://temppeli.ton.tut.fi/~roger/codectest/). I didn't find it easy to decide which format to use - both have their pros and cons. To me it seemed like deadzones had little effect on grain.

Cheers!

--G

Ohter then the "XviD MeGUI preset 58% HQ" matrix, the "X264 CRF24 No Deblocking Sharktooth" matrix looked the most pleasing to my eyes. Blocks look more evenly formed and don't stand out as much.

[HeadBangeR77]

@ Gilron:
I've just taken a closer look at your files. As to the 1st one, the 58% XviD preset did the best job imo, since the 90% one isn't so much different to justify the jump in the file size. I prefer the Sharktooth's matrix samples to the M4G ones. The "HQ-Slow" is so derived of grain [b]and[b] textures I couldn't stand looking at it. ;)

As to the second sample: what happened with x264? :eek: The image is distorted and very blocky ... That's why I've asked if some of those sample-specific x264 settings made sense for encoding a whole film, e.g. with no de-blocking and low motion estimation precision (???).

cheers,
HDBR77

[*.mp4 guy]

That blocking looks like the coravc blocking error.... and which of my matrices did you use, there is more then one.

[AlexW]

I was just wondering how setting motion estimation to fullpel or halfpell with x264, in order to aid the grain retention, would come out quality wise throughout the whole film, since I don't know and I'm not capable of doing a proper grainy encode with x264.

Note that x264 always performs motion estimation on halfpel and quarterpel even if you use subme 1, the difference is that subme 1 performs the subpel refinement after mode decision and uses SAD as the error metric instead of SATD which is used for quarterpel search/refinement in subme 2 - 6.
So if subme 1 really is better at preserving film grain then it might be due to the use of SAD in the subpel search.

[Gilron]

XviD 58% was my own favorite too when it comes to "transparent" quality. I also noticed that distortion with x264 in second test - decoder was CoreAVC so it is possible it's caused by a bug. Should test with another decoder...

M4G, your matrix I used was v31_high_detail. Sharktooths matrix was EQM-AVC HR.

Cheers!

--G

[Sharktooth]

@ Sharktooth:
Excuse me, but to whom did you write the above?
...
It was for R3Z in consequence of his post:Not knocking Didee, but h264 isnt able to do it even with the bitrate being higher. That really throws that conclusion out the window.

Something being more efficient doesnt exactly help if its throwing away important details at the same time. I have already tried compressing grainy uncompressed material with massive overkill x264 settings (we are talking 8 mbits for 720 x576) and moderate-high mpeg 2 settings (6mpbs) and there is no comparison. The mpeg2 comps are able to keep the majority of grain, noise and high end detail.

This is a well known problem or setback with h264, documented widely accross this very forum.

I also get pissed when people tell me that you are confusing grain and detail with noise, dont tell me what i can and cant see.

I think the only way this is going to be fixed is in the direction of film grain synthesis, though it seems people these days want that clean digital look to all their films - even the old ones captured in analogue :eek:

Dont get me wrong, i am not downing on x264 - i understand i am the minority here and a compromise is good enough for me.

[steve77]

Being the original OP I'll go ahead and say you guys are now way out of my league. I read over the bulk of the past pages briefly and am really amazed with the time taken to to these tests.

Thanks!

So basically, to sum it up briefly, for a high bitrate backup XviD is best but for a low quality backup x264 comes out on top, right? I know it's a little simplistic to summarize your 9 pages of effort in 3 lines but as stated, I'm just not at the level where I fully understand all of the intricacies of vid. encoding.

I'll re-read it a couple of times, and try some tests of my own very soon.

[foxyshadis]

Not so much "best" but definitely easier to get good retention of nitty-grittiest details, compared to x264 and other AVC codecs. AVC seems to be so geared toward lower bitrates that you really have to pick and play with the internals to get grainy results.

For clear, easy stuff AVC pretty much always wins, whether it's at high or low bitrates. (Although you might not be able to tell if it's high enough.)

[HeadBangeR77]

Note that x264 always performs motion estimation on halfpel and quarterpel even if you use subme 1, the difference is that subme 1 performs the subpel refinement after mode decision and uses SAD as the error metric instead of SATD which is used for quarterpel search/refinement in subme 2 - 6.
So if subme 1 really is better at preserving film grain then it might be due to the use of SAD in the subpel search.
Thank you very much for so detailed explanation. Sagittaire didn't explain the matter, though for him it could have been obvious, yet not for me.

@ Sharktooth:
Clear. Ta. ;)

@ *.mp4 guy:
Could it be the same bug with different deblocking values as before in this thread, or some new devilry of CoreAVC? How could decoding be so ... distorted (I was going to write sth stronger here ;))?

@ foxyshadis:
Perfect summary. :)

[*.mp4 guy]

It looks like the same bug, but since deblocking was disabled in some of the screenshots that had the distortion it could also be something else, I don't use coreavc so I'm not the best person to ask.

[ToS_Maverick]

i did a lot of testing on this topic on my own during the last days. unfortunatly i don't have the time to do such an outstanding comparison-page as Gilron did.

anyway, i think i finally got x264 to the point where we can say it's transperent :cool: :D

i mostly tested with a comp check from the movie "SAW", which is VERY grainy, with all kinds of grain, soft, hard, in the middle, DIRTY walls, in one word: great ;)

i downloaded the black pearl samples and i think it really looks good. please check my settings and give me some feedback.

Black Pearl Sample, Settings and Size:

XviD V3HR @ Q3 gave me 30 MB

my "transparent" setting, 49 MB

--crf 20.0 --level 3 --deadzone-inter 3 --deadzone-intra 2 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 10000 --threads auto --thread-input --progress --no-dct-decimate --output


same a tad smaller with deadzones 6,4, 44,7 MB

--crf 20.0 --level 3 --deadzone-inter 6 --deadzone-intra 4 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 10000 --threads auto --thread-input --progress --no-dct-decimate --output


my "same size as V3HQ and almost same quality" setting, 32,4 MB

--crf 22 --level 3 --deadzone-inter 6 --deadzone-intra 4 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 10000 --threads auto --thread-input --progress --no-dct-decimate --output


note that i use --subme 1, this means, grain almost as good as the original, and lightning fast encoding speed, at least with my machine. here are the examples:

XviD: ~25 fps
x264: ~50 fps

i look very much forward to hearing comments from you guys. hope you like it :D

PS: screens here
originial:
http://img169.imageshack.us/img169/561/bporigti5.th.jpg (http://img169.imageshack.us/my.php?image=bporigti5.jpg)
"transparent" coded
http://img169.imageshack.us/img169/6391/bpcodeddq4.th.jpg (http://img169.imageshack.us/my.php?image=bpcodeddq4.jpg)

[*.mp4 guy]

Please host the actual encode somewhere, there are a lot of things that can't be determined from screenshots alone (although your screenshot definately looks impressive).

If you don't know any hosting sites try mytempdir, megaupload and rapidshare, mytempdir is the best, but only for files under 50mb in size. Just google the names and the apropriate site should be at the top of the results.

[bkman]

ToS_Maverick: Very interesting settings and results. Some of my own tests show that with these settings, x264 keeps the appearance of noise even at higher quants. I find it looks better than Xvid at equivalent bitrates now in terms of noise and overall detail. Who'd have thought that x264 was so flexible? :cool:

[markrb]

i did a lot of testing on this topic on my own during the last days. unfortunatly i don't have the time to do such an outstanding comparison-page as Gilron did.

anyway, i think i finally got x264 to the point where we can say it's transperent :cool: :D

What matrix did you use?
One other thing if you will.
In MEgui where would I modify it to get "--deadzone-inter 3 --deadzone-intra 2"
I was able to modify everything to match pretty much except for that.

Thanks
Mark

[Sharktooth]

The latest MeGUI version supports deadzone settings.
They're in x264 config in the advanced tab.

[ToS_Maverick]

Please host the actual encode somewhere, there are a lot of things that can't be determined from screenshots alone (although your screenshot definately looks impressive).

i'll try to do that, i hope it will be soon, as i may not have the time today to get it done ;) as i mentioned in my previous post, please try it yourself and encode the sample on your machine, if it comes out at 49 MB, it should be right.

maybe someone else could code the sample while i'm at work and host it, so that the others can play around with it?

What matrix did you use?
One other thing if you will.
In MEgui where would I modify it to get "--deadzone-inter 3 --deadzone-intra 2"
I was able to modify everything to match pretty much except for that.

that's the standard matrix. some time ago i tested CQM in x264 but didn't like the fact, that i have to use bpred = none.

i gave you the complete settings, nothing else was used.

[HeadBangeR77]

@ ToS_Maverick:

You've appeared in crouching-tiger-hidden-dragon-style! :D
If I had to judge on a basis of one screenshot (plz save as png next time, as I don't trust jpegs, even if they are of high quality), I would say your encode is really perfect, considering the higher size of the other samples: my 45-46MB ones were 2-pass encodes, 1-pass encodes utilized higher bitrate.

I think everybody was at least surprised to hear you had used the standard flat matrix for the encode. ;) :devil:

cheers,
HDBR77

@ mp4 guy:
Didn't you use subme 6 for your best sample?

[Sagittaire]

I think everybody was at least surprised to hear you had used the standard flat matrix for the encode. ;) :devil:


Why ... ???

-> Grain and noise are high frequencies.
-> If you want preserve grain/noise you must use no agressive matrix for high frequencies.
-> Flat16 is not agressive for high frequencies
-> x264 is optimized to work with flat16

[Manao]

Technally speaking, white noise isn't high frequencies. And i have seen grain being as big as 3 pixels, and that's not high frequencies either.

[ToS_Maverick]

@HeadBangeR77:
i read doom9 on a daily basis, especially the AVC-Board. i'm glad i could help you on this matter, since normally i can't be of any help :(
i'm just interested in getting the most out of my x264 encodes :devil:

about the screens: it was late yesterday, i just wanted to post the screens, they are at the highest quality jpeg setting. if i have the time, i'll add a few more, maybe in png

@Sagittaire:
i agree with you, that x264 is optimized for flat16. about the grain i'm not so sure, since x264 kills alot of it at higher subme settings.

[HeadBangeR77]

@ Sagittaire:
In this particular case I had better results with Heini's 6of9, that compresses high frequencies more, but middle and low less, than with Didee's SixOfNine, which is by far more flat. Yet the sample was very specific, 'cause it had various kinds of noise & grain & dust & debris all floating in the air. ;) Stronger filtering of middle frequencies with fft3dfilter showed similar results - at least more grain was removed. But, as already said, this sample was a killer (also in terms of poor quality).
On the other hand I had really good results with Soulhunter's V3, which inter-part is all flat (16).

@ check:
I wouldn't assume anything, until we have created a commission and examine the matter under a good microscope. :p ;)

[check]

I would assume dust is very flat :)

[ToS_Maverick]

ok, here i'm again, this time with more screens, and a little summary after more testing ;)

during my analysis i tried to find an x264 equivalent to XviD Q3 with the 6of9 and V3HR matrix. i think most guys know teegedeck's profiles, which are based on this matrices.

my final commandline:

--crf 20.0 --level 3 --deadzone-inter 9 --deadzone-intra 6 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 10000 --threads auto --thread-input --progress --no-dct-decimate --output


the filesizes are:
XviD V3HR @Q3: 30.0 MB
x264 (my cmdline) @CRF22: 29.5 MB

XviD 6of9 @Q3: 40,7 MB
x264 (my cmdline) @CRF20: 40,8 MB

this commandline is a compromise between higher quantizer and higher deadzone settings. for example, these settings are equivalent in filesize:

CRF20 deadzones 9,6
CRF21 deadzones 4,3
CRF22 deadzones 0,0

deadzone 0,0 might sound cool, but for my taste, the film-look isn't homogeneous anymore. grain pops out of nowhere and vanishes, which i find very irritating. xvid on the other hand, looks grainy, but it is a kind of a static grain.

ok, let's get to the screenshots

XviD 6of9
http://img482.imageshack.us/img482/3063/8166of9lk6.th.png (http://img482.imageshack.us/my.php?image=8166of9lk6.png)

CRF 20:
http://img374.imageshack.us/img374/6342/816crf2096qk3.th.png (http://img374.imageshack.us/my.php?image=816crf2096qk3.png)

XviD V3HR:
http://img255.imageshack.us/img255/526/816v3hr2dy9.th.png (http://img255.imageshack.us/my.php?image=816v3hr2dy9.png)

CRF 22:
http://img374.imageshack.us/img374/9012/816crf2296km9.th.png (http://img374.imageshack.us/my.php?image=816crf2296km9.png)

this is a worst-case part, where x264 drops most of the grain. after all, x264 still looks a bit inhomogenous and sometimes washed out. xvid has it's sertain look, that is a bit more true to the original.

so why should someone use x264 at this compression ratio? normally x264 is being used, when high compression is needed, and it gets the job perfectly done.
the answer is: SPEED

at this settings, x264 is AT LEAST twice as fast as xvid. this might sound strange, but it's true. i'm not quite sure why, maybe my core2duo might be the reason.

finally, i would appreciate all feedback you guys have. code your samples with these settings, try things out, maybe we find even better settings. the next step surely would be, to try some matrices, anyone ;)

[HeadBangeR77]

Hello, ;)

I don't doubt x264 is faster with subme 1. Since I'm a humble 1-core user , I don't pay attention if any application or a specific encoder support multi-threading. Is x264 capable of this (forgive my ignorance, AFAIK it is, yet I'm not utterly sure)? If you would like to check how XviD behaves, then use the latest Celtic Druid's builds, which support MT as well.

Just one more question concerning codecs: since I feel free to modify XviD pre-sets for my own use, what settings exactly did you use for XviD 1-pass samples?
Btw. looking at my encodes I consider V3 HR at Q3 way far from being transparent - it smooths too much and eats too much grain imo.

Finally: Mate, I'm dying to see your larger sample! :D Could you upload it to Rapidshare or another hosting site? My shared a-DSL was squealing when I was uploading my samples, yet I've managed that with 8KB/s upload speed. ;)

cheers and good night ;)
HDBR77

[ToS_Maverick]

i tried to upload the file, but it didn't work. i'll try it tomorrow.

anyway, why don't you code the sample by yourself? IIRC you posted the .m2v, so just use megui/x264 with my settings. if you plan to use it further, you'll sooner or later have to generate a profile anyway ;)

good night from austria too :)

edit, my xvid settings (copied from teegedeck's thread):
CQ=3, MSP=6, VHQ=4, VHQ for b-frames, Qpel, SixOfNine, quantizer-restrictions min. 3, max. 5 (4 for I-frames), chroma ME, Trellis, chroma opt., b-frames: max. 2 consecutive, ratio 1.62, offset 0

[CruNcher]

@ToS_Maverick
just disable Qpel and see XviD fly away contra is less detail preservation (grain) facial details high frequency and other objects most of the time, but rarely visible for untrained eyes or without haveing comparision material ;)
it should be faster then by a factor of 2-3x times (Qpel is really bad balanced in ASP time/quality)

[ToS_Maverick]

oh, thx for the tip, i'll try that as soon i have time for it ;)

during my tests with SAW,i tried XviD with no QPel. the picture was, as you said, less detailed. because of that, i always use QPel.

XviD with QPel is already not as sharp as x264, but without QPel... i think x264 will be the winner then :D

[CruNcher]

@ToS_Maverick
jep that's because in H.264 the Qpel implementation is much more efficient (you learn from mistakes) and faster also :)
it's no secret that Qpel,GMC allways where seen as bad balanced in ASP also the cause why 1st Generation Standalones had no support for both no manufacture wanted to implement it at first because of the power it needed for the less quality improvement it was resulting in it's like you put 3 times the effort into it and get 1% improvement out of it (not economicaly and also HVS wise efficient).

[shon3i]

during my tests with SAWSaw is hell noise movie, like war of the worlds, in that cases, crf 10 maybe not good enought.

[HeadBangeR77]

edit, my xvid settings (copied from teegedeck's thread):
CQ=3, MSP=6, VHQ=4, VHQ for b-frames, Qpel, SixOfNine, quantizer-restrictions min. 3, max. 5 (4 for I-frames), chroma ME, Trellis, chroma opt., b-frames: max. 2 consecutive, ratio 1.62, offset 0

It's no wonder then that XviD was so much slower than x264. :P ;)
Did you use the MT-capable version of XviD btw (the already mentioned Celtic Druid's latest build)?

You've used it with all the goodies turned on, while x264 with most of the goodies turned off. The presets are there for 2-pass encodes, and it's written there explicit, as a warning. The settings you've used are meant for the 2nd pass.

From my experience: MSP=4 or 5, VHQ=1, VHQ for b-frames are usually enough to get a decent 1-pass encode with good matrices at quantizer 2 or 3. However my samples were all done with QPEL (links are still active).

Without QPEL it goes at 30fps and higher on my system, with QPEL about 20fps (or faster), with the settings quoted about 10fps for the given resolution. More exact values for the given source are somewhere in this thread. ;)

XviD with QPel is already not as sharp as x264, but without QPel... i think x264 will be the winner then.
You're absolutely right about this. :)

cheers,
HDBR77

[ToS_Maverick]

encoded the sample with 6of9 MSP6 VHQ1 and without QPel @ 50 fps. with x264 i got 60 fps, still a bit ahead :D

with these settings my prevous estimate is right, x264 is slightly ahead, but please, judge for yourself. anyway here's a screen of the xvid encode:
http://img266.imageshack.us/img266/2584/8166of9wp7.th.png (http://img266.imageshack.us/my.php?image=8166of9wp7.png)

@HDBR77: have you already done an encode with my x264 settings? i'm currently uploading the file to my ftp, i'll edit this post when it has finished

alright, here's the file on my webspace, will be deleted in the near future:
http://www.infinitpower.com/files/Black.Pearl.Sample%20mav%20crf20%209,6.mp4

[Inventive Software]

My word, what the hell did this thread turn into? :D

I'll chuck my own encoding into the mix then. ;)

This is a comparison video of Formula 1 against Grand Prix 3 (links: Xvid (http://mihd.net/xsye4w), x264 (http://mihd.net/08z14x)). Traditionally, I've had real trouble just getting the GP3 footage to encode decent at all with Xvid, and so often x264 wins out, even when Xvid is encoded with a higher bitrate. Case study: Xvid (http://mihd.net/bumaxv), x264 (http://mihd.net/g5m63t). Same settings were used here as for the comparison videos, except target bitrate was 1200 kbits/sec and 8 refs and 8 b-frames for x264, and 1500 kbits/sec for Xvid (Xvid couldn't hit that, instead going to around 2000 kbits/sec, but even that couldn't look as good as x264 ;)).

Settings for Xvid were as follows: 2-pass encode, Adaptive Quantization, H.263 Quantization, ASP@L5 limitation, 4 consecutive BVOPS, QPel, target bitrate 2000 kbits/sec, ME 6, VHQ 4, VHQ for B-frames, Use Chroma motion, Keyframes distance 250, Keyframe at beginning of encode.

Settings for x264 (taken from stats file): cabac=1 ref=6 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=7 brdo=1 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=0 mbaff=0 bframes=6 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=2000 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30

The way I strung the two videos together was via AviSynth (and I wish I'd had MT for Xvid, as it hovered around 50% CPU usage for the whole encode :D). The script for the GP3 part loaded a set of images exported via GPxPatch and GP3 (those who play will know what I mean ;)), resized it to 512x384, converted the framerate to 25 FPS and converted the colourspace from the original RGB to YV12. Audio was recorded with good ol' Sound Recorder from in-game on 98 (I hear *ouch* going around the forum as I write that, especially from renouned 98 hater Doom9 :D), and merged with the F1 hotlap in Audacity. The F1 lap is Button's pole position lap in Australia, originally encoded into DivX at 1200 kbits/sec, 512x384 by Berger_fan at f1archives.com. I don't know what settings he used, but I think it was balanced cause I know he doesn't like to wait around. So the encoder has the challenge of re-encoding some already fairly heavily compressed real-life fast-moving footage without losing too much quality. The AviSynth script to put the 2 side-by-side involved StackHorizontal. Audio was added into VirtualDub and encoded with LAME @ 96 kbps CBR.

Make of it what you will. My opinion is that, even with deblocking on, Xvid can't hit x264's quality, reflecting the thread title and my own opinion that x264 has better quality IMHO and in certain situations, gaming included. ;) Only with significantly higher bitrates (as much as 10x in some cases) can Xvid get anywhere near x264's quality. x264 @ CRF 16 is similar to Xvid @ Q2 from a test I did several months ago, if my shaky memory serves me correctly.

[HeadBangeR77]

@ ToS_Maverick
Hi! Then it was 50fps verse 60 fps, not two times slower. :p ;)

I was getting familiar with MeGUI yesterday (the Lemming's one doesn't support dead zones, unless I was so tired I couldn't see), but gave up in favour of testing de-halo from fft3dfiler. :D
Thanks very much for the sample - I'm gonna wait till darkness to watch it in my standard-viewing-conditions. ;)

@ Inventive Software
We were not talking about gaming footage, which makes over 80% of your post, and is very specific content, as you most probably know. It could be as smooth as silk, and no one would give a damn.
We were talking about specific film content with much noise and grain, because this is the one field where XviD is capable of competing with x264 (even if the first looses a bit). I think the guys from the x264 have benefited from the thread in terms of finding the right settings, which wasn't so easy at all. In case you haven't noticed, nobody was trying to prove the contrary (I mean the thread's topic). So, being really in good mood today, I haven't got the faintest idea what you're laughing at. :D

Only with significantly higher bitrates (as much as 10x in some cases) can Xvid get anywhere near x264's quality.
I consider the above whole lot over-exaggerated, if not a nonsense.

x264 @ CRF 16 is similar to Xvid @ Q2 from a test I did several months ago, if my shaky memory serves me correctly.
I depends on so many variables, settings, kind of content, and the quantization matrix used, that I would never dare to generalize in such a manner. I don't think you understand much about CQMs, no offence, correct me if I'm wrong. ;)

cheers,
HDBR77

[Inventive Software]

So, being really in good mood today, I haven't got the faintest idea what you're laughing at. :D
Fair enough. I just thought I'd chuck another variable into the mix and see how it came out. :P


Quote:
Only with significantly higher bitrates (as much as 10x in some cases) can Xvid get anywhere near x264's quality.

I consider the above whole lot over-exaggerated, if not a nonsense.
And you think I don't know about video encoding? ;) I've been here longer than you have, and seen Xvid and x264 along the way, so don't say over-exaggerated. (That's how I see that BTW, nothing against you, just be very careful what you say. I bite. ;)) Besides, I did say it was roughly estimated. I think I managed to get transparancy with Xvid at around Q2, x264 I think was CRF 18, but was probably CQ16 or something, as I hadn't discovered CRF at the time...

I depends on so many variables, settings, kind of content, and the quantization matrix used, that I would never dare to generalize in such a manner. I don't think you understand much about CQMs, no offence, correct me if I'm wrong. ;)
Ah, tis where you and I differ. I dare generalise because I fear NOBODY! :D Plus, being really specific has the effect of being, say, anally retentive, and I'm not like that. If I can understand what I write, I consider 90% of my audience to understand me, since I often have trouble reading into what i write. I do know CQMs for the record. I just choose not to use them, since I'd have no idea which one would fit my profile, and I don't really have the time or energy to find one. Consider yourself corrected. ;)


Yes, game footage makes up around 80% of my post (I think 70%, but I'm being pedantic there :D), but there was also another factor there that it appears nobody picked up on, and I made great pains to mention. There was already fairly heavily compressed real-life footage there that Xvid couldn't re-encode without it blurring or blocking significantly. x264 could, and this is one of it's strengths IMHO.


BTW, did you download the videos? If so, what did you think? :)

[ToS_Maverick]

@HDBR77: just get MeGUI from here (http://forum.doom9.org/showthread.php?t=96032) and let it download the newest updates. get Sharktooth's and Teegedeck's profiles, and you're ready to go ;)

i usally encode x264 with megui. since i'm accustomed to it, i also use it with xvid (in megui it is implemented via xvid_encraw).

i look forwart to hearing your comments at night :D

[Sagittaire]

I depends on so many variables, settings, kind of content, and the quantization matrix used, that I would never dare to generalize in such a manner. I don't think you understand much about CQMs, no offence, correct me if I'm wrong.

and you ... ???

Don't forget that for a large majority of user H263 quantisation is the best visual way. H263 is always in best group with blind test. H263 is always the default quantisation for all the MPEG4 ASP codec. IMO most of the time the CQM are only placebo effect for a large users majority (legend of CQM with magical HVS coef ... lol). The only way to test CQM is blind test. Make blind test and see the result.

[HeadBangeR77]

And you think I don't know about video encoding? ;) I've been here longer than you have, and seen Xvid and x264 along the way, so don't say over-exaggerated. (That's how I see that BTW, nothing against you, just be very careful what you say. I bite. ;))
No, I don't think so, 'cause it would be over-interpretation. I just said you didn't seem to know much about XviD CQMs, and still I think I wasn't very far from the truth. If being registered here is some kind of measure in your opinion, then fine, think what you want.
I consider your statement:
"Only with significantly higher bitrates (as much as 10x in some cases) can Xvid get anywhere near x264's quality."
as over-exaggerated, and it's my opinion. You can't tell people what they should say and think, unless you're playing Adi Amin Dada. (http://en.wikipedia.org/wiki/Idi_Amin) :D

Ah, tis where you and I differ. I dare generalise because I fear NOBODY! :D Plus, being really specific has the effect of being, say, anally retentive, and I'm not like that. If I can understand what I write, I consider 90% of my audience to understand me, since I often have trouble reading into what i write. I do know CQMs for the record. I just choose not to use them, since I'd have no idea which one would fit my profile, and I don't really have the time or energy to find one. Consider yourself corrected. ;)
Now you're being amusing. :)
I don't have the problem, since I'm not tied to any profiles. The CQM of my choice depends on the source and bitrate I can spare.

Has anyone here ever said XviD could compete against x264 either with encoding or transcoding heavily compressed footage? It's obvious it can't, and H264 is the best choice in such a case, and we weren't busy with low-bitrates for the last few pages.

I was uploading sth, now I'm downloading your samples, gonna have a look at them in the evening.

cheers.

PS. @ Sagittarie:
LOLing again, huh? :D Glad you're having fun. :)
Btw. CQMs should be used with different bitrates and different types of content imo, so testing them at fixed bitrate doesn't make much sense imo. Call it placebo or not, it's working.

[DarkZell666]

IMO most of the time the CQM are only placebo effect for a large users majority.... triple lol. I would have never thought I could hear such a thing considering all the testing that has been done (particularly in this thread) regarding CQM's.

Fancy quantisation being a placebo process ... I love the idea :D

[*.mp4 guy]

Back a while ago Soulhunter ran a few double blind cqm comparisons (for xvid), while the differences weren't always huge, they were there, link (http://forum.doom9.org/showthread.php?t=90785).

In the test I linked I rated them:

Hybrid8aq-3.9
h.263-3.2
Jawors 1CD-3.6
Soulhunters v8-3.7
EQM v3 ULR-3.8

and said:
they were all very similar. except number 2 [h.263] which was too smoothed out for my tastes.

This was using double blind testing methadology, and viewing on a cheap 1024*768*75hz crt, so to say that its a placebo and that I (or anyone else) can't see the differences between matrices is a bit farfetched.

[Inventive Software]

OK HBR77, I admit I wrote most of that reply on impulse, trying to make a point, only badly. :D

What I *should* have meant by this statement:
Only with significantly higher bitrates (as much as 10x in some cases) can Xvid get anywhere near x264's quality.
I should have meant with reference to my games footage encoding. Sorry if that came across wrong. ;)

I may have to experiment more, especially with CQMs, when I find the time, but I really just wanted to chuck another factor in, since it gets overlooked a lot IMO.

[HeadBangeR77]

@ Inventive Software:
You've made one very good point. Since we were busy with some grainy and noisy sources, one might have forgotten this topic isn't restricted to such a footage at all. ;)

The idea of encoding games at real-time (or transcoding, from FRAPS for instance) is really new to me (I used to play mostly RPG /cRPG and real-time strategic games). I first came across such a thing about a few weeks ago, when I was helping a guy with some matroska-muxing issues, and he uploaded a sample (x264 btw.). I may only assume that XviD really can't compete on this field, especially when the footage is heavily compressed.

As to CQMs:
I remember Soulhunter has done many comparisons like that, at different bitrates, and the last one has never ended because of lack of interest. I was there at the time, though not registered. ;)

[Sagittaire]

Back a while ago Soulhunter ran a few double blind cqm comparisons (for xvid), while the differences weren't always huge, they were there, link (http://forum.doom9.org/showthread.php?t=90785).

In the test I linked I rated them:

Hybrid8aq-3.9
h.263-3.2
Jawors 1CD-3.6
Soulhunters v8-3.7
EQM v3 ULR-3.8

and said:
they were all very similar. except number 2 [h.263] which was too smoothed out for my tastes.

This was using double blind testing methadology, and viewing on a cheap 1024*768*75hz crt, so to say that its a placebo and that I (or anyone else) can't see the differences between matrices is a bit farfetched.


well always very better to post the complete test:

Custom Matrix comparison - V2 (blind test)
http://forum.doom9.org/showthread.php?p=540969#post540969

Custom Matrix comparison - V3 (blind test) - 900 Kbps
http://forum.doom9.org/showthread.php?p=570152#post570152

Custom Matrix comparison - V3 (blind test) - 1600 Kbps
http://forum.doom9.org/showthread.php?s=&postid=578992#post578992



.... triple lol. I would have never thought I could hear such a thing considering all the testing that has been done (particularly in this thread) regarding CQM's.

Fancy quantisation being a placebo process ... I love the idea


Well speak about that with dev if you want. If it's obvious that the CQM offer a superior quality then why these CQM are not the defaut matrix in XviD, DivX, Nero ASP, Libavcodec ASP, 3ivX, x264 HP, Nero AVC HP, Mainconcept AVC HP ... ???

IMO CQM is placebo effect for a very large users majority. There are not magical CQM good in all situation. In the general case H263 quantisation will be the best overall HVS solution for ASP, in the general case flat16 will be the best overall HVS solution for AVC.

And Grain Retention for x264 is really not a problem for flat16 and it's really not a problem for H263 quantisation too.

[HeadBangeR77]

I've read the threads you linked to, though a long time ago. And I still say it depends on our expectations. If I like to encode a 2-hour 16:9 anamorphic widescreen NTSC material like my crappy source above, and choose 3CDs (just for orientation, 'cause I rarely split), I would never use H.263 in my life, because it's smoothing too much, and I would probably get an undersized file, unless I set Q1 as minimum for all frames. Point.
If I really had to squeeze a shorter source on 1-CD, I would give it a try at least, 'cause this quantization has its uses, but I don't encode at low bitrates as a rule.


Well speak about that with dev if you want. If it's obvious that the CQM offer a superior quality then why these CQM are not the defaut matrix in XviD, DivX, Nero ASP, Libavcodec ASP, 3ivX, x264 HP, Nero AVC HP, Mainconcept AVC HP ... ???
Thinking, huh?

I can only speak of XviD:
1) Compatibility with standalone players is a huge issue with CQMs, and only the standard ones have a guarantee to play on every crappy and outdated piece of junk (like I own :D), provided the rest was configured correctly (Qpel/no Qpel, 0/1/2/ B-frames, PB/no PB etc.).

2) Piracy, for obvious reasons (H.263 compressibility), makes it popular.

Not only XviD:
3) An average, let's call it universal low-middle bitrates matrix, lets an average Joe make an average encode. We're here a bunch of freaks, who want to get more.

There are not magical CQM good in all situation. In the general case H263 quantisation will be the best overall HVS solution for ASP, in the general case flat16 will be the best overall HVS solution for AVC.
1st sentence is a pure truism, and you know that.
2nd sentence is more or less true IMO, in case of an average Joe.
3rd sentence - I know too less about x264 CQMs to even dare to write anything.

And Grain Retention for x264 is really not a problem for flat16 and it's really not a problem for H263 quantisation too.
Why did you recommend and used your custom matrix then for the purpose of the above tests?

Sure, H263: it will keep the largest possible grain (like 2-3 pixels) in some scenes, however it will wash out 5 of 10 spots on a face (or arse, depending on the film's genre :D).

[Sagittaire]

I've read the threads you linked to, though a long time ago. And I still say it depends on our expectations. If I like to encode a 2-hour 16:9 anamorphic widescreen NTSC material like my crappy source above, and choose 3CDs (just for orientation, 'cause I rarely split), I would never use H.263 in my life, because it's smoothing too much, and I would probably get an undersized file, unless I set Q1 as minimum for all frames. Point.
If I really had to squeeze a shorter source on 1-CD, I would give it a try at least, 'cause this quantization has its uses, but I don't encode at low bitrates as a rule.

[3 cd + XviD + 576p + DVD source] is really strange and useless way.
[3 cd + h264 + 720p + HDTV source] will done and really by far better quality.

Size/quantisation scaling is not H263+ASP problem. It's only a H263+XviD problem.



I can only speak of XviD:

Why?
Libavcodec ASP is by far more configurable ASP codec. You can choose if you want ME function to preserve noise ... ect ect ect


1) Compatibility with standalone players is a huge issue with CQMs, and only the standard ones have a guarantee to play on every crappy and outdated piece of junk (like I own :D), provided the rest was configured correctly (Qpel/no Qpel, 0/1/2/ B-frames, PB/no PB etc.).

CQM is not a problem for standalone compatibility


3) An average, let's call it universal low-middle bitrates matrix, lets an average Joe make an average encode. We're here a bunch of freaks, who want to get more.

If you want really high quality at high bitrate, you can try DivX3 (with libavcodec). Size/quantisation scaling is not a problem for DivX3 and q2+H263+divx3 and will done certainely higher bitrate than q2+6o9+xvid.



Why did you recommend and used your custom matrix then for the purpose of the above tests?

I don't recommanded my matrix. Grain Retention for H264 is not a CQM problem.


Sure, H263: it will keep the largest possible grain (like 2-3 pixels) in some scenes, however it will wash out 5 of 10 spots on a face (or arse, depending on the film's genre :D)

Grain retention for ASP is not a H263 quantisation problem too.

[HeadBangeR77]

You could work as a propaganda minister somewhere in Africa. :D

[3 cd + XviD + 576p + DVD source] is really strange and useless way.
[3 cd + h264 + 720p + HDTV source] will done and really by far better quality.
I don't think a high-quality 3CD rip of 2-2.5 hour film is useless. In such a case I get good image with less than half of standard DVD-5, instead of DVD-9 (of course, the main film is probably much less than DVD-9, but surely more than DVD-5). That's the quality I'm aiming at, so it's not useless from my POV, and I think I'm not alone (I shall tell Tegedeeck half of his presets is useless then, and alarm the MeGUI-team, that have implemented it :D). If you've got another point of view, fine with me, but don't try to play a crusader. :p
And where am I supposed to get that HDTV source from, if I may ask? Could you turn my DVDs collection into HDTV footage auto-magically? It's the first time I will write :
LOL

Size/quantisation scaling is not H263+ASP problem. It's only a H263+XviD problem.
Huh?

CQM is not a problem for standalone compatibility
REALLY? :D

If you want really high quality at high bitrate, you can try DivX3 (with libavcodec). Size/quantisation scaling is not a problem for DivX3 and q2+H263+divx3 and will done certainely higher bitrate than q2+6o9+xvid.
No, thank you. I used to encode with DivX 3 for many years, and I'm not going back, nor pump my bitrate into empty void.

I don't recommanded my matrix. Grain Retention for H264 is not a CQM problem.
You've recommended it along with full command line:

http://forum.doom9.org/showthread.php?p=945751#post945751

"x264.exe --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -2:-2 --cqmfile Sagittaire.cfg --crf 18 --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 1 --progress -o x264.mp4 Encodage.avs

with Sagittaire.cfg"

Btw. Did you use the standard flat quantization or Sagittaire.cfg for your sample? ;)

Grain retention for ASP is not a H263 quantisation problem too.
So no matter what frequencies are compressed and how (to what extend), it doesn't influence the grain retention. That's what you're saying? :D