x264 MUCH better quality than XviD?

[ricardo.santos]

HeadBangeR77 thanks!

[DarkZell666]

I've just finished uploading the 4 samples here:

http://xasonline.info/doom9/BP_QP18_M4G-HighDetail-V3.1cqm_deadzone0-nodeblock.mkv
http://xasonline.info/doom9/BP_QP17_flatcqm_deadzone0-nodeblock.mkv
http://xasonline.info/doom9/BP_QP18_flatcqm_deadzone0-nodeblock.mkv
http://xasonline.info/doom9/BP_QP18_M4G%20HRM%20V1cqm_deadzone0-nodeblock.mkv

I'm really having trouble distinguishing them appart, though they all visibly loose much grain in the background compared to the m2v :)
I'll upload some cqp15 and cqp10 samples tomorrow, but they'll have such a bitrate that they will probably only serve to proove that x264 can't be transparent whatever you try (as already stated at the beginning of this thread). I'll also give a 2-bframes and a 4x4 transform sample a shot just in case it changes anything, but it'll ruin the transparency a bit more imho.

Cya tomorrow anyway ^^

[*.mp4 guy]

X264 is pretty good with b frames, unless they have the wierd badly skiped predicted blocks they aren't worse then pframes visualy. B frames should always be used. I'm not sure about the 4x4 transform.

[*.mp4 guy]

Well with these settings:
--pass 2 --bitrate 3500 --stats ".stats" --keyint 240 --min-keyint 48 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct none --filter -2,-4 --subme 6 --analyse all --8x8dct --thread-input --cqmfile "M4G HRM V1.5.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output "Black.Pearl.Sample3.mkv" "Black.Pearl.Sample1.avs" --deadzone-inter 4 --deadzone-intra 6

I get this (http://www.megaupload.com/?d=WBR7545H).

[HeadBangeR77]

I must have been absent-minded to upload my best 2-pass samples to rapidshare, instead of uploading them on the server DarkZell666 had kindly made available for me ... :o
Shame, at least I'm uploading the screenshots atm (see my "homework" post on the previous page for updates).

Although I'm a half-noob to x264, I've already marked that disabling b-frames won't raise the quality too much, but will bump up bitrate enormously. Maybe playing with the B-frame reduction could help? Like e.g. 1.25 or 1.20?

@ DarkZell666
Gonna download your samples soon and have a close look at them :devil: ;)

@ 8.mp4 guy
Thank for another x264 encode - the above applies to it as well. Could you try 2 passes with target bitrate 2553kbps? 'Cause that's the target of all 2-pass samples of mine. :)
Btw. working with so noisy, grainy, dusty, dirty and blocky material I've just discovered that 2 passes could do miracles. 1 pass samples are just for starters, to search for appropriate settings etc.

Thank you guys for the cooperation, at last there's sth going on here. I hope all that might turn useful while developing x264 further, since I've marked that akupenguin is watching. ;)

[*.mp4 guy]

2553 kbps is only enough to keep ~25% of the grain in the original, 3500 keeps ~75%. I noted a rather big difference in grain retention when I disabled B prediction (though it caused no other problems as long as b-rdo was disabled when using it) B prediction didn't impact spatial noise retention, it had a sort of temporal blurring effect, causing the grain to look less temporally random, which makes sense I suppose, atleast now that the b-rdo workaround is known it is safe to use on non-grainy material, or material where retaining the grain is unimportant.

[HeadBangeR77]

2553 kbps is only enough to keep ~25% of the grain in the original, 3500 keeps ~75%.
The problem is not in the actual grain retention in general, imho, but in the fact the background, the interior of that smithy is simply coverd with noise & grain & dust particles (which should be there). The layer is so thick sometimes, that it hides the background's details, so after removing all that grain & other grain-like stuff there are no details left, e.g. on the walls, the bricks seem blurred etc.

I noted a rather big difference in grain retention when I disabled B prediction (though it caused no other problems as long as b-rdo was disabled when using it) B prediction didn't impact spatial noise retention, it had a sort of temporal blurring effect, causing the grain to look less temporally random, which makes sense I suppose, atleast now that the b-rdo workaround is known it is safe to use on non-grainy material, or material where retaining the grain is unimportant.
Without going too deep into x264 settings, which I'm only starting to be familiar with, do you think it is the above temporal blurring, that results in turning most of the grain into some sort of moving, unnatural haze? (looks nasty!) I've seen sth like that in my x264 trial encodes.

Having uploaded the screenshots I'm downloading your encode atm. Did you happen to have a look at my 2nd 2-pass sample (Heini 6of9)? If so, what do you think of it? It's only half the size of the best 1-pass encode I've uploaded here.

cheers,
HDBR77

[HeadBangeR77]

@ mp4 guy:

Alle Ihrem Land (Poland) zugewiesenen Download-Slots sind derzeit besetzt. Versuchen Sie es in einigen Stunden erneut oder installieren Sie die Megaupload Toolbar - dann gibt es für Sie keine Slot-Limitierung mehr!
Die Megaupload Internet Explorer-Toolbar macht Ihre Uploads schneller und bequemer.

which stands for ...

All download-slots for your country (Poland) are busy/engaged atm. Plz try in a couple of hours (sic!!!) again, or install the Megaupload Toolbar - there will be no slots limit for you then!
blah blah Toolbar makes your uploads quicker and more comfortable.

What the hell is that? What I could do, if I don't want to install any toolbar (I'm allergic to them ;)), and especially not a one for IE?

[*.mp4 guy]

yeah, don't install any crapware :D . I'll upload it somewhere else, I should probably stop using that site, it seems to have trouble with some countries (no clue why).

[edit] link (http://rapidshare.com/files/14637176/X264.mkv.html)
[edit2] 2553 bitrate encode with a different matrix, all other settings the same (http://rapidshare.com/files/14640262/X264.mp4.html)

Having uploaded the screenshots I'm downloading your encode atm. Did you happen to have a look at my 2nd 2-pass sample (Heini 6of9)? If so, what do you think of it? It's only half the size of the best 1-pass encode I've uploaded here.

The noise was all blured together, but it kept good detail in high motion scenes and still scenes, and revealed less of the sources artifacts then the x264 encodes, overall the quality was ok. Personally I liked the small x264 encode better, but its pretty close.

[GmorG McRoth]

All download-slots for your country (Poland) are busy/engaged atm. Plz try in a couple of hours (sic!!!) again, or install the Megaupload Toolbar - there will be no slots limit for you then!
blah blah Toolbar makes your uploads quicker and more comfortable.

What the hell is that? What I could do, if I don't want to install any toolbar (I'm allergic to them ;)), and especially not a one for IE?

Try this: https://addons.mozilla.org/firefox/3843/

[HeadBangeR77]

@ ricardo.santos
You're welcome. :) Btw. do you happen to know Sharro (from Portugal as well, has been around here from the very beginning)?

@ GmorG McRoth
Thanks, mate - might turn out useful sometimes (should work with my Seamonkey 1.1 also, since it shares the engine with Firefox 2.0).

To the main matter:
You've done a very good job with your encode, *.mp4 guy! My congratulations! I haven't seen the smaller version yet (have to reboot after deinstallation of the old Haali's splitter, and I haven't reboot for weeks :D), but the 3500kbps one is grainy and noisy as hell. :D It's also blocky to the same amount, but the source was really bad. ;) I mean with equally difficult source, but of better quality, those blocks shouldn't be so visible, and your settings + matrice would probably deliver better results.

I must take a closer look at my best 1-pass samples again, yet I've already got an impression your 2-pass encode looks a bit better in terms of noise/grain/dust retention, while remaining smaller in its size. I've deliberately chosen a high bitrate matrice for my samples, which is not so blocky at the same time, to get an overall good visual impression, and I think I've succseeded. The only difference lies in the fact, I've used my standard XviD settings, without tweaking too much (it was more the choice of the right matrix, not the codec's settings itself). Nevertheless you've just proven x264 can be almost-transparent, while using certain settings + CQM, yet this comes with experience. Thank you very much for this little contest - hope you've enjoyed it a bit. ;)

I personally prefer such an encode:
http://rapidshare.com/files/14693396/21-Noise-Deblocking2.avi

Doesn't have that much noise and grain, since it's been denoised gently. What was left has been sharpened after that, and soothed with Soothe(). Most of the blocks have been masked by Deblock_QED: if you had time to take a look at frames 973, 1529, 1753, 2564, 2583, and around the frame 2700 and the next ones, you would mark a difference. Gosh, it's getting totally off-topic. :p After all it's my problem how to correct a bad source, even by sacrificing some details.

cheers,
HDBR77

@ DarkZell666
Have you seen that guy's samples? Impressing, isn't it?
Thanks once again for some webspace, and I hope you will pop up with some nice, grainy sample yet. ;)

[Sagittaire]

With one thing, suggested by Sagittaire, I will never agree: speed. Since most XviD's users use fast first pass or a hybrid first pass (as in Teegedeck's presets), and most x264's users prefer 2 full passes (some even 3), there's no match in terms of speed for XviD imho. On my outdated-yet-still-breathing pc (Athlon XP-M 11x220, 2x512MB Mushkin TCCD 2-3-3-11, ATI Radeon 9800 PRO @ XT v-modded, modded BeQuiet 450W PS and so on) I can reach 25-40 fps for the first pass (hybrid, yet I change it depending on the source) and 10-12 fps for the 2nd pass with all the options maxed out. With x264 I rarely see anything beyond 10fps, not to mention an encode with all possible goodies activated.

One more time it's completely false ...

1) crf mode is a very popular one pass mode and quality will be exactly the same than multipass encoding but without size prediction. You can use exactly the same first pass turbo tweak for all codec (faster ME for example).

2) RDO, umh, multiref, full partition, inloop, cabac ... etc are facultative setting and particulary for low quantizer encoding. For x264 you can use by far faster setting than slowest XviD setting (ME6 + VHQ4 + trellis). The slowest setting for ASP can be really slow too (with libavcodec for example).

[*.mp4 guy]

To the main matter:
You've done a very good job with your encode, *.mp4 guy! My congratulations! I haven't seen the smaller version yet (have to reboot after deinstallation of the old Haali's splitter, and I haven't reboot for weeks :D), but the 3500kbps one is grainy and noisy as hell. :D It's also blocky to the same amount, but the source was really bad. ;) I mean with equally difficult source, but of better quality, those blocks shouldn't be so visible, and your settings + matrice would probably deliver better results.

I must take a closer look at my best 1-pass samples again, yet I've already got an impression your 2-pass encode looks a bit better in terms of noise/grain/dust retention, while remaining smaller in its size. I've deliberately chosen a high bitrate matrice for my samples, which is not so blocky at the same time, to get an overall good visual impression, and I think I've succseeded. The only difference lies in the fact, I've used my standard XviD settings, without tweaking too much (it was more the choice of the right matrix, not the codec's settings itself). Nevertheless you've just proven x264 can be almost-transparent, while using certain settings + CQM, yet this comes with experience. Thank you very much for this little contest - hope you've enjoyed it a bit. ;)
It was fun seing how much grain I could coax X264 into keeping :devil:, usually I just get rid of as much noise and compression crap as I can (without killing detail) before encoding with anything.

Doesn't have that much noise and grain, since it's been denoised gently. What was left has been sharpened after that, and soothed with Soothe(). Most of the blocks have been masked by Deblock_QED: if you had time to take a look at frames 973, 1529, 1753, 2564, 2583, and around the frame 2700 and the next ones, you would mark a difference. Gosh, it's getting totally off-topic. :p After all it's my problem how to correct a bad source, even by sacrificing some details.

Well, if we are allowing filtering into the equation I would pobably sacrifice some quality, since the source isn't that great, and go with something like this (http://www.mytempdir.com/1201140).

[HeadBangeR77]

One more time it's completely false ...
One more time you're saying sth is completely false, as if everything in this world was either 1 or 0. Do you happen to mark, there's whole lot in between? Every single person tends to have either slightly or completely different attitudes, needs, expectations etc.
I was writing about my own needs and till now I've never encoded anything with x264 faster than with XviD.

1) crf mode is a very popular one pass mode and quality will be exactly the same than multipass encoding but without size prediction.
Imho not completely true. At certain bitrate a codec will make more wise decisions while running two passes, than just one. If the final bitrate turns out to be similar in both cases (CRF, 2-pass encode), the latter looks better to my eyes. Above certain limit, which is hard to estimate, 'cause this varies from source to source and resolution, the difference will be invisible, unless one would examine frame by frame, what's obviously not a common thing. ;)
If you want a quick proof, just examine my 1-pass samples with those 2-pass ones, that are of similar size.

You can use exactly the same first pass turbo tweak for all codec (faster ME for example).
That's true in general, I must agree. Yet I use x264 for low bitrates, and for such a use I always do two full passes. Fast first pass in my case tends to break the final bitrate (and thus filesize) prediction a bit - might depend on the revision though.

2) RDO, umh, multiref, full partition, inloop, cabac ... etc are facultative setting and particulary for low quantizer encoding.
I agree, yet:
- see above (so I need those settings),
- turning more of those goodies off, yet within reasonable limits, I'm still almost twice slower than with XviD e.g. MSP=5, VHQ=1, VHQ for b-frames, chroma ME, trellis and even Qpel on. Might be that french PCs are different to the eastern european ones, who knows.

For x264 you can use by far faster setting than slowest XviD setting (ME6 + VHQ4 + trellis). The slowest setting for ASP can be really slow too (with libavcodec for example).
E.g.? What do you mean by far faster settings? What could be turned off in your opinion, without too much risk to quality, to make x264 soooo fast?

Btw. do you happen to know at least two other persons who would share you pov as to the speed of XviD and x264?

[HeadBangeR77]

It was fun seing how much grain I could coax X264 into keeping :devil:, usually I just get rid of as much noise and compression crap as I can (without killing detail) before encoding with anything.
I've just finished watching your larger 2-pass encode and my best 1-pass sample over and over again: they are comparable, the one is better here, and the other there, yet yours is smaller. My second best one-pass (http://rapidshare.com/files/14330263/15a-SV3-Qpel-5-1-Q2.avi), made with Soulhunter's V3, is also quite a good one, and the bitrate is lower (without Qpel it was even lower, 2915kbps). Next time a freak like me pops out, you've got the settings ready for contest. :D

Update : After longer examination I must admit I prefer your 2-pass one (3500 kbps) to my best one at constant quantizer. :) On the other hand I like my 2-pass encode with Heini's 6of9 (No 11) more than your sample at the same bitrate.

My preferences differ from source to source: I would like to see for instance Matrix as clean as possible, but The Lord of the Rings not. Sometimes it is hard to decide, especially when there are only some certain scenes which look better (imo) with grain & dirt (old smithy, caves, dungeons, like in the 1st part of POTC).

Well, if we are allowing filtering into the equation I would pobably sacrifice some quality, since the source isn't that great, and go with something like this (http://www.mytempdir.com/1201140).

Gonna have a look and update my post.

cheers,
HDBR77

[freshNewB]

As a sidenote dont waste your time with 3 passes unless the 2nd pass doesnt hit the desired bitrate/filesize.

i noticed that the 3rd pass generate a little smaller stats file than the 2nd pass , while pass4's stats file size is nearly equals to pass3's.
Can i explain that 3 passes will get a little better quality than 2 passes ,and after pass 4 , we will rarely improve the quality than the pass 3.
Is it right?can i mesure the quality form the stats file size? and how many % quality improve from 3passes than 2passes?

i usually use 3passes as default . I wonder if it is worth.
thx.

[check]

1) crf mode is a very popular one pass mode and quality will be exactly the same than multipass encoding but without size prediction. You can use exactly the same first pass turbo tweak for all codec (faster ME for example).

pengvado has specified a number of times this is false. You can prove yourself wrong too! :P

[DarkZell666]

@M4G: well, your samples are amazing, I've given up :p The grain is somewhat modified but it's still there.

I did do some QP10 and QP15 encodes with my same settings, and they looked far closer to the source, but they were huge (over 75MB and 100MB respectively). The QP10 encode in particular looked closer to the source than your 3500kbps sample imho, but it wasn't worth the bitrate, no way ;) Wierdly enough, the QP15 encode still lacked some temporal grain that your samples preserved quite nicely :) I guess I should have used --no-p-decimate, bframes, and the 4x4 transforms :p


I noticed something more intesting in my first attempts, and I wanted to be sure about it before posting:

@QP18, when I set the deadzone to 6, and changed the deblocking from -3 to -6 (I did other samples with deblocking enabled too), the output was bit-identical ! Whereas when I set deblocking back to 0, the output was different. I guess that's the desired effect of a deadzone anyway, but it was worth noting =)

[akupenguin]

@QP18, when I set the deadzone to 6, and changed the deblocking from -3 to -6 (I did other samples with deblocking enabled too), the output was bit-identical ! Whereas when I set deblocking back to 0, the output was different. I guess that's the desired effect of a deadzone anyway, but it was worth noting
That has nothing to do with deadzone.
H264 deblocking is inherently dependent on the QP, and the thresholds become 0 (i.e. deblocking is disabled) when QP+2*min(alpha,beta) <= 15.
Thus QP18 w/ deblock<=-2 is the same as no deblock.

[pinkie_1]

H264 deblocking is inherently dependent on the QP, and the thresholds become 0 (i.e. deblocking is disabled) when QP+2*min(alpha,beta) <= 15.
Just to be sure : is this a feature of H.264 in general, or a specific implementation in x264 ?

[akupenguin]

It is a feature of H.264 in general.

x264 chooses to disable deblocking in frames where it wouldn't do anything anyway (as determined by that formula), just to save the decoder some cpu-time in checking each macroblock's QP. But that decision only affects 1 bit in the frame header, not the content of the compressed stream nor the result of decoding.

[DarkZell666]

Ahhhh gotcha, thx for explaining :)

[Sagittaire]

One more time you're saying sth is completely false, as if everything in this world was either 1 or 0. Do you happen to mark, there's whole lot in between? Every single person tends to have either slightly or completely different attitudes, needs, expectations etc.
I was writing about my own needs and till now I've never encoded anything with x264 faster than with XviD.

I agree, yet:
- see above (so I need those settings),
- turning more of those goodies off, yet within reasonable limits, I'm still almost twice slower than with XviD e.g. MSP=5, VHQ=1, VHQ for b-frames, chroma ME, trellis and even Qpel on. Might be that french PCs are different to the eastern european ones, who knows.


Well you can find example here (Your CPU is the same class CPU)
http://forum.doom9.org/showthread.php?t=105763

And it's an old test, now x264 is really faster like for example this CLI:

x264.exe --bframe 2 --ref 1 --direct auto --deblock -3:-3 --cqmfile Sagittaire.cfg --deadzone-inter 0 --deadzone-intra 0 --crf 20 --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 2 --no-chroma-me --progress -o azerty.mp4 azerty.avs

-> only 8x8 partition with 8x8dct
-> only fullpel or halfpel (subme 1 or 2)
-> CQM with low deadzone

[HeadBangeR77]

An interesting test - you must have done whole lot of work on it, my congrat. :) And, believe or not, I'm not gonna doubt the results you've published there.

Yet I've got some remarks, if you found a moment (remember the CPU was more or less of similar class):

1) All my 2-pass samples (2553 kbps target bitrate) had:
PSNR above 43.5, with the best two ones: 43.77296 (Didee's 6of9) and 43.76364 (Didee's 6of9 HVS) respectively.
SSIM was way above 0.97X, with Didee's 6of9 HVS scoring 0.97701 and Didee's 6of9 - 0.97698.

1st pass speeds: 30-35 fps without Qpel (settings as described earlier), 20-25 fps with Qpel. The impact on metrics was mariginal, yet I was aiming at transparency.
2nd pass speeds: 14-15 fps for VHQ=2, 10-12 fps for VHQ 4.

I hadn't rebooted my pc for weeks back then, and it had whole bunch of applications running in the background - what influence it must have had on the encoding speed you're sure aware of.

It was high bitrate for that resolution, but ...

2) Encoding the whole movie with a target bitrate 1800kbps, exactly at the same resolution, with similar settings, Didee's SixOfNine matrice, yet much faster first pass, resulted in:
PSNR - 43.08350
SSIM - 0.97808

Fps: 34 fps for the 1st pass, 12 fps for the 2nd (have just looked at the log).

3) SSIM - I'm not for metrics too much, yet I prefer SSIM. How on earth did it happen, that encoding at medium bitrate was better than the one at high bitrate then? Credits! :D That's why I don't trust metrics too much - my best sample (Ad.1) scored almost the worst metrics, 'cause it was less blocky than the source, but resulted in the best possible visual transparency, keeping sharp image both at high and low motion, as even mp4.guy has stated.

3) Your tests were done at 1400kbps, anomorphic encode. I must emphasize over and over again, everyone has it's own preferations: I would never encode an anomorph rip with XviD at that bitrate, and I'm pretty sure it would deliver very good visual quality at about 2000kbps or a bit higher, while the encoding speed would remain similar. Secondly, I'm not interested in 1-pass constant quality encodes, unless I do some short samples like recently.

4) With all the goodies turned on, doing the mentioned samples, I was getting 5-6 fps with x264, after a reboot and defragmentation. Turning most of them off, apart from leaving motion estimation at 5, Hexagonal Search, resulted in fps between 10 and 15. The results were rather pathetic in terms of transparency.

5) I'm not trying to prove you were wrong, I'm just saying you've made some general benchmarks, while I've got my own goals, with the main one: "transparency for all". Did you happen to have a look at the source, btw? Would you achieve transparent results with subme 2?

6) So excuse me for my limited knowledge of x264, which I'm trying to tame atm and make friends with (;)), but for my uses XviD is faster. Have you seen how many people do 2 or either 3 full passes with x264? There are questions even in this thread, right above.

regards,
HDBR77

[Sagittaire]

An interesting test - you must have done whole lot of work on it, my congrat. :) And, believe or not, I'm not gonna doubt the results you've published there.

Yet I've got some remarks, if you found a moment (remember the CPU was more or less of similar class):

1) All my 2-pass samples (2553 kbps target bitrate) had:
PSNR above 43.5, with the best two ones: 43.77296 (Didee's 6of9) and 43.76364 (Didee's 6of9 HVS) respectively.
SSIM was way above 0.97X, with Didee's 6of9 HVS scoring 0.97701 and Didee's 6of9 - 0.97698.

1st pass speeds: 30-35 fps without Qpel (settings as described earlier), 20-25 fps with Qpel. The impact on metrics was mariginal, yet I was aiming at transparency.
2nd pass speeds: 14-15 fps for VHQ=2, 10-12 fps for VHQ 4.

I hadn't rebooted my pc for weeks back then, and it had whole bunch of applications running in the background - what influence it must have had on the encoding speed you're sure aware of.

It was high bitrate for that resolution, but ...

2) Encoding the whole movie with a target bitrate 1800kbps, exactly at the same resolution, with similar settings, Didee's SixOfNine matrice, yet much faster first pass, resulted in:
PSNR - 43.08350
SSIM - 0.97808

Fps: 34 fps for the 1st pass, 12 fps for the 2nd (have just looked at the log).

3) SSIM - I'm not for metrics too much, yet I prefer SSIM. How on earth did it happen, that encoding at medium bitrate was better than the one at high bitrate then? Credits! :D That's why I don't trust metrics too much - my best sample (Ad.1) scored almost the worst metrics, 'cause it was less blocky than the source, but resulted in the best possible visual transparency, keeping sharp image both at high and low motion, as even mp4.guy has stated.


1) Really bad way for metric use. Simply because Metric are not absolute quality measure ... lol
2) You can make really good conclusion with delta at 1.0 or 1.5 dB but certainely not with delta 0.1 dB or 0.15 dB



3) Your tests were done at 1400kbps, anomorphic encode. I must emphasize over and over again, everyone has it's own preferations: I would never encode an anomorph rip with XviD at that bitrate, and I'm pretty sure it would deliver very good visual quality at about 2000kbps or a bit higher, while the encoding speed would remain similar. Secondly, I'm not interested in 1-pass constant quality encodes, unless I do some short samples like recently.

1) No just 16/9 source with PAR 1:1 ...
2) It's not 1 pass speed but just speed for last encoding pass ...




I'm not trying to prove you were wrong, I'm just saying you've made some general benchmarks, while I've got my own goals, with the main one: "transparency for all". Did you happen to have a look at the source, btw? Would you achieve transparent results with subme 2?


subme 1 is fullpel search and subme 2 is halfpel search. 6 or 7 for subme is just RDO and done just better efficacity (save X% of size for same quality). With my sempron 32 bits at 2.1 Ghz and your sample.

D:\Mes dossiers\Codec\x264>x264.exe --bframe 2 --ref 1 --direct auto --deblock -3:-3 --cqmfile Sagit
taire.cfg --deadzone-inter 0 --deadzone-intra 0 --crf 20 --qcomp 0.75 --ipratio 1.25 --pbratio 1.33
--partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 2 --no-chroma-me --progress -o azerty.mp4
azerty.avs
avis [info]: 720x304 @ 23.98 fps (3624 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1001 (scale 24000)
x264 [info]: slice I:76 Avg QP:20.04 size: 26524 PSNR Mean Y:46.23 U:48.13 V:49.22 Avg:46.88 Gl
obal:46.78
x264 [info]: slice P:1961 Avg QP:21.23 size: 17990 PSNR Mean Y:45.42 U:47.23 V:48.15 Avg:46.03 Gl
obal:45.90
x264 [info]: slice B:1587 Avg QP:23.19 size: 8971 PSNR Mean Y:44.14 U:46.42 V:47.25 Avg:44.85 Gl
obal:44.74
x264 [info]: mb I I16..4: 20.2% 41.9% 37.9%
x264 [info]: mb P I16..4: 13.4% 39.9% 0.0% P16..4: 24.8% 11.4% 5.6% 0.0% 0.0% skip: 4.9%
x264 [info]: mb B I16..4: 2.6% 7.0% 0.0% B16..8: 28.1% 1.9% 5.5% direct:30.7% skip:24.2%
x264 [info]: 8x8 transform intra:72.6% inter:38.6%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: SSIM Mean Y:0.9810880
x264 [info]: PSNR Mean Y:44.874 U:46.893 V:47.777 Avg:45.534 Global:45.369 kb/s:2727.45

encoded 3624 frames, 16.03 fps, 2727.76 kb/s, total time: 0:03:46:109

D:\Mes dossiers\Codec\x264>pause
Appuyez sur une touche pour continuer...

and done this result ...
2772.76 Kbps with more than 16 fps
http://dl.free.fr/F4Lk01ph/x264.mp4


... but it's a completely useless test simply because x264 at the same bitrate can done really better result with HDTV source for this movie (reencoding at 1280*544 at 2500 kbps for this sample for example) with really better overall visual quality and here XviD can't never fight.

[HeadBangeR77]

1) Really bad way for metric use. Simply because Metric are not absolute quality measure ... lol
2) You can make really good conclusion with delta at 1.0 or 1.5 dB but certainely not with delta 0.1 dB or 0.15 dB

Gosh, you're still reading what you want to read. You were the first to pop out with metrics - PSNR & SSIM, which I had not published before, simply because I don't think they are an absolute quality measurement. And I wrote it in the post you quoted, I better trust my own eyes. So take your LOLing somewhere else, if you would be so kind in your kindness.
When even underlining or writing in bold text doesn't help, I give up.

With my sempron 32 bits at 2.1 Ghz and your sample.
(...)
and done this result ...
2772.76 Kbps with more than 16 fps
http://dl.free.fr/F4Lk01ph/x264.mp4

In terms of quality, trying to remain objective, you've done a good job - I would place it somewhere between mp4.guy's best encode (2-passes, 3500kbps) and his second sample (2-passes, 2500 kbps), rather closer to the best one.

In terms of speed I've done my 1-pass samples at 30-35 fps without Qpel (two times faster), as stated above, and 20-25 fps with Qpel enabled (stil above 25% faster). Settings as described many times already (MSP=5, VHQ=1, VHQ for b-frames, chroma ME, trellis and so on). So plz don't kill me with those 16 fps. :D


... but it's a completely useless test simply because x264 can done really better result with HDTV source for this movie (reencoding at 1280*544 at 2500 kbps for this sample for example) with really better overall visual quality and here XviD can't never fight.
I'm gonna repeat for the last time, I'm aiming at transaprency. Sure, such an encode at 2500 kbps at the given resolution will be transparent, no dobut. :D :D :D
Especially since *.mp4 guy needed his HRM matrice and 3500 kbps to achieve an almost-transaprent result at 720x304.

And one thing more: I've never stated, anywhere, that x264 will not deliver an overall better quality throughout the movie than XviD. Somone wanted a tough source, so I've found one.

alles Beste
HDBR77

[Sagittaire]

Gosh, you're still reading what you want to read. You were the first to pop out with metrics - PSNR & SSIM, which I had not published before, simply because I don't think they are an absolute quality measurement. And I wrote it in the post you quoted, I better trust my own eyes. So take your LOLing somewhere else, if you would be so kind in your kindness.
When even underlining or writing in bold text doesn't help, I give up.


No it's not the probleme: you compare metric with little sample at 2500 Kbps and after with complete movie at 1800 Kbps. You simply don't understand how work Rate Control and Metric.


In terms of quality, trying to remain objective, you've done a good job - I would place it somewhere between mp4.guy's best encode (2-passes, 3500kbps) and his second sample (2-passes, 2500 kbps), rather closer to the best one.

In fact my encoding is by far better than mp4.guy's 2500 kbps encoding. There are major blocking artefact flicking in the dark area for mp4.guy's 2500 kbps encoding ...




In terms of speed I've done my 1-pass samples at 30-35 fps withour Qpel (two times faster), as stated above, and 20-25 fps without Qpel (stil above 25% faster). Settings as described many times already (MSP=5, VHQ=1, VHQ for b-frames, chroma ME, trellis and so on). So plz don't kill me with those 16 fps. :D

No certainely not with VHQ4 + ME6 + BRDO + QPel. You say in your previous post:

1st pass speeds: 30-35 fps without Qpel (settings as described earlier), 20-25 fps with Qpel. The impact on metrics was mariginal, yet I was aiming at transparency.
2nd pass speeds: 14-15 fps for VHQ=2, 10-12 fps for VHQ 4.

I think that you definitively don't understand how work RC for codec. I can make 2 pass encoding for x264 with high speed first too ...



I'm gonna repeat for the last time, I'm aiming at transaprency. Sure, such an encode at 2500 kbps at the given resolution will be transparent, no dobut. :D :D :D
Especially since *.mp4 guy needed his HRM matrice and 3500 kbps to achieve an almost-transaprent result at 720x304.


XviD Q3 CQM HRM matrix done 2550 Kbps. Try to find artefact in my sample if you want ...

[DarkZell666]

I think we've done a full circle again :)

Actually, I'm quite surprised with x264's capability of being transparent at relatively useful bitrates, that was a nice comparison to make imho (even if the debate has been opened quite a number of times already), and the debate in question is all in the topic title: it all depends on what you call "better quality" (quality being a "hyper-subjective" matter already xD)

[HeadBangeR77]

No it's not the probleme: you compare metric with little sample at 2500 Kbps and after with complete movie at 1800 Kbps. You simply don't understand how work Rate Control and Metric.
1) I gave the metrics I've achieved with a small sample. Yet it was indeed a small sample, and at high bitrate, so...
2) I gave then the metrics I've achieved encoding the whole movie, medium bitrate, and they weren't so bad, as in you test you've linked to above.
3) The only thing I've done wrong I've rushly compared my samples' merics with the whole movie.

1400kbps for 16:9 movie, with PAR 1:1, at full DR is an overkill for XviD's capabilities and you know that. So what were you trying to prove by that? That x264 is overall better? Yes, it is, nobody has raised any doubt here, neither me. What was wrong, imho, you had chosen back then the worst field for that comparison: low bitrate, at the most low-medicore bitrate (1400 kbps for DVD resolution PAR 1:1, even if it was 16:9). So there was no chance for XviD to prove, that it doesn't behave so much worse at higher bitrates. You proved what everybody here knows: there's no match for H264 in general at low-medium bitrate. Point.


In fact my encoding is by far better than mp4.guy's 2500 kbps encoding. There are major blocking artefact flicking in the dark area for mp4.guy's 2500 kbps encoding ...
Yes, your de best, no doubt! :D
I have said I would place it in between mp4.guy's samples, yet closer to the best one. If you want admiration, you've got a piece here.

AND for heaven's sake (!!!)
You've done a one-pass sample, haven't you?
So I was talking about my one-pass samples, which I've linked to earlier, giving the settings more than once. If you don't believe, just browse through this thread. A few pages of reading with understanding won't do you any harm, imo.
You've cited a part of post, in which I was talking about 1-pass samples, so to compare the speed with your one pass, what's more, I had given the settings there, so why do quote two posts, that concern two different things (1-pass, quick, 2-passes, high qulaity)?

I know you could run two passes with similar of even identical speed, as well as I could run my second pass at the same speed as the first one. So what's the matter then?

[Sagittaire]

XviD 2 pass encoding:

turbo fisrt pass + VHQ1 + ME6 + BRDO + Trellis + Bframe 2/1.5/0.0
first pass at 37.33 fps and 97 sec
second pass at 21.30 fps and 170 sec
total time at 263 sec

turbo fisrt pass + VHQ4 + ME6 + BRDO + Trellis + Bframe 2/1.5/0.0
first pass at 37.33 fps and 97 sec
second pass at 11.60 fps and 312 sec
total time at 409 sec

turbo fisrt pass + VHQ4 + ME6 + BRDO + Trellis + Bframe 2/1.5/0.0 + Qpel
first pass at 35.95 fps and 101 sec
second pass at 9.12 fps and 397 sec
total time at 498 sec


x264 2 pass encoding:

first pass at 24.47 fps and 148 sec
second pass at 18.07 fps and 200 sec
total time at 348 sec

D:\Mes dossiers\Codec\x264>x264.exe --bframe 2 --ref 1 --direct none --no-deblock --cqmfile Sagittai
re.cfg --bitrate 2550 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --
partitions "none" --me "dia" --subme 1 --no-chroma-me --progress -o NUL azerty.avs
avis [info]: 720x304 @ 23.98 fps (3624 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:41 Avg QP:17.37 size: 30938 PSNR Mean Y:46.95 U:49.23 V:50.21 Avg:47.68 Gl
obal:47.58
x264 [info]: slice P:1873 Avg QP:18.54 size: 17650 PSNR Mean Y:44.97 U:47.55 V:48.39 Avg:45.75 Gl
obal:45.58
x264 [info]: slice B:1710 Avg QP:20.13 size: 8514 PSNR Mean Y:43.89 U:46.99 V:47.81 Avg:44.76 Gl
obal:44.58
x264 [info]: mb I I16..4: 33.6% 0.0% 66.4%
x264 [info]: mb P I16..4: 29.0% 0.0% 0.0% P16..4: 63.2% 0.0% 0.0% 0.0% 0.0% skip: 7.7%
x264 [info]: mb B I16..4: 5.5% 0.0% 0.0% B16..8: 94.5% 0.0% 0.0% direct: 0.0% skip: 0.0%
x264 [info]: final ratefactor: 18.39
x264 [info]: SSIM Mean Y:0.9791799
x264 [info]: PSNR Mean Y:44.485 U:47.304 V:48.138 Avg:45.307 Global:45.098 kb/s:2587.47

encoded 3624 frames, 24.47 fps, 2587.61 kb/s, total time: 0:02:28:110

D:\Mes dossiers\Codec\x264>x264.exe --bframe 2 --ref 1 --direct auto --deblock -3:-3 --cqmfile Sagit
taire.cfg --deadzone-inter 0 --deadzone-intra 0 --bitrate 2550 --pass 2 --stats "x264_stat.log" --qc
omp 0.75 --ipratio 1.25 --pbratio 1.33 --partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 2 -
-no-chroma-me --progress -o azerty.mp4 azerty.avs
avis [info]: 720x304 @ 23.98 fps (3624 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1001 (scale 24000)
x264 [info]: slice I:41 Avg QP:20.46 size: 25487 PSNR Mean Y:45.94 U:47.88 V:48.93 Avg:46.60 Gl
obal:46.49
x264 [info]: slice P:1873 Avg QP:21.60 size: 17247 PSNR Mean Y:45.31 U:47.23 V:48.16 Avg:45.95 Gl
obal:45.81
x264 [info]: slice B:1710 Avg QP:23.66 size: 8729 PSNR Mean Y:43.88 U:46.26 V:47.08 Avg:44.61 Gl
obal:44.51
x264 [info]: mb I I16..4: 20.2% 42.5% 37.3%
x264 [info]: mb P I16..4: 13.8% 41.2% 0.0% P16..4: 23.3% 10.9% 5.4% 0.0% 0.0% skip: 5.4%
x264 [info]: mb B I16..4: 2.5% 7.2% 0.0% B16..8: 50.8% 2.1% 5.1% direct:10.9% skip:21.3%
x264 [info]: 8x8 transform intra:73.7% inter:38.3%
x264 [info]: direct mvs spatial:0.0% temporal:100.0%
x264 [info]: SSIM Mean Y:0.9802544
x264 [info]: PSNR Mean Y:44.642 U:46.779 V:47.657 Avg:45.327 Global:45.155 kb/s:2555.12

encoded 3624 frames, 18.07 fps, 2555.34 kb/s, total time: 0:03:20:500

D:\Mes dossiers\Codec\x264>pause
Appuyez sur une touche pour continuer...


x264 constant quality encoding:

unique pass at 15.67 fps and 231 sec
total time at 231 sec
same metric than 2 pass mode


D:\Mes dossiers\Codec\x264>x264.exe --bframe 2 --ref 1 --direct auto --deblock -3:-3 --cqmfile Sagit
taire.cfg --deadzone-inter 0 --deadzone-intra 0 --crf 20.4 --qcomp 0.75 --ipratio 1.25 --pbratio 1.3
3 --partitions "i8x8,p8x8,b8x8" --8x8dct --me "hex" --subme 2 --no-chroma-me --progress -o azerty.mp
4 azerty.avs
avis [info]: 720x304 @ 23.98 fps (3624 frames)
x264 [warning]: NAL HRD parameters require VBV max bitrate and buffer size to be specified
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 1001 (scale 24000)
x264 [info]: slice I:72 Avg QP:20.49 size: 25749 PSNR Mean Y:45.92 U:47.90 V:49.00 Avg:46.59 Gl
obal:46.48
x264 [info]: slice P:1966 Avg QP:21.63 size: 17068 PSNR Mean Y:45.21 U:47.14 V:48.07 Avg:45.86 Gl
obal:45.71
x264 [info]: slice B:1586 Avg QP:23.56 size: 8370 PSNR Mean Y:43.95 U:46.33 V:47.15 Avg:44.68 Gl
obal:44.58
x264 [info]: mb I I16..4: 20.4% 42.1% 37.5%
x264 [info]: mb P I16..4: 13.3% 39.3% 0.0% P16..4: 25.2% 11.3% 5.5% 0.0% 0.0% skip: 5.3%
x264 [info]: mb B I16..4: 2.2% 6.3% 0.0% B16..8: 27.3% 1.9% 5.4% direct:29.4% skip:27.6%
x264 [info]: 8x8 transform intra:72.7% inter:38.6%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: SSIM Mean Y:0.9803986
x264 [info]: PSNR Mean Y:44.674 U:46.800 V:47.687 Avg:45.357 Global:45.189 kb/s:2576.78

encoded 3624 frames, 15.67 fps, 2577.08 kb/s, total time: 0:03:51:203

D:\Mes dossiers\Codec\x264>pause
Appuyez sur une touche pour continuer...

[*.mp4 guy]

Here (http://forum.doom9.org/showthread.php?t=110328) is a link some people may find interesting.

@Sagittaire do not try to make up peoples minds for them, they can decide on there own which encode looks better. And if my encode has blocks (which it does) what about yours? I have the funniest impresion that you are being hypocritical since it has far more blocks then my encode...

[edit] link fixed to point to the begining of the thread

[HeadBangeR77]

@ Sagitarius, Calm down, mate, have you been drinking? :D

My one-pass (with Qpel) is still above the speed of yours (more than 25% at least, actually above 30%), that was made with subme 2 (halfpel)!

After that, you compare all possible /popular two-pass versions with XviD, including the one with all goodies turned on, with the really quick 2-pass encode using x264, subme 1/2! And, what would like to show or "prove" by that? That:


turbo fisrt pass + VHQ1 + ME6 + BRDO + Trellis + Bframe 2/1.5/0.0
first pass at 37.33 fps and 97 sec
second pass at 21.30 fps and 170 sec
total time at 263 sec


what is a moderately good-quality setting for XviD, was faster than x264

first pass at 24.47 fps and 148 sec
second pass at 18.07 fps and 200 sec
total time at 348 sec


without chroma me, no deblocking (sure you will never use deblocking :D), subme 1 (1st) pass, subme 2 (second pass)?

You've done it! My congratulations! :)

PS. Now turn on all the goodies of x264, all the goodies of XviD, and compare the speed. ;)

EDIT:
@ DarkZell666 - You've summed the things up very good, mate. Briefly and correctly imo. :)

@ *.mp4 guy - Sagittaire sample managed to retain much grain, yet it's as blocky as hell. If the only purpose of those comparisons was grain retention, then it was fine, but the overall quality + grain retentin would put it on a lower postion. I'm gonna check your smallest sample now. Cheers.

[Sagittaire]

Here (http://forum.doom9.org/showthread.php?t=110328&page=5) is a link some people may find interesting.

@Sagittaire do not try to make up peoples minds for them, they can decide on there own which encode looks better. And if my encode has blocks (which it does) what about yours? I have the funniest impresion that you are being hypocritical since it has far more blocks then my encode...

No you have major and really visible artefact here (block flicking):
http://multimediacom.free.fr/Download/mp4guy.mp4

And not my encoding or XviD encoding:
http://multimediacom.free.fr/Download/sagittaire.mp4



what is a moderately good-quality setting for XviD, was faster than x264

without chroma me, no deblocking, subme 1 (1st) pass, subme 2 (second pass)?

You've done it! My congratulations!


Simply because like I always say x264 done always by far really better objective quality (metric only here) in all situations. You can use the fastest possible setting for x264 and the slowest possible setting for XviD (more generaly for ASP) and XviD will be never able to obtain better objective quality. It's not an obligation to use slowest setting for x264 and particulary for low quantizer encoding. And as you can see fast setting for x264 done really good quality for your sample:
http://dl.free.fr/F4Lk01ph/x264.mp4


@ *.mp4 guy - Sagittaire sample managed to retain much grain, yet it's as blocky as hell. If the only purpose of those comparisons was grain retention, then it was fine, but the overall quality + grain retentin would put it on a lower postion. I'm gonna check your smallest sample now. Cheers.

it's as blocky as hell ... with this source ... lol

Make comparison with the source and see the result if you want ... I wait.

[*.mp4 guy]

Sagittaire the block flickering in the sample from my clip that you posted was in the source... While the blocking in your sample was not in the source.

[HeadBangeR77]

Simply because like I always say x264 done always by far really better objective quality (metric only here) in all situations. You can use the fastest possible setting for x264 and the slowest possible setting for XviD (more generaly for ASP) and XviD will be never able to obtain better objective quality. It's not an obligation to use slowest setting for x264 and particulary for low quantizer encoding. And as you can see fast setting for x264 done really good quality for your sample:
http://dl.free.fr/F4Lk01ph/x264.mp4
I've just marked with bold the most typical parts. Comments not needed. Someone mentioned anything about metrics?

Yes, I've seen your sample, you've already linked to it, and yes, I appreciate it has kept most of the noise and grain. I've already said that twice. The overall quality was rather good.

***

@ *.mp4 guy:
I've got an answer for your 3500kbps encode, yet I have to upload it first (at 8KB/s :D). Generally it's similar to the one pass Soulhunter's V3 Q2 encode, the same matrice, but it's a 2-pass encode with b-frames 1/1/0 instead of 2/1.62/0, so the noise and grain are more stable (it's not like P2 - excellent retention of noise&grain, B3 - fair retention, which may cause a bit flickering). Noisy and grainy as hell again, yet a bit less blocky than the source. I think it did a bit better job, yet it's subjective.

Soulhunter's V3, 2-passes (http://rapidshare.com/files/14966352/Special2-SoulhuntersV3.avi)

Btw. Your smallest encode ain't that bad - it's been derived of noise & grain, a bit too soft, but far better from what I was expecting, I must admit. :o Sometimes noise & grain melts into some kind of haze, that moves unnaturally along the walls, but it's only visible in very few places.

@ all:
I've also done some "HD for the poor", 1280x544, not to prove it's better than x264 or equal, but to show XviD is capable of delivering some reasonably good results at such a resolution at about 3000 kbps. What's more, it still has some of the grain. :)
Filters: gentle Deblock_QED, BlindDeHalo_3_MT2 (just PPmode=-3), Lanczos4Resize and that's all.

XviD HD for the poor! ;) (http://rapidshare.com/files/14948968/HD1-DB-DH-H6of9-1.mkv)

Another version used another matrice (Heini's MR instead of Heini's SixOfNine) and had some slight denoising and sharpening at the end, apart from the above mentioned scripts:

XviD HD for the poor 2 (http://rapidshare.com/files/14973440/HD2-DB-DH-SH-HMR-1.mkv)

Cheers,
HDBR77

[Sagittaire]

Sagittaire the block flickering in the sample from my clip that you posted was in the source... While the blocking in your sample was not in the source.

It's really serious ... ???

Well now serious comparison:

lossless source (http://multimediacom.free.fr/Download/lossless.avi)
http://multimediacom.free.fr/Download/source.PNG

Sagittaire encoding (http://multimediacom.free.fr/Download/sagittaire.mp4)
http://multimediacom.free.fr/Download/sagittaire.PNG

mp4guy encoding (http://multimediacom.free.fr/Download/mp4guy.mp4)
http://multimediacom.free.fr/Download/mp4guy.PNG

XviD Q3 CQM UHR (http://multimediacom.free.fr/Download/XviD.avi)
http://multimediacom.free.fr/Download/XviD.PNG

[*.mp4 guy]

The version of careavc you are using to decode the video is buggy, it creates decoding errors on any file that uses different values for alpha and beta deblocking. get the fixed version of coreavc or use ffdshow and the problem will go away.

What do you think I am, blind?

[Sagittaire]

The version of careavc you are using to decode the video is buggy, it creates decoding errors on any file that uses different values for alpha and beta deblocking. get the fixed version of coreavc or use ffdshow and the problem will go away.

What do you think I am, blind?

Damned ... it's true ... lol

Anyway if I want really keep the grain with x264 I use:
- only 8x8 partition
- Half or FullPel
- CQM with low deadzone
- low inloop strenght or desactived inloop

[HeadBangeR77]

Samples uploaded (http://forum.doom9.org/showthread.php?p=949290#post949290), except the last one (ok, already done). ;)
The first is softer, yet it still has some grain; the 2nd one is sharper, but almost all grain is gone.

I've also seen some very gentle, hardly noticeable bugs while decoding XviD with ffdshow via libavcodec.dll. The material used always custom matrices, yet no other settings were "unusual". I've been using XviD 1.1.2 via ffdshow since then.

[foxyshadis]

(Assuming this is a recent version of tryouts.) Try changing the IDCT in decoder options, if you'd like. "auto" works best for divx3, libmpeg2 has been slightly more compatible than auto for most other content, and there's also the xvid internal version. Since you're pretty intimately familiar with the source, I guess that you'd be able to tell us which cause problems for this xvid+cqm stuff.

If you're ever in the mood to test, you could drop off results at the ffdshow development thread (http://forum.doom9.org/showthread.php?t=120465).

[Gilron]

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

[HeadBangeR77]

@ Gilron,

First of all, welcome to the forums! :)

Secondly, you've made whole lot of good work there - I've just taken a quick look at the screenshots. Must have more time to examine them more thoroughly. With many x264 profiles /presets you've used even the wall on the first one looks totally derived of not only some grain but any details (its texture). On the other hand I'm pretty sure such samples had better overall quality than e.g. 30% profile from Tegedeeck's presets, yet I can't judge that by looking at still frames.

cheers,
HDBR77

PS. If you really want to keep more grain with XviD I would recommend other matrices than the ones from XviD's presets, e.g. Didee's SixOfNine, which still is my favourite one, keeps sometimes less grain at quantizer 2 than Heini's equivalent at Q3.

PS2. Qpel seems to help with grain (XviD), while, at least according to Sagittaire, higher motion estimation precision with x264 does exactly the opposite (see his posts on the previous page).

[R3Z]

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

Well done man, it really puzzles me how mpeg 2 is able to retain such fine grain, noise and detail and h264 cant despite massive bitrates. :confused:

[HeadBangeR77]

Well done man, it really puzzles me how mpeg 2 is able to retain such fine grain, noise and detail and h264 cant despite massive bitrates. :confused:

Grain is temporally random. That's why it's a general problem for all encoders that get most of their "coding efficiency" out of motion compensation: since motion compensation is of zero help in compressing grain, the only way to preserve grain is to use sufficiently enough bits for "texture" ... and even with the codecs getting more modern and more efficient, the needed bits for this don't decrease by the same factor than overall efficiency does.
And that's why the old boy Mpeg-2 can "deal well" with grain, while the more modern codecs Mpeg-4 ASP and AVC seem to "deal worse": one has gotten used to the fact that they "perform similar" to Mpeg-2 at bitrates as low as 25% to 40% of Mpeg-2 bitrates. But that's only with clean sources. When grain comes into play, the keys-to-efficiency don't work out, and one would have to use higher bitrates with the newer codecs, too. But often one won't, because it's "a rule" that the new kids on the block shall always work with rather low bitrates ... the truth is that they can not *always* do so. Mpeg-2 can, because it's bitrate is comparably high, and coding grain with much bits is easy. Coding grain with little bits is hopeless.

Conclusion: It's not so much a problem of the codecs. It's a problem of wrong expectations of the users.

http://forum.doom9.org/showthread.php?p=952813#post952813

Me thinks Didee is right. ;)

[Seb.26]

Maybe the MPEG-5 will add "inloop graining" ... :o ... it could be cool just before denoising to evaluate the type & amount of grain to post-add it when decoding ... no ?! :confused:

[R3Z]

Me thinks Didee is right. ;)

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.

[HeadBangeR77]

Not knocking Didee, but h264 isnt able to do it even with the bitrate being higher. That really throws that conclusion out the window.
He was generalizing a bit, true enough, but h264 is capable of retaining most of the stuff with appropriate matrices and some tweaking, like the mp4.guy did in this thread. Yet the bitrate was more or less the same that the one of the source, and the tweaking he did was for my sample. I haven't got the faintest idea, if those settings (or Sagittaire's) would work well throughout the whole film.

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.
I'm more worried with background textures. It seems to me that the codec sacrifices: noise (ok, for most of users), grain, some very specific details and background textures (like e.g. rocks seen far away, similar things), to get better motion compensation in high-motion scenes, very sharp and detailed look in low-motion scenes, especially by close-ups etc. I can't tell to what extend the above side-effects could be neutralized by some magic tweaking, since I'm H.264/x264 noob, as already said more times. ;)

<continuation>


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.
Yes, indeed, there's such a tendency. If I see some nasty flickering noise, I normally want to get rid of it, but some grain won't bother me, especially in certain specific scenes /films. Like for instance grain on the sky, which disappears with chroma filtering, helps to mask or even prevent banding.

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:
Old films are old, and they should remain so, imo. So consider me a grain-fanatic. :)

cheers,
HDBR77

[nm]

Maybe the MPEG-5 will add "inloop graining" ... :o ... it could be cool just before denoising to evaluate the type & amount of grain to post-add it when decoding ... no ?! :confused:
That is already possible with MPEG-4 Part 10 and it's called Film Grain Modelling (FGM). There just aren't many encoders or decoders that can do it yet. Ateme and Thomson (with their FGT) probably have some solutions.

[R3Z]

He was generalizing a bit, true enough, but h264 is capable of retaining most of the stuff with appropriate matrices and some tweaking, like the mp4.guy did in this thread. Yet the bitrate was more or less the same that the one of the source, and the tweaking he did was for my sample. I haven't got the faintest idea, if those settings (or Sagittaire's) would work well throughout the whole film.


I'm more worried with background textures. It seems to me that the codec sacrifices: noise (ok, for most of users), grain, some very specific details and background textures (like e.g. rocks seen far away, similar things), to get better motion compensation in high-motion scenes, very sharp and detailed look in low-motion scenes by close-ups etc. I can't tell to what extend the above side-effects could be neutralized by some magic tweaking, since I'm H.264/x264 noob, as already said more times. ;)

<smoke> <BRB>

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.

[Seb.26]

That is already possible with MPEG-4 Part 10 and it's called Film Grain Modelling (FGM). There just aren't many encoders or decoders that can do it yet. Ateme and Thomson (with their FGT) probably have some solutions.
Oh ... so I'm not the first who have the idea ... :( ... maybe next idea make me rich ... :o ... lol ... thnks for the information.

Does any "public" decoder ( FFDShow / CoreAvc ... ) can handdle FGM ?!