x264 MUCH better quality than XviD?

[steve77]

I did a quick Auto 3 pass x264 encode via meGUI today and was really impressed with the quality. It just seems that it preserves so much details compared to XviD, and somewhat less blocky.

Are my eyes deceiving me? the 3 pass encode of a 2h home movie was pretty painful though (15FPS... so about 4 hours per pass)... but my initial tests seem very favorable indeed.

The question I wanted to ask is weather or not there is a guide that explicitly explains all of the details that are unfamiliar to me; I've only just gotten the hang of XviD! :mad:

I searched around the internet but found broad guides, not detailed ones. I'm not shy and like to fine tune the settings.


ONe thing I noticed in particular was the Quantizers; min 10, max 51?! That's alot higher than the standard 2-31 with XviD.

Of course, the codecs are probably totally different, which is why I'm looking for more detailed info.

Hats off to the developers!

Regards,

Steve

[Sharktooth]

welcome to the club ;)
For a starter, MeGUI has baloon tips explaining the options in the x264 codec configuration.
The quantizers are different coz the quantizer scaling is different. x264 Q18 is equivalent to xvid Q2 (using standard quantization).
As a sidenote dont waste your time with 3 passes unless the 2nd pass doesnt hit the desired bitrate/filesize.

[steve77]

welcome to the club ;)
For a starter, MeGUI has baloon tips explaining the options in the x264 codec configuration.
The quantizers are different coz the quantizer scaling is different. x264 Q18 is equivalent to xvid Q2 (using standard quantization).
As a sidenote dont waste your time with 3 passes unless the 2nd pass doesnt hit the desired bitrate/filesize.

Yeah, I noticed the tool-tips.... and it does seem pretty self-explanatory. Just wanted to get the inside track ;)

Do my encode times seem about right? (0.5x realtime per pass?, 4h for a 2h movie, 15 FPS on a 29.97FPS NTSC movie?) just making sure that I'm getting the best speed possible.

I'll definately be using x264 in future I think.... I've been using the mp4 container (I think that alot of people use matroska, right?)

I've also been using nero's AAC encoder for the audio, which seems to be good, but I've always used LAME MP3, so I'm not sure this is the best choice.

Regards,

Jimmy

[Sharktooth]

Well, AVC is more complex than ASP. However x264 has a lot of options to play with and you can adjust the encoding speed at the cost of quality.
MeGUI comes with a lot of presets, obviously the HQ presets are those which offer the highest quality but are slow. If you use the default settings you will notice a huge speedup but quality wont be the same... but still better than xvid.
I just suggest you to use AAC for audio so you can put both video and audio into a MP4 container that is the official MPEG4 container (by specs). Nero AAC is quite good, you can draw your own conclusions from the HydrogenAudio listening tests. Even at 32kbps it sounds incredibly good for that bitrate...

[jay_jay]

i think xvid is better .becoz i feel only same qulity with same bitrates.xvid is some for faster!!!!

[DarkZell666]

jay_jay: more constructive remarks would have been welcome :)
----

x264 does yield much better quality than XviD in almost every situation, except when trying to archive for very high transparency (like you would to with XviD@Q2 and a CQM, with which you're better off sticking for that purpose, imho). This is because (and you might have noticed already) x264 automagically removes some details which are considered to be noise (wrongly for sure) by default. Tweaking x264 to counter-act this default behavior is much more tricky than with, say, XviD (which isn't as agressive in the first place), but this particular behavior also helps yield better visual quality at medium & low bitrates, so it's a tradeoff you'll have to experiment with.

There are so much discussions about x264 settings in various situations (e.g: x264 typically creates blocking in low-contrast/flat areas, and there are 2 whole threads about how to get rid of the problem more or less succesfully in this subforum ;)).

I hope you'll have good fun making kick-ass encodes of your stuff =)

[*.mp4 guy]

Basically how it pans out is that If you are encoding in a situation where artefacts will be unavoidable X264 is better becuase its artefacts are less annoying, and overall there are less of them. In any other situation (archiving, transparent format shifting, refiltering etc.) X264 is inferior to Xvid becuase it is much harder to get transparent results with X264 then Xvid, on some sources it is completely impossible to get transparent results with X264 unless you use lossless or neer lossless bitrates.

[aabxx]

I have a lot of experience encoding VHS movies which tend to be very noisy and unstable, and xvid is clearly better on those sort of videos. My goal is to keep to the original as close as possible, therefore also trying to retain the noise, and even though the AVC codecs don't look directly bad or anything, they alter the noise characteristics too much compared to xvid.

Also, if I encode DVD, I use very high bitrates and on those both AVC and xvid excel. I choose xvid in those situations though as currently xvid is better supported (both on computers and standalone), easier to configure than most encoders and is speedy as well.

At medium to low bitrates though, AVC is superior. But I don't deal with those bitrates personally. But for downloadable anime, AVC rocks.

[BoNz1]

Do my encode times seem about right? (0.5x realtime per pass?, 4h for a 2h movie, 15 FPS on a 29.97FPS NTSC movie?) just making sure that I'm getting the best speed possible.


Not sure exactly about what kind of computer you have but that sounds about right. Is the movie really 29.97fps or is it just film at 23.97fps? I ask because you may be spending extra time encoding frames that you don't have to. Check in DgDecode if it is film. If so then this will make your encodes faster and better quality.

[Sagittaire]

i think xvid is better .becoz i feel only same qulity with same bitrates.xvid is some for faster!!!!

No ...

1) use the best setting for x264 is not a obligation
2) MPEG4 ASP can be extremely slow too if you use the best possible setting
3) For same speed AVC done better result than ASP


Also, if I encode DVD, I use very high bitrates and on those both AVC and xvid excel. I choose xvid in those situations though as currently xvid is better supported (both on computers and standalone), easier to configure than most encoders and is speedy as well.

1) Well At the same bitrate (high) you can use higher resolution for AVC (1024*576 or 1280*720 with interpolation) and the result will be always really better with AVC

2) In futur AVC hardware compatibility (both on computers and standalone) will be really better than ASP compatibility with HDTV, HDDVD, BD and hardware GPU decoding

[Sharktooth]

@Sagittaire: there is no freaking "BEST"...
Stop talking about "best" in all your posts. it doesnt exists, coz "best" is subjective and what is the "best" for you (probably metrics) could not be the "best" for me (infact i dont trust metrics at all!) or for other ppl. So your "best" settings could be completely off from my (or others) POV.

[Sagittaire]

@Sagittaire: there is no freaking "BEST"...
Stop talking about "best" in all your posts. it doesnt exists, coz "best" is subjective and what is the "best" for you (probably metrics) could not be the "best" for me (infact i dont trust metrics at all!) or for other ppl. So your "best" settings could be completely off from my (or others) POV.

Optimal visual quality for ASP and AVC at the same bitrate are not at the same quantizer@resolution and particulary in "high bitrate" situation. If for your eyes ASP done best quality at 720*400@q2 (XviD, usual setting) then AVC with higher resolution like 1280*720@q22 (x264, usual setting) will done better result for your eyes. It's really simple to prove that.

[*.mp4 guy]

No it isn't simple, ASP at 720*480*24P@Q2 with eqm-uhr (the one based on the fox home entertainment matrix) will be completely flawless looking, X264 will have banding at the same bitrate (I have no effing clue why, but it will), using interpolation on the source and then encoding with X264 will only make the banding worse (much worse).

Aditionaly if I am archiving footage I want to keep the encoded version as close to the original as possible, Inventing high frequency information and then trashing the gradients (and probably some details aswell) doesn't improve the situation for X264 at all.

[steve77]

@ BoNz1: Yeah, it's strange material; 29.97, all progressive frames. A buddy gave me the video to encode it... I actually inspected the frames and there are no duplicates/repeating frames.

My PC is a Core 2 Duo @ 3.2GHz...

I haven't done any tests yet, but I was REALLY impressed with the x264 clip I initially encoded (bitrate of 1350).

... goes and get some materials to test :)

[foxyshadis]

Optimal visual quality for ASP and AVC at the same bitrate are not at the same quantizer@resolution and particulary in "high bitrate" situation. If for your eyes ASP done best quality at 720*400@q2 (XviD, usual setting) then AVC with higher resolution like 1280*720@q22 (x264, usual setting) will done better result for your eyes. It's really simple to prove that.

I suspect this conclusion depends entirely on how you percieve grain. If it's an ugly artifact or simply unimportant, x264 is always better because it reduces and changes it. (Is this what you mean by "more pleasant to the eyes"?) If it's an absolutely essential component of the director's vision, xvid can often keep the grain more perfectly modeled than even the best x264 settings+post-added grain, as morte found. Most people probably aren't the kind of hardcore film buffs like him, but enough are that it's important to remember them.

[Sagittaire]

I suspect this conclusion depends entirely on how you percieve grain. If it's an ugly artifact or simply unimportant, x264 is always better because it reduces and changes it. (Is this what you mean by "more pleasant to the eyes"?) If it's an absolutely essential component of the director's vision, xvid can often keep the grain more perfectly modeled than even the best x264 settings+post-added grain, as morte found. Most people probably aren't the kind of hardcore film buffs like him, but enough are that it's important to remember them.

This thread don't speak about grain but it's really not a problem for H264 at "high bitrate":
http://images.apple.com/movies/wb/300/300-tlr2_h1080p.mov
http://images.apple.com/movies/wb/300/300-tlr2_h480p.mov

[*.mp4 guy]

Sagittaire what is that supposed to prove? both of the trailers are encoded with the same codec, and presumably from the same source, both are blocky in places, exhibit god awful banding, have screwed up levels, and inconsistent grain retention, how are we supposed to know if the HD one keeps all the grain when we can't see the original? If I had to guess I would say that it didn't keep all of the grain because some scenes are noticibly lacking in grain and because there is sometimes grain in the low rez version that the HD version doesn't have, not to mention the obvious blocking and "twisting" in some grainy areas, but without looking at the source(s?) how am I supposed to know for sure were the artifacts come from?

[DarkZell666]

There's at least one hardware factor who determines what's "best" to use too: HDD space :) Some people (me including) don't have 250GB of free HDD space to work with, so it's out of the question (at least for me) to archive anything that can take more than 1GB, and some content will necessarily need x264 to come down to such a size while retaining an "acceptable" quality, and in my case, "acceptable" is far from being transparent (but still much nicer than XviD at the same bitrate, which isn't an "archiving"-like bitrate at all, due to my low free hdd space =))

That's where the tradeoff is set, imho => some want the best possible visual quality no matter the size, and others want (or are forced to) achieve a high quality/filesize distortion. For the latter, AVC is definately a winner, but for the former, ASP does pretty good with a correct cqm (or even @Q1).

[squid808]

Has anyone experimented with "emulating" ASP settings with x264 for transparent bitrates? I.e. forcing 8x8 transform only, disable deblocking, dont use smallest blocksizes for ME etc? Quite odd if that wouldn't yield similar or better results.

[akupenguin]

There's still quantization (h264 isn't the same as either h263-style or mpeg-style), and no bilinear motion compensation (though I don't see people complaining about xvid qpel causing artifacts).

I have heard from people experimenting with libavcodec (where it's completely configurable) that using SATD for motion estimation can cause blocking, and the exact DCT is preferred. libavcodec w/ SATD looks fine to me, but that's something else to try.

[squid808]

Which aspect of the quantization do you refer to? Quantization matrix, logarithmix step size scaling, integer definition of inv. quant or something else?

What measure is used for ME in xvid?

[*.mp4 guy]

What akupenguin is refering to is that H.264 stricktly speaking does not use the dct transform as asp does, it uses a modified version that uses purly integer operations and has finite precision, whereas a true dct uses float operations and has non-finite precision (different implementations yeild different quality results, more speed=less quality, perfect quality is unachievable).

(also IMO, Xvid Qpel does cause artifacts)

[akupenguin]

No, the HCT vs DCT isn't a big problem. It really doesn't matter which exact set of approximations you use as long as the encoder and decoder agree. If the encoder and decoder use different approximations, then the low quality is due to the difference between them, not due to the difference from the ideal DCT.

By quantization, I mean given a quantized coefficient and the step size, how do you compute the dequantized coefficient. h264 uses level*qscale. ASP (both h263 and mpeg) uses level*qscale+qadd, with different values of qadd. (qadd is 0 for mpeg intra, but non-0 for h263 intra and both inter).


Xvid ME uses SAD (and then may refine with RD, depending on the setting of vhq).

[squid808]

Right, so if this "qadd" is the key to perceptual transparency for ASP it would actually be quite difficult to achieve something similar within H.264?

[Sagittaire]

Has anyone experimented with "emulating" ASP settings with x264 for transparent bitrates? I.e. forcing 8x8 transform only, disable deblocking, dont use smallest blocksizes for ME etc? Quite odd if that wouldn't yield similar or better results.

Mainconcept/Elecard encoder make a special grain profil. Work really well at high quantisation level. IMO there are not problem with H264 (and for x264 too) at low quantisation for grain ...



Sagittaire what is that supposed to prove? both of the trailers are encoded with the same codec, and presumably from the same source, both are blocky in places, exhibit god awful banding, have screwed up levels, and inconsistent grain retention, how are we supposed to know if the HD one keeps all the grain when we can't see the original? If I had to guess I would say that it didn't keep all of the grain because some scenes are noticibly lacking in grain and because there is sometimes grain in the low rez version that the HD version doesn't have, not to mention the obvious blocking and "twisting" in some grainy areas, but without looking at the source(s?) how am I supposed to know for sure were the artifacts come from?

Show me a source ...

[shon3i]

Mainconcept/Elecard encoder make a special grain profil. What is name of that profil?

[Manao]

Right, so if this "qadd" is the key to perceptual transparency for ASP it would actually be quite difficult to achieve something similar within H.264?I don't think it's the key.

If I was a betting man, I would say that the intra prediction is partly guilty to the absence of noise ( intra are coded completely differently from mpeg1/2/4 ). The second culprit would be the 4x4 transform ( I would say a 8x8 transform would more easily creates patterns that looks like noise ). The third one would be deblocking.

[check]

Well, if someone can post a source they feel xvid does significantly better than x264 on, I would be interested to have a shot!

[HeadBangeR77]

Well, if someone can post a source they feel xvid does significantly better than x264 on, I would be interested to have a shot!
That 'significantly' sounds like either irony or a chellange. :D

I might think of sth: ever watched "Pirates of the Caribbean - The Curse of the Black Pearl"? I bet most of you did. There's that fighting scene in a smithy in Port Royal between Jack Sparrow and Will Turner. The scene contains (in my NTSC DVD source)
- some light/moderate noise changing throughout the scene,
- some filmgrain, as I would discribe that,
- whole lot of dust from a XVIIth century smithy, which was owned by a trunkard and probably cleaned once a year.

Now try do distinguish those three, and make your encoder distinguish that. :D There's dust rising from the ground, as they are fighting, especially visible in sunlight, whole lot of dirt just floating in the air (no noise nor grain!), mixed with noise and filmgrain. Sounds interesting? Huh? ;)

With XviD 2pass, Didee's 6of9, it looks rather good, with some errors I could live with. With x264 it looks simply terrible: sometimes every kind of noise/dust/dirt disappear, making the whole fight unnatural, and the smithy automagically clean, sometimes it appears partially + there's terrible banding on the walls.

:devil: ;) ;) ;)

[Sagittaire]

That 'significantly' sounds like either irony or a chellange. :D

I might think of sth: ever watched "Pirates of the Caribbean - The Curse of the Black Pearl"? I bet most of you did. There's that fighting scene in a smithy in Port Royal between Jack Sparrow and Will Turner. The scene contains (in my NTSC DVD source)
- some light/moderate noise changing throughout the scene,
- some filmgrain, as I would discribe that,
- whole lot of dust from a XVIIth century smithy, which was owned by a trunkard and probably cleaned once a year.

Now try do distinguish those three, and make your encoder distinguish that. :D There's dust rising from the ground, as they are fighting, especially visible in sunlight, whole lot of dirt just floating in the air (no noise nor grain!), mixed with noise and filmgrain. Sounds interesting? Huh? ;)

With XviD 2pass, Didee's 6of9, it looks rather good, with some errors I could live with. With x264 it looks simply terrible: sometimes every kind of noise/dust/dirt disappear, making the whole fight unnatural, and the smithy automagically clean, sometimes it appears partially + there's terrible banding on the walls.

:devil: ;) ;) ;)

Well make little sample (30 sec for example) ...

[HeadBangeR77]

Well make little sample (30 sec for example) ...
I don't have to. I've already got a test clip (about 30 minutes long), 672x288, Video + MP3 VBR V2, encoded with over ten different matrices in XviD, twice in DivX (MPEG, H.263 Opt.), and twice in x264 (rev.600 I think) at exactly the same bitrate (target bitrate 1348 kbit/s, target filesize 355MB), so the rest should be no match for x264, considering the bitrate.*

I also have two full XviD encodes i.e. with Didee's 6of9 + MP3 (video about 1820kbps), and Heini's MR + AC3 (video @ 1570 kbps), 720x304, that should be a better comaparison for x264, considering the superiority of the latter.

Trying to remain objective, no matter how well x264 does throughout the clip (and it looks better than other clips in most parts), it fails poorly in this particular scene. I'm talking about clips at the same bitrate.

Now, if you tell me if I'm allowed to upload copyrighted material, including a part of the original VOB (and how to cut the latter), and where to upload, I'm gonna do it.

* Not to mention I had encoded those in two passes fast/full 2nd in XviD (MSP=6, VHQ=1), and two full slow passes in x264 with almost everyting turned on (aske me about settings after some monts, I could recall most of them).

PS. Wouldn't it be better to upload just a part of the original VOB?

[Sagittaire]

Now, if you tell me if I'm allowed to upload copyrighted material, including a part of the original VOB (and how to cut the latter), and where to upload, I'm gonna do it.


1) Just 30 sec from this particular scene ... done the frame number or the time interval if you don't want or can't upload original vob sample

2) You use XviD at q2 I suppose ... ???

3) try this setting

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

INTRA4X4_LUMA =
12,12,14,16,
12,14,16,20,
14,16,20,25,
16,20,25,32

INTRA4X4_CHROMAU =
12,12,14,16,
12,14,16,20,
14,16,20,25,
16,20,25,32

INTRA4X4_CHROMAV =
12,12,14,16,
12,14,16,20,
14,16,20,25,
16,20,25,32

INTER4X4_LUMA =
14,14,15,16,
14,15,16,20,
15,16,20,25,
16,20,25,32

INTER4X4_CHROMAU =
14,14,15,16,
14,15,16,20,
15,16,20,25,
16,20,25,32

INTER4X4_CHROMAV =
14,14,15,16,
14,15,16,20,
15,16,20,25,
16,20,25,32

INTRA8X8_LUMA =
12,12,12,12,13,14,15,16,
12,12,12,13,14,15,16,17,
12,12,13,14,15,16,17,19,
12,13,14,15,16,18,20,22,
13,14,15,16,18,21,24,27,
14,15,16,18,21,26,27,37,
15,16,17,20,24,27,39,48,
16,17,19,22,27,37,48,68

INTER8X8_LUMA =
14,14,14,14,15,15,16,16,
14,14,14,14,15,15,16,16,
14,14,14,15,15,16,16,17,
14,14,15,15,16,16,17,18,
15,15,15,16,17,18,19,21,
15,15,16,16,18,20,22,26,
16,16,16,17,19,22,27,32,
16,16,17,19,21,26,32,44

[dukey]

I've found at high bitrates theres not a lot of difference between xvid and x264. At very low bitrates x264 looks miles better. But at medium bitrates sometimes the deblocker kills details which it really shouldn't But i suppose that's the trade off.

[HeadBangeR77]

1) I've got nothing against uploading a small part of a VOB (a bit larger, 3629 frames, half of that scene), just don't know how to cut it and where to upload. This would be the easiest way, so everyone could experiment with the source, for scientific reasons, of course. ;)

2) If I were at my home, I could make a torrent out of this, but I'm somewhere else, behind NAT, with no ports forwarded, and 8KB/s upload speed.

3) I'm familiar with the settings you've recommended, though I'm Vwf kind of guy (just don't kill me :D). To be continued in the next post.

4) And don't get me wrong - I'm just a user, who made many samples some time ago in order to come to conclusion, what would serve his needs. It turned out then, that even standard XviD settings + some custom matrices (even Soulhunter's V6, which should be standard MPEG's equivalent) preserved the mentioned scene better than x264, 2pass encode, I repeat, exactly the same bitrate (DivX 6.4 was a mistake, btw. :D). Qunatization was much higher than Q2 ment for archiving.

5) I'm encoding fast samples atm: XviD 1.1.2 Koepi's build, MSP=5, VHQ=1, VHQ for b-frames, Chroma ME, Turbo, Trellis, b-frames 2/1.62/0.0 (no Qpel nor any other options on):
a) Quantizer 2
- Heini's SixOfNine,
- Didee's SixOfNine,
- Soulhunter's V3,
- Heini's MR,
- Sharktooth's V3 HR.
b) Quantizer 3
- the same ;)
Note: for future reference, when I've already cut and uploaded that damned piece of VOB, so that you can experiment on it as long as you can.

I'm not using Q2 as a rule, since I'm not interested in 1pass final encodes, though I usually make dozens of samples @ Q3 with different matrices.

<smoke>

[Sharktooth]

I've found at high bitrates theres not a lot of difference between xvid and x264. At very low bitrates x264 looks miles better. But at medium bitrates sometimes the deblocker kills details which it really shouldn't But i suppose that's the trade off.
lower the deblocking then ;)

[HeadBangeR77]

1) Just 30 sec from this particular scene ... done the frame number or the time interval if you don't want or can't upload original vob sample
As I wrote above, I've got nothing against, just name a tool and a server I could upload to (it's 4 A.M. and I'm not that clever anymore :D).

2) You use XviD at q2 I suppose ... ???
As I wrote above. The samples I've made were 2pass encodes, aiming at desired filesize. I'm not interested in preserving everything at the cost of storage space.

3) try this setting

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
I used then 2 b-frames (so no pyramid), b-rdo, bidirectional me, weightb, max. 5 referene frames, mixed references, direct mode auto, deblock 0/0 and -1/-2 (2 samples), and everything else turned on (partitions 8x8, 4x4, chroma ME, CABAC) aprat from trellis, but I kept DCT decimate instead. Uneven multihex (range 16), and that's all I remember (I haven't messed up with x264 settings since then too much).

I already see that disabling 4x4 partitions, and DCT decimate, could improve things a bit, in terms of keeping grain/dust/dirt (that ment to be there, of course), and in terms of speed. How it would influence the accuracy of such an encode? Keep in mind I don't change any XviD settings nor a matrice I've chosen for certain encode, just to keep the grain. That would be ridicolous, with all due respect. :D

And undestand, plz, one thing: you're interested in comparing codecs' absolute thresholds and capabilities, 'cause that's a part of your job, I assume. I do totally different things in life, and treat encoding as a hobby (a serious one), so:
- I'm interested in 2pass encodes, since space is an issue, but not as big, that I would have to switch to x264 because of that;
- Time does matter, and there's no match for XviD (mixed first pass at constant quantizer is quick, second pass is always a tad faster than x264, even with VHQ4 and Qpel);
- I'm not into x264 cqms;
- I lack some technical background (just some loose thoughts).

good nite :)

PS. Now the discussion will heat up, or even blaze :D

[HeadBangeR77]

Just to give you guys an idea, what I'm talking /writing about:
(not quite a hosting for this kind of stuff, but who cares? :p)

http://www.hidebehind.com/thumbs3/73D4AA70.png (http://www.hidebehind.com/73D4AA70)

http://www.hidebehind.com/thumbs3/E130826.png (http://www.hidebehind.com/E130826)

http://www.hidebehind.com/thumbs3/EEA5EBF2.png (http://www.hidebehind.com/EEA5EBF2)

http://www.hidebehind.com/thumbs3/A763BCB8.png (http://www.hidebehind.com/A763BCB8)

http://www.hidebehind.com/thumbs3/D59B67A7.png (http://www.hidebehind.com/D59B67A7)

http://www.hidebehind.com/thumbs3/73F4EDA1.png (http://www.hidebehind.com/73F4EDA1)

http://www.hidebehind.com/thumbs3/571C95.png (http://www.hidebehind.com/571C95)

http://www.hidebehind.com/thumbs3/2137B130.png (http://www.hidebehind.com/2137B130)

MPC, VMR9, RGB32, taken as bmps, zipped into pngs using a special plugin (6 passes :D).

cheers,
HDBR77

[*.mp4 guy]

Heres (http://www.megaupload.com/?d=ODLI8UTC) a short clip from War of the Worlds, which is an insanely grainy movie, and just to be really cruel its from a scene with lots of water. you can tell how bad it is from the blatant compresion artifacts on the dvd.

Anyway, if this is going to turn into a "which is better" comparison between asp and avc implementations use this script to keep things more or less comparable.

MPEG2Source("VTS_02_1.demuxed.m2v", cpu=0, idct=4, info=3).colormatrix(hints=true).crop(4,8,-4,-8)
lanczosresize(704, 384, taps=4)

[shon3i]

1) Just 30 sec from this particular scene ... done the frame number or the time interval if you don't want or can't upload original vob sample

2) You use XviD at q2 I suppose ... ???

3) try this setting

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

And 20 hours to encode with this settings plus quality is one big ?

@*.mp4 guy i haved big problems with that film, and asp(XviD) shows much quality in this such scenes.

[Morte66]

As I wrote above, I've got nothing against, just name a tool and a server I could upload to (it's 4 A.M. and I'm not that clever anymore :D).

This is how I usually upload samples for discussion at Doom9:

Launch DGIndex, drag the VOB(s) onto DGIndex, select the start/end of a short clip with the '[' and ']' buttons, then select "Save project and demux video" from the file menu. That will create a file with a name like "something.demuxed.m2v", which is a plain mpeg2 video file (no sound). Upload that file to www.rapidshare.com.

[Sagittaire]

Heres (http://www.megaupload.com/?d=ODLI8UTC) a short clip from War of the Worlds, which is an insanely grainy movie, and just to be really cruel its from a scene with lots of water. you can tell how bad it is from the blatant compresion artifacts on the dvd.

Anyway, if this is going to turn into a "which is better" comparison between asp and avc implementations use this script to keep things more or less comparable.

MPEG2Source("VTS_02_1.demuxed.m2v", cpu=0, idct=4, info=3).colormatrix(hints=true).crop(4,8,-4,-8)
lanczosresize(704, 384, taps=4)

Well XviD q2 with uhr done more than 10 Mbps, I have no doubt that x264 obtain good result at 10 Mbps for 400p encoding ... !!?

What must be my setting for XviD ... ???

[check]

At 10mbits per second, x264 is more or less identical to the original stream for me.
I used this commandline with the latest x264 build from sharktooth:
--crf 18 --nf --analyse all --8x8dct --cqmfile "M4G HRM V1.cfg" --deadzone-intra 4 --deadzone-inter 6
This came out at 55mb, which is more like 10.5mbits, and an I frame QP of 20.6. I'm sure the 500kbit reduction would have little image impact when you factor in the quality gain from 2pass, using better x264 settings, etc etc.

btw, this is a dirty great bitrate chowing scene! :)

[Sagittaire]

At 10mbits per second, x264 is more or less identical to the original stream for me.
I used this commandline with the latest x264 build from sharktooth:
--crf 18 --nf --analyse all --8x8dct --cqmfile "M4G HRM V1.cfg" --deadzone-intra 4 --deadzone-inter 6
This came out at 55mb, which is more like 10.5mbits, and an I frame QP of 20.6. I'm sure the 500kbit reduction would have little image impact when you factor in the quality gain from 2pass, using better x264 settings, etc etc.

btw, this is a dirty great bitrate chowing scene! :)

Yes ... really no problem for x264 here if you compare with XviD q2@uhr (90 Mo) and XviD q2@h263 (54 Mo). Moreover here make ASP encoding is really completely useless simply because the 704*384 encoding done 90 Mo with 720*480 source at 35 Mo.

next example ... ;-)

[*.mp4 guy]

:rolleyes: The issue isn't detail preservation, not at that bitrate, the issue is that X264 leaves behind artifacts at that birate, while Xvid doesn't, which makes Xvid better since it takes about the same bitrate to get all of the sources details as X264, but doesn't have any artifacts. And If you can't see the artifacts in low contrast areas, amoung a few other quibles there isn't anything I can do to convince you.

[Sagittaire]

:rolleyes: The issue isn't detail preservation, not at that bitrate, the issue is that X264 leaves behind artifacts at that birate, while Xvid doesn't, which makes Xvid better since it takes about the same bitrate to get all of the sources details as X264, but doesn't have any artifacts.

You want really comparison between XviD and x264 at 17 Mbps for this source ... !!!?

Let's go ...

[*.mp4 guy]

You want really comparison between XviD and x264 at 17 Mbps for this source ... !!!?

Let's go ...
I'm Afraid i don't see what your playing at, Xvid is visually lossless at 8-10 mbps, while X264 isn't, why would I use a higher bitrate?

[Sagittaire]

I'm Afraid i don't see what your playing at, Xvid is visually lossless at 8-10 mbps, while X264 isn't, why would I use a higher bitrate?

Simply because XviD q2@uhr done this bitrate. XviD q2@h263 done 10 Mbps. I use h263 quantisation for XviD ... ???

[*.mp4 guy]

fine, go to 17 mbps then, it won't make a difference, the artifacts don't go away, thats the problem you can throw as much bitrate at x264 as you wan't they will never go away, well until you use lossless mode atleast.

[edit] Furthermore Xvid with the fox home entertainment matrix @Q3 is visually lossless to me on this source, sometimes you loose a touch of high frequency detail with those settings, but this source is so heavily filtered and compressed there isn't anything to loose, so for visually transparent results on this source Xvid comes out at 10.6 Mbps not 17mbps.

[Sagittaire]

fine, go to 17 mbps then, it won't make a difference, the artifacts don't go away, thats the problem you can throw as much bitrate at x264 as you wan't they will never go away, well until you use lossless mode atleast.

[edit] Furthermore Xvid with the fox home entertainment matrix @Q3 is visually lossless to me on this source, sometimes you loose a touch of high frequency detail with those settings, but this source is so heavily filtered and compressed there isn't anything to loose, so for visually transparent results on this source Xvid comes out at 10.6 Mbps not 17mbps.

Done a clear example with frame and zoom ... thx

[HeadBangeR77]

This is how I usually upload samples for discussion at Doom9:

Launch DGIndex, drag the VOB(s) onto DGIndex, select the start/end of a short clip with the '[' and ']' buttons, then select "Save project and demux video" from the file menu. That will create a file with a name like "something.demuxed.m2v", which is a plain mpeg2 video file (no sound). Upload that file to www.rapidshare.com.
Thank you very much for the tip. :)

:thanks:

I was trying to demux just one specific cell from the right chapter (IFO mode, stream processing, just the main video stream, no audio nor any other stuff), and I sucseeded. Unfortunatelly I had no idea after that, how to cut the damned vob, which turned out to be 100MB large (5480 frames, 29.970 fps, 100% film). Following your instructions (didn't think that would be so easy ;)) I'm left with a nice sample (65.5 MB, 3395 frames, 29.970 fps), which is too big again. I won't stop trying, but I'm afraid I have to wait till tomorrow to get home, where I've got about 768 kbit/s upload speed. Thanks again.

@ *.mp4 guy
I will have a look at your source, when I'm able to acces your host (all slots closed for Poland atm, sorry). Btw. What is your source like, comapring to mine, if you could judge from those screenshots I posted? In my sample there's all kind of motion, quick action and slow close-ups, all in dust, dirt, grain and noise as well. :D

To be continued ;)

PS. The demuxed *.m2v still remains 29.970, so you would have to force film, and create a new *.d2v project.

[*.mp4 guy]

This (http://img259.imageshack.us/img259/332/lightblockinguj5.png) screenshot shows the problem pretty clearly (make sure to open it in a media player and view it fullscreen). Here (http://img201.imageshack.us/img201/1930/lightblockingwithenhanczz7.png) is a version with enhanced overal contrast and enhanced blue channel contrast to make the problem more obvious, it is also zoomed 2X with bicubic interpolation.

there isn't anything special about this source to make it exhibit this problem, infact its a rather poor example of it.

With all of this said I am getting very tired of rehashing this topic I guess most people just don't see the artifacts.

[Sharktooth]

ensure you're not using CoreAVC for decoding coz it introduces blocks in dark areas that are NOT in the encode...
however dont generalize...x264 is just ONE of the h.264 codecs. IF it has problems in dark areas that doesnt means h.264 (as a standard) has problems in dark areas.

[*.mp4 guy]

I know, I'm using FFDshow.

[edit] I'm not generalizing, I have not once said that h.264/AVC has problems with banding blocking compared to ASP, I always refer specifically to X264 because that is the only Mpeg4-AVC/H.264 complient encoder I use, AVC as a standard may have a problem with banding/blocking in certain situations, and based on my limited experience with other encoders I think it needs to be considered as a potential problem; but I have not once claimed that it is a problem with the AVC standard, I have only said that it is a problem with X264.

[Sagittaire]

This (http://img259.imageshack.us/img259/332/lightblockinguj5.png) screenshot shows the problem pretty clearly (make sure to open it in a media player and view it fullscreen). Here (http://img201.imageshack.us/img201/1930/lightblockingwithenhanczz7.png) is a version with enhanced overal contrast and enhanced blue channel contrast to make the problem more obvious, it is also zoomed 2X with bicubic interpolation.

there isn't anything special about this source to make it exhibit this problem, infact its a rather poor example of it.

With all of this said I am getting very tired of rehashing this topic I guess most people just don't see the artifacts.


1) Well for me real comparison is comparison between source and encoding.

2) Make comparison with enhanced overal contrast and enhanced blue channel contrast is really not a good way for make comparison.

3) You see a problem for the choma chanel. If the quality for the chroma chanel is not good for you change simply the chroma qp offset.

[*.mp4 guy]

1- fine, you have the source, look at it yourself.

2- the blue is just a neet way to make it glaringly obvious, it is perfectly obvious with only contrast enhancement, if you don't like it, ok, but it is effective in showing the problem.

3- it is not a problem with the chroma channel, the blue was only a way of highlighting luma differences, furthermore the blue enhancement was done in RGB colorspace so it was using luma and chroma information.

[Sagittaire]

2- the blue is just a neet way to make it glaringly obvious, it is perfectly obvious with only contrast enhancement, if you don't like it, ok, but it is effective in showing the problem.


Well it's simply not a good way. Some HVS tunnig use for example higher quantizer in dark area but if you make modification for the image (more unatural constrast or more unatural luma) the HVS tunnig well be visualy not good in this case.

You show simply artefact (if there are really artefacts) that in the real conditions it will be impossible to see.

Moreover in this case make q2@uhr or q3@uhr is a completely useless and absurd example ...

[HeadBangeR77]

Well XviD q2 with uhr done more than 10 Mbps, I have no doubt that x264 obtain good result at 10 Mbps for 400p encoding ... !!?

What must be my setting for XviD ... ???
Sagittaire, I mean no offence, but you seem to act so quickly, that you miss some points and statements I've made (even more than just once ;)). If we are to discuss and test, then plz make an effort and read what I've written, at least once.

http://forum.doom9.org/showpost.php?p=945765&postcount=34

"I'm encoding fast samples atm: XviD 1.1.2 Koepi's build, MSP=5, VHQ=1, VHQ for b-frames, Chroma ME, Turbo, Trellis, b-frames 2/1.62/0.0 (no Qpel nor any other options on)..."

Encoding speed on my old Athlon XP-M @ 11x220, 2x512MB Mushkin TCCD 2-3-3-11: about 35-36 fps.

This is the way I make some quick samples. For more quality in one-pass encodes you'll need:
MPS=6, VHQ=2/3*, VHQ for b-frames, Chroma ME, Trellis and Qpel, b-frames 2/1.62/0.0 (no Turbo nor any other options on).
* VHQ=4 could have problems with grain & noise.

Encoding speed: 13-15 fps, as far as I can remember, which is still way above x264 & my current hardware.

I've already listed the matrices used, so I won't do it again. Of course you could use others, as you've already done (like Sharktooth's EHR, UHR, Fox Entertaiment, Semi-Insane etc., although it doesn't make sense to me).

<smoke>

EDIT coming soon. ;)

[HeadBangeR77]

Well it's simply not a good way. Some HVS tunnig use for example use higher quantizer in dark area but if you make modification for the image (more unatural constrast or more unatural luma) the HVS tunnig well be visualy not good in this case.

You show simply artefact (if there are really artefacts) that in the real conditions it will be impossible to see.
Although I do see those artifacts, I must agree with you. :)

Moreover in this case make q2@uhr or q3@uhr is a completely useless and absurd example ...
I can see your point, but you speak of very high bitrates, as if you wanted to test the ultimate codec's capabilities, and on the other hand you seem to limit that bitrate. If you had read what I had written before, I'm not interested in one-pass-extremely-high-bitrate encodes.

I'm doing samples atm, but try to keep them in reasonable bitrate & size, so that they won't get bigger than the VOB itself (which is, as I wrote, 65.5MB).

I've spotted the artifacts and came to the conclusion, XviD was better for that source, while doing 2-pass sample clips (for details see one of my first posts). XviD produced better quality in this particular scene, at the same bitrate (sic!).

I'm not trying to claim a specified codec is better or worse: I'm trying to say, that for certain sources and certain bitrates, XviD is still a match for x264.

Savvy? ;)

[Sagittaire]

Sagittaire, I mean no offence, but you seem to act so quickly, that you miss some points and statements I've made (even more than just once ;)). If we are to discuss and test, then plz make an effort and read what I've written, at least once.


No offence at all but here I speak about *.mp4 guy sample.

Moreover IMO XviD q2 with high quality matrix is a completely useless setting for me. In this bitrate interval MPEG2 will begin to done very good result with really better hardware compatibility and really better authoring capacity (DVD)

[HeadBangeR77]

No offence at all but here I speak about *.mp4 guy sample.
And I know this, especially because I haven't uploaded my VOB yet. But I wanted to concentrate on some other points of discussion, like e.g. desired filesize and encoding's total time, apart form just bumping the bitrate up to 10 Mbit/s for a resized encode. Hence my reference to my previous posts, as well as some recommendations as to XviD encoding ;)

Moreover IMO XviD q2 with high quality matrix is a completely useless setting for me. In this bitrate interval MPEG2 will begin to done very good result with really better hardware compatibility and really better authoring capacity (DVD)
And that's utterly true. :) I would like to prove it's possible to keep a reasonable transparency for an XviD encode at some reasonable bitrate, keeping some filmgrain and scene's natural dust & dirt, hence I'm experimenting with samples atm. Try Didee's SixOfNine Q3, Heini's SixOfNine Q3 and Heini's MR Q2/Q3.

cheers,
HDBR77

Btw. What about my question? Would turning off some advanced AVC settings like 4x4 partitions, DCT Decimate etc., just to keep some filmgrain, harm the overall quality? Would it harm quality at constant quant or just make the file bigger or would harm the quality in case of 2-pass encode with target filesize/bitrate? I don't have to mess with XviD settings to retain the discussed details.

[Sharktooth]

it will make the file bigger or harm the quality in case of 2 passes (fixed filesize). However "harm the quality" means it will lower the metrics (PSNR, SSIM) that do not necessarily represent the "perceived quality"...

[HeadBangeR77]

it will make the file bigger or harm the quality in case of 2 passes (fixed filesize). However "harm the quality" means it will lower the metrics (PSNR, SSIM) that do not necessarily represent the "perceived quality"...
Thanks very much for the quick and precise answer (the best metrics are my own eyes, especially late at night with no other lights, but just my pc and me :D).

I'm finishing my sample-encodes and I've just come to the conclusion, it would be good to make a two-pass encode with my sample vob, anomorphic! :

1) VOB is 65.5 MB large, so let's say we want to save some space (that's MPEG-4 all about, isn't it?), and make it 40-45 MB (the same for XviD and x264 or should we lower the filesize in case of x264, because of its more advanced capabilites?). I would suggest:
45MB for XviD
38MB for x264

(???)

2) I think we should enable/disable what options we want (XviD, x264), use custom CQM of our choice, but no filters at all, and encode the sample into a container of our choice (AVI, MP4, MKV, OGG etc.).

3) Two passes, no matter if the first is fast or full, or a hybrid (which is my choice). The script (cropping and PAR) I'll post later, this evening yet.

Would the above be an objective comparison? We could let everybody just download the encodes and say what they think about it. I don't need any metrics, but let's say SSIM (and maybe MSU Blocking - sounds suitable for this test ;)) could go.

cheers,
HDBR77

PS. @ foxyshadis
The scene is crazy, true enough, so the problem is in keeping as much grain/dust/goodness knows what as possible, because it's natural for this particular scene. X264 makes it so clean, that it doesn't look like a XVIIth century's fight in an old smithy, but more like star wars or sth :D
And the above can't be done at all cost imo - so bitrates like 10 Mbit/s are excluded, since the source is roughly 4-5 Mbit/s (here I agree with Sagittaire).

[foxyshadis]

Well it's simply not a good way. Some HVS tunnig use for example higher quantizer in dark area but if you make modification for the image (more unatural constrast or more unatural luma) the HVS tunnig well be visualy not good in this case.

You show simply artefact (if there are really artefacts) that in the real conditions it will be impossible to see.

Moreover in this case make q2@uhr or q3@uhr is a completely useless and absurd example ...

I've never heard anyone describle a film effect as "natural", but most movies are filmed with all kinds of effects. The whole point of having an advanced video codec is to better handle the things that threw cogs into older codecs. Stop apologizing for x264, we all agree it's a great codec but the thread is about specific limitations it has and possibly how to mitigate them; simply saying they don't exist and the people who see them can't really see them isn't helping.

I don't know if there's any way to warp the grain to convince the encoder to keep it, without working on a parametric way of doing it, though. (Which may be as simple as a file with frame ranges and ffdshow settings. I started such a thing but abandoned it as needing more thought in the design first.) Especially for such a crazy scene as headbanger77's.

[DarkZell666]

[evilmode on]
I don't know if there's any way to warp the grain to convince the encoder to keep it,I like the word "warp" :p
So, basically, rather than telling x264-the-bastard to be a nice guy with poor little shy grain, we should teach the grain to be less impressionable so that x264-the-bastard isn't tempted to punch it's face too often :P
[evilmode off]

What about ... medium frequency "sharpening" rather than edge (high frequency) sharpening ? That's what grain is, after all, isn't it ? (more or less ...)

[*.mp4 guy]

I think some people missed the point of that example, which is that there are some things X264 just isn't any better at then Xvid, for these situations it makes more sense to use Xvid because it doesn't cause any unique problems, the clip was supposed to demonstrate this, not the artifacts x264 produces on more subdued areas of the picture.

Sagittaire also seems to have gottent the impression that I am "against" X264 (or advances in videocoding in general) Which couldn't be farther from the truth; Just look at all the time I spend here, the matrices I made for X264 etc. Just because I acknowledge problems when I find them (and do my best to find ways that I can work around them) doesn't mean that I'm against advances in video coding, it just means that If the best solution in certain situations is to use a less advanced codec I will use the best solution not the newest.

Sorry if I pulled this thread to far off topic, that wasn't my intent.

[HeadBangeR77]

I think some people missed the point of that example, which is that there are some things X264 just isn't any better at then Xvid, for these situations it makes more sense to use Xvid because it doesn't cause any unique problems, the clip was supposed to demonstrate this, not the artifacts x264 produces on more subdued areas of the picture.
I agree with you form the first to the last letter of your statement (see my post here (http://forum.doom9.org/showpost.php?p=946100&postcount=58)).

as well as with ...

Just look at all the time I spend here, the matrices I made for X264 etc. Just because I acknowledge problems when I find them (and do my best to find ways that I can work around them) doesn't mean that I'm against advances in video coding, it just means that If the best solution in certain situations is to use a less advanced codec I will use the best solution not the newest.

Sorry if I pulled this thread to far off topic, that wasn't my intent.
I think everything we've been talking about is still about pros and cons of the two mentioned codecs, so it perfectly suits the thread's name. ;)

Btw. Didee's SixOfNine seems to eat much from my sample, while Heini's SixOfNine preserves everything (both are in the same league). Screenshots to be uploaded later (the sample probably tomorrow).

cheers,
HDBR77

[FAII]

Is 3 pass really worth it? I encode all of my videos in 2 pass. My friend tells me there's barely any difference between 2 pass and 3 pass.

[DarkZell666]

FAII (you're way off topic btw) : there are many topics about 2-pass vs. 3-pass and the true answer is ? .... tadaaaaaaaa! => It depends ! :p
Try encoding a sample with 2- ans 3-passes and compare for yourself, that's the best advice that can be given to you imho, because wether the 3rd pass is worth the time spent on it is your choice :)

[FAII]

OK, let's switch from "Is it worth it?" to "Is it always better (no matter how little)?"

And could you link to these threads? I can't find them.

[MySchizoBuddy]

2006 codec benchmark wasn't done right
I'm still waiting for the Vc1 and h.264 comparison

[Theliel]

for me is easy. X264 is the best video codec at the moment, but is posible that sometimes is better use Xvid.

VC1 Vs H.264... well, H264 are more powerfull and better codec, but yes, I'll like view some test too. I haven't time for make some of them.

[Sharktooth]

OK, let's switch from "Is it worth it?" to "Is it always better (no matter how little)?"

And could you link to these threads? I can't find them.
3rd pass is only useful if rate control misses the desired bitrate (but it happens very rarely).
for what concerns "grain" in modern movies, it's digitally added... so by removing it you actually do what you're supposed to...
re-adding it during playback is as easy as a mouse click (with ffdshow)...
however dont forget to use (lower) the deadzone parameters in x264 that are supposed to "help" preserving noise and grain...
for what concerns my encodings i never found a case where xvid would be superior to x264 in terms of global quality of a movie...

[HeadBangeR77]

Attention! Achtung! Pozor! Uwaga!
There will be a new download link very soon (thanks to DarkZell666), so if you're sick of multiple clicking and waiting at rapidshare, you will able to download directly the whole sample from an ftp!
Update: The new link is already avaliable here:
http://forum.doom9.org/showpost.php?p=947397&postcount=85

My best sample encodes at constant quantizer are here:
http://forum.doom9.org/showpost.php?p=947231&postcount=83

cheers

...

Although I still haven't got my normal internet accses (1.5Mbit/768kbit FTTH) and have to stick to some shitty-almost-modem-speed shared ADSL connection, I will upload the promised sample tonight, if anyone is still interested (hope so!) ;)

I have packed the sample, including d2v project (forced film, sometimes two projects differ a bit then) and the suggested aviscript (idct, cropping, resizing), with WinRAR and split it into 4 pieces, just in case sth might go wrong while uploading (8 KB/s, no comments). I'm gonna update this post with further links to the upload, for now, here's the first part:

http://rapidshare.com/files/14170724/Black.Pearl.Sample.VOB.part1.rar

and finally the next ones:

http://rapidshare.com/files/14176578/Black.Pearl.Sample.VOB.part2.rar

http://rapidshare.com/files/14180722/Black.Pearl.Sample.VOB.part3.rar

http://rapidshare.com/files/14182108/Black.Pearl.Sample.VOB.part4.rar

thanks for your patience and may the force be with you! :D

HDBR77

[HeadBangeR77]

In the meantime ...

I've done some samples at constant quantizer over the last few days, in order to check, if XviD is capable of preserving every detail from the mentioned killer-scene, even at the cost of high bitrate. I'll post some screenshots later, however they can't give back the overall impression one could get only while watching whole samples. I would like to remind you, that the original VOB is
65.5 MB large, 16:9 anomorphic widescreen (1:2.35 /1:2.40) NTSC, so there's not much left after cropping black bars (712x360).
Therefore I decided to resize (I usually either downsize or upsize) to 720x304 square pixels - not a big hit in terms of quality imo, and it goes a tad faster.

0) The original VOB MPEG-2
http://www.hidebehind.com/thumbs3/B92FC654.png (http://www.hidebehind.com/B92FC654)
http://www.hidebehind.com/thumbs3/B4BDB289.png (http://www.hidebehind.com/B4BDB289)

1) Heini's SixOfNine @ Q2 - 75.6 MB, 4186 kbps
This one has managed to keep everything I wanted to keep, or at least to keep the overall grainy impression, including dust & dirt, which are an integral part of the scene. Though I think the cost is too big, since it's bitrate is higher than the original MPEG-2. Still, it's better than 10 Mbit/s mentioned somewhere above in this thread.
Nevertheless, once or twice, there are some artifacts visible, as if the codec wanted to swallow the grain, but couldn't (some dust and grain flickering, or dead zones derived of dust). Only visible while watching at very high brightness, frame by frame.
http://www.hidebehind.com/thumbs3/F5BFFBB1.png (http://www.hidebehind.com/F5BFFBB1)
http://www.hidebehind.com/thumbs3/ECECA752.png (http://www.hidebehind.com/ECECA752)

2) Didee's SixOfNine @ Q2 - 70.0 MB, 3877 kbps
This matrice has produced some nice effect, eating more of the filmgrain and dust than the previos, yet making it more evenly, without rapid changes or any artifacts I could spot. If I had to choose between those two, it would really be a hard choice to make. Bitrate still above the original!
http://www.hidebehind.com/thumbs3/27A0CC9C.png (http://www.hidebehind.com/27A0CC9C)
http://www.hidebehind.com/thumbs3/A9B3FACC.png (http://www.hidebehind.com/A9B3FACC)

3) Soulhunter's V3 @ Q2 - 54,8 MB, 3031 kbps
This one was tricky, I must admit. It doesn't play in the same league as the first two ones, however the overall impression was very good and it managed to keep the damend grain & dust very well. As a con, I could say the image was somehow softer, not so sharp as in case of the first two. On the other hand the bitrate was reasonable, at least!
http://www.hidebehind.com/thumbs3/D786326C.png (http://www.hidebehind.com/D786326C)
http://www.hidebehind.com/thumbs3/E37000C8.png (http://www.hidebehind.com/E37000C8)

4) Heini's MR (modded V3 HR) @ Q2 - 52.7 MB, 2915 kbps
It may sound crazy, but this one kept a bit less grain & dust than the previous, however the overall impression was a bit better, as if the image was a bit sharper or sth similar. Of course, no match for the first two, but the bitrate was kept in reasonable limits. 3 and 4 have the best quality/size ratio imho.
http://www.hidebehind.com/thumbs3/11BB6506.png (http://www.hidebehind.com/11BB6506)
http://www.hidebehind.com/thumbs3/6874F41D.png (http://www.hidebehind.com/6874F41D)

5) Sharktooth's V3 HR @ Q2 - 52.0 MB, 2877 kbps
V3 HR did the worst job in this amateur comparison, however I wouldn't say it failed badly. Although the difference in bitrate against its modded version was mariginal, it kept less grain and was somehow softer, yet managed to keep a decent overall impression (has not ruined the scene, in other words).
http://www.hidebehind.com/thumbs3/FB2EBF18.png (http://www.hidebehind.com/FB2EBF18)
http://www.hidebehind.com/thumbs3/A1E0E95C.png (http://www.hidebehind.com/A1E0E95C)

At quantizer 3, what I expected, all the matrices has swallowed too much. Heini's 6of9 did relatively well, if I had to name the winner, Didee's 6of9 has kept its face as well. Soulhunter's matrice failed at this quant unfortunatelly, turning the grain into some kind of moving, unnatural haze or fog (that's exactly what x264 did in my early tests). Heini's MR did a bit better this time, although it didn't look to well in terms of "grain retention". :D Sharktooth's one similar, maybe a bit worse then its competitors. I will just give the final bitrate and post screenshots again.

6) Heini's SixOfNine @ Q3 - 43.4 MB, 2401 kbps
http://www.hidebehind.com/thumbs3/4D07C1CA.png (http://www.hidebehind.com/4D07C1CA)
http://www.hidebehind.com/thumbs3/E2253CFB.png (http://www.hidebehind.com/E2253CFB)

7) Didee's SixOfNine @ Q3 - 41.1 MB, 2269 kbps
http://www.hidebehind.com/thumbs3/A447220E.png (http://www.hidebehind.com/A447220E)
http://www.hidebehind.com/thumbs3/7D59D3F8.png (http://www.hidebehind.com/7D59D3F8)

(the rest in the next post because of forum's limitations)

Settings (fast sample) as listed ...here... (http://forum.doom9.org/showpost.php?p=945765&postcount=34), haven't tried the more accurate ones as suggested ...here... (http://forum.doom9.org/showpost.php?p=946091&postcount=57), and I probably won't because of time issues.
Plz view at full screen with as much brightness as possible (I personally use QPQ function in my Iiyama CRT monitor).

2-pass samples I have, but I'm already tired of all this. I could upload the best one, if someone was interested.

Good night everyone! :)

PS. Just a tip, seems obvious, but ... the png size may suggest the amount of details in each frame, since they were compressed using the same pngout-plugin (6 passes).

[R3Z]

Well done man, if you want web space to host these or any other projects that give a visual representation - please let me know and its yours.

That goes for anyone else too.

[HeadBangeR77]

8) Soulhunter's V3 @ Q3 - 29.8 MB, 1643 kbps
http://www.hidebehind.com/thumbs3/5733178A.png (http://www.hidebehind.com/5733178A)
http://www.hidebehind.com/thumbs3/FF27461B.png (http://www.hidebehind.com/FF27461B)

9) Heini's MR (modded V3 HR) @ Q3 - 31.3 MB, 1728 kbps
http://www.hidebehind.com/thumbs3/1F790A90.png (http://www.hidebehind.com/1F790A90)
http://www.hidebehind.com/thumbs3/30ED6DE0.png (http://www.hidebehind.com/30ED6DE0)

10) Sharktooth's V3 HR @ Q3 - 30.6 MB, 1690 kbps
http://www.hidebehind.com/thumbs3/7DE0D4.png (http://www.hidebehind.com/7DE0D4)
http://www.hidebehind.com/thumbs3/54A1C5B8.png (http://www.hidebehind.com/54A1C5B8)

11) My script for upsizing (despite of some denoising involved, looks good) - Heini's SixOfNine Q3
http://www.hidebehind.com/thumbs3/5938A6AA.png (http://www.hidebehind.com/5938A6AA)
http://www.hidebehind.com/thumbs3/78919EEA.png (http://www.hidebehind.com/78919EEA)

12) My script for upsizing (despite of some denoising involved, looks good) - Didee's SixOfNine Q3
http://www.hidebehind.com/thumbs3/37BD3B1B.png (http://www.hidebehind.com/37BD3B1B)
http://www.hidebehind.com/thumbs3/CDCB7AE0.png (http://www.hidebehind.com/CDCB7AE0)

@ R3Z
Cheers! :) Hope all that could be of any use apart from my own curosity. ;)
Hosting might be useful, but first I must get my proper HTTH connection back, thanx in advance.

[R3Z]

@ R3Z
Cheers! :) Hope all that could be of any use apart from my own curosity. ;)
Hosting might be useful, but first I must get my proper HTTH connection back, thanx in advance.

Truly, it does help man :D

Its all well and good for others to tell people what to do, but if you are a noobie or want to learn more the only way you can get around to knowing things is a) visual representation with the settings used and b) doing it yourself.

Bookmark my name, and if you need space - let me know :)

[DeathTheSheep]

For a starter, MeGUI has baloon tips explaining the options in the x264 codec configuration.

Some of those balloon tips look quite a bit like they were ripped out of an older version of my guide...!

Just an aside, btw...

[DarkZell666]

Hmmm you did say Q2 right ? The overlayed info says it's Q3 all over ;)

[HeadBangeR77]

Hmmm you did say Q2 right ? The overlayed info says it's Q3 all over ;)
When? Where? Why? For what purpouse? :o
Gonna check it out immediately.

EDIT: I've left Q2 in the description of No 6-10, just a typo (it's written above, that they were made at Q3). Edited.

Q2: 1) P 2.0, P 2.0; 2) B 3.0, P 2.0; 3) P 2.0, P 2.0; 4) P 2.0, P 2.0; 5) P 2.0, P 2.0;
Q3: 6) P 3.0, P 3.0; 7) P 3.0, P 3.0; 8) P 3.0, P 3.0, 9) P 3.0, P 3.0; 10) P 3.0, P 3.0.

Btw. Turning on Qpel blew up the size in this case, e.g. by Didee's 6of9 Q2 from 70MB to 74.5MB, yet with noticeable quality's improvement. I can't say the same is valid for pure constant quant (B 1/1/0) with Qpel - 95MB and no visual improvement, unless I'm blind. :D
Perfect quality? Standard MPEG matrix at Q1 - 144MB - pure nonsesne from quality/filesize pov. :p

PS. Could someone with better knowledge and experience in x264 try to make a sample?

[check]

your sample is really way too big to bother with. Cant you crop it down to ~50mb at the max?

[HeadBangeR77]

your sample is really way too big to bother with. Cant you crop it down to ~50mb at the max?
To download 66.5MB and to download 50MB doesn't make a large difference, does it? :confused:
I've made all my samples with this m2v (as well as all 2-pass samples, that I would have to encode again, to reach a different target filesize). The larger the samples the better for testing purpouses imo.

Also, sorry for inconvenience of splitting files, that can be downloaded only part by part after half an hour or so (I wasn't familiar with rapidshare), if one doesn't have a paid account by them. The reason was safety of upload, as stated before.

cheers,
HDBR77

[HeadBangeR77]

Here's my last post, which I will keep updating with new samples. Till now you've only got some screenshots (tried to choose those with P 2.0/P 3.0 frames, since B-frames seem to be uncapable of noise-retention ;)) and my subjective, rather brief impressions. Now I'm gonna upload a few samples I've made, starting from the best one, and finishing with the most reasonable ones, in terms of quality/filesize ratio. I would be really grateful (I know I keep repeating myself) if someone could encode such samples using x264. I'm gonna trie as well, but I don't use MEGUI nor am I into x264's custom matrices, so my encodes won't be a proper comparison for my XviD ones.

Settings as described earlier + Qpel. Turbo still on, MSP at 5, since I had a vague impression MSP 6 used to swallow more filmgrain, VHQ 1 (from the same reason).

1) The absolute killer in terms of quality and bitrate - Heini's SixOfNine @ Q2 - 80.5MB, 4456kbps

http://rapidshare.com/files/14297870/13a-H6o9-Qpel-5-1-Q2.avi

2) Imo the best among those within reasonable bitrate, really grrrainy - Soulhunter's V3 @ Q2 - 60.4MB, 3343kbps

http://rapidshare.com/files/14330263/15a-SV3-Qpel-5-1-Q2.avi

3) Maybe a bit worse than the previous, but still quite good - Heini's MR @ Q2 - 56.1MB, 3106 kbps

http://rapidshare.com/files/14340025/16a-HMR-Qpel-5-1-Q2.avi

4) Comparable to the previous one, much smaller filesize - Heini's SixOfNine @ Q3 - 45.7MB, 2525kbps

http://rapidshare.com/files/14347717/17-H6o9-Qpel-5-1-Q3.avi

(To be continued... ;)) - not valid anymore - finito! :D

[DarkZell666]

HeadBanger77: i've just sent you a pm with ftp credentials for uploading your sample (which will be better than rapidshare I guess ;)). (btw, I invite anyone who'll download the files off my mirror to report the download speed back =)).

[HeadBangeR77]

HeadBanger77: i've just sent you a pm with ftp credentials for uploading your sample (which will be better than rapidshare I guess ;)). (btw, I invite anyone who'll download the files off my mirror to report the download speed back =)).
I've sent you a pm either - it's sooo late I'm gonna upload the vob tomorrow (i.e. today, after-noon :D). Thanks a bunch, mate, much appreciated. :) Hope some x264 encodes will emerge from the tides of time then. ;)

New download links(!!!):

http://xasonline.info/headbanger/Black.Pearl.Sample.m2v
http://xasonline.info/headbanger/Black.Pearl.Sample.d2v


btw. it's working flawlessly with Total Commander & I can cap the upload speed at last, and enjoy browsing in the meanwhile!
edit: download 60 KB/s, which is my maximum with the present connection.

PS. The script:


# PLUGINS
LoadPlugin(" ... \DGDecode.dll")

# SOURCE
mpeg2source(" ... \Black.Pearl.Sample.d2v", idct=7)

# CROPPING
crop(4,58,712,360)

# RESIZING
LanczosResize(720,304)


And don't forget to change the sample path in the d2v project either. ;)

[Sharktooth]

Some of those balloon tips look quite a bit like they were ripped out of an older version of my guide...!

Just an aside, btw...
Uhm, it's possible. The baloon tips were a contribution from someone of this community. The changelog eventually shows who was the author.

[HeadBangeR77]

To sum the things up, as well to gather all the links to my uncommented efforts in one place

The thread started with a question, if x264 (eventually H.264 in general) was much better than XviD (MPEG-4 ASP). There is no doubt that x264, being a much more advanced codec, delivers better overall quality throughout the film /movie /clip, and this at the same or even lower bitrate. I don't want to go into any numbers, statistics etc., 'cause that would probably raise some pulses here, especially in the AVC forum, and this is not my intention. I was reading carefully through this thread to gather opinions, before I started to post at all. Especially the posts of DarkZell666 (http://forum.doom9.org/showpost.php?p=944722&postcount=6), *.mp4 guy (http://forum.doom9.org/showpost.php?p=944760&postcount=7) (don't forget he's really deep into AVC), and aabxx (http://forum.doom9.org/showpost.php?p=944765&postcount=8) were the ones I could agree with, more or less. Therefore I found some source, that had caused me whole lot of trouble in the past, both with XviD and x264, and proposed some sort of competition /comparison here:
http://forum.doom9.org/showthread.php?p=945716#post945716

I wanted to prove XviD handles this particular source better, both at high bitrates (1-pass samples at constant quantizer 2 & 3) and middle-high bitrates (2-pass encodes within reasonable limits of filesize). My goals, used settings and matrices can be found on pages No 2-4 of this thread, including screenshots(!) (http://forum.doom9.org/showpost.php?p=945832&postcount=37) from the source for those, that wouldn't download the sample anyway. Until now I've made dozens of samples with XviD, more or less successfully, both at constant quantizer beyond and within limits of reasonable bitrate, and 2-pass encodes within reasonable limits (46MB). In my opinion the given sample can cause a lot of trouble to any codec available today, unless we start to use some filters, which was definitely not the goal of this thread, but pure codec's capabilities and possible limitations. Till now, to my surprise and disappointment (:p), no single x264 encode has popped out!

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.

Now, before you fall asleep while reading, here are the links to the most important materials I've been dealing with over the last few days:

Post with the most important links
http://forum.doom9.org/showthread.php?p=946838#post946838

The source sample, MPEG-2, "The Curse of the Black Pearl"
http://xasonline.info/headbanger/Black.Pearl.Sample.m2v
http://xasonline.info/headbanger/Black.Pearl.Sample.d2v

Screenshots and my subjective impressions start here...
http://forum.doom9.org/showthread.php?p=946858#post946858

The best constant quality/quantizer samples are here...
http://forum.doom9.org/showthread.php?p=947231#post947231

...and the best 2-pass encodes with a bunch of screenshots:

http://forum.doom9.org/showthread.php?p=948242#post948242

PS. Hope my English is understandable. ;)

[DarkZell666]

You gotta be reading my mind mate =)

I did a couple of CQP18 encodes tweaking the deadzone/deblocking parameters and "good quality" settings=> the x264 encode comes out exactly the same size as the MPEG2 encode (~500kB near), and looses quite some grain in the background, but overall looks very good (the grain in the foreground is preserved nicely). I'll post more details later on, when I've tried the different CQM's (I wanted to get the most out of the flat one before trying something else).

-- Edit per akupenguin's following comment --
I simply changed "DGIndexProjectFile14" to "DGIndexProjectFile15" (inside the .d2v HeadBanger77 posted), and the latest 1.4.9 beta 13 dgdecode.dll opened it, with correctly set IVTC etc... my bad ^^
-- --

More coming later, I'll compare your smallest encode with mine (your biggest encode looks very close to the MPEG2 except in very rare places, and it's closer to the MPEG2 than my current x264 version, even if your's is 23MB bigger than the source :p)

[akupenguin]

You also didn't mention your deinterlacing method in your avs script, so I resorted to using FieldDeinterlace(full=true, dthreshold=10)
Black.Pearl.Sample.m2v isn't interlaced, it's soft-telecined.

[DarkZell666]

My current batch file:
SET DEBLOCK=-6
SET DEADZONE=0
SET QP=18

rem SET MATRIXNAME=M4G-HighDetail-V3.1
rem SET MATRIX=--cqmfile "./Matrices/%MATRIXNAME%.cfg"

rem SET MATRIXNAME=M4G HRM V1
rem SET MATRIX=--cqmfile "./Matrices/%MATRIXNAME%.cfg"

SET MATRIXNAME=flat
SET MATRIX=

rem BFRAMEOPTS NOT USED YET
rem SET BFRAMEOPTS=-w -b 3 --b-pyramid --direct spatial --b-rdo

SET PARTITIONS=-8 -A "p8x8,i8x8,b8x8"
SET MISCOPTS=--no-fast-pskip --progress --deadzone-inter %DEADZONE% --deadzone-intra %DEADZONE%
SET OPTIONS=--qp %QP% --mixed-refs --ref 3 --no-deblock --me hex --subme 6 %PARTITIONS% -t 1
x264 %OPTIONS% %MISCOPTS% %MATRIX% --progress -o "BP_QP%QP%_%MATRIXNAME%cqm_deadzone%DEADZONE%-nodeblock.mkv" "pirates.avs"

As you can see: QP18, no bframes, no deblocking, deadzone(inter+intra)=0, flat matrix.
This gave me a 50,5MB file, with rock-ass quality (not 100% transparent yet, but getting there :p).

See for yourself: screenshots here (http://xasonline.info/doom9/BP_QP18_flatcqm_deadzone0-nodeblock.rar) (~3MB)
Note: I voluntarily ruled out the 4x4 partitions.

[*.mp4 guy]

The M2v really isn't a great source, there are a lot of visible artifacts in it, did you put it through dvd rb or something? I don't remember the dvd beeing that bad.

[DarkZell666]

The M2v really isn't a great source, there are a lot of visible artifacts in it, did you put it through dvd rb or something? I don't remember the dvd beeing that bad.

I suppose the question was targeted to HeadBanger77, but in case you're actually asking me the answer is no :)

[DarkZell666]

All x264 settings are as shown in the batch file in my previous post.

Here's what I've tried so far:

x264 QP18 with M4G High-Detail 1.3 => 48.371kB
x264 QP18 with flat CQM => 51.749kB
x264 QP17 with flat CQM => 61.139kB
x264 QP18 with M4G HRM => 64.942kB
Original MPEG2 source for reminder => 67.122kB

Screens:

http://xasonline.info/doom9/pirates_lot1_hat.jpg

http://xasonline.info/doom9/pirates_lot1_face.jpg

http://xasonline.info/doom9/pirates_lot1_background.jpg

Note: the original m2v picture is 1 or 2 frames off each time. I tried adding Trim(2,0) but it jumped the other way round (as if it had trimmed 4 frames instead of 2).

[HeadBangeR77]

The M2v really isn't a great source, there are a lot of visible artifacts in it, did you put it through dvd rb or something? I don't remember the dvd beeing that bad.
I was waiting for someone with sharp sight to mark that. ;)
Yes, it's my back-up copy, that had been simply shrinked to fit one DVD-5 (no menu, no extras, just the main movie and AC3 5.1 soundtrack), fortunatelly just a few days before my young cousin literally broke the original in two pieces (the same happened to "Dead Man" <shed a tear>). * When I compare it to e.g. Two Towers Director's Cut Edition (bare movie on two DVD-9s + 2 x DVD-9 with extras) the quality is s***y. This make a proper encode even more difficult imo, since when I use e.g. Didee's SixOfNine matrice, which is rather flat, it makes the source even more blocky (same for the HVS version). Heini's SixOfNine keeps the details I would like to keep, and is less blocky than the source at the same time. Very gentle use of Deblock_QED helps a lot, but we don't use any filters/scripts for this little comparison.**

As to the d2v - I'm still using 1.4.9. beta-7, since I haven't found any bugs in it so far, for my limited use. And yes, the source was 100% film, so forcing film was enough. I attached my d2v, since I've marked, that forcing film doesn't always give the same results (a few frames may differ), and I wanted all the encodes to be identical in terms of frames.

Brb, cheers

[evilmode=on]
* now someone tell me back-ups aren't needed! :angry:
[evilmode=off]

** framestepping for instance from frm 2700 and further reveals some nasty blocks.

Evilmode and its modifications are under pending patent protection, reserved for DarkZell666 Inc.

PS. I've just made a two pass encode with Fox Home Entertainment - interesting :D
http://rapidshare.com/files/14499240/Black.Pearl.Sample14.avi

PS2. @ DarkZell666
Could you just paste the links /thumbnails - my screen goes crazy :D Also, joined jpegs aren't a great idea while comparing quality: I would recommend single pngs, which are lossles, so that everyone could view them at fullscreen resolution. ;)

I'm examining the screencaps you've taken from the the flat matrice's encode.

[HeadBangeR77]

(...)
As you can see: QP18, no bframes, no deblocking, deadzone(inter+intra)=0, flat matrix.
This gave me a 50,5MB file, with rock-ass quality (not 100% transparent yet, but getting there :p).

See for yourself: screenshots here (http://xasonline.info/doom9/BP_QP18_flatcqm_deadzone0-nodeblock.rar) (~3MB)
Note: I voluntarily ruled out the 4x4 partitions.
Gee, looks more blocky than the source, and the screenshots are so heavily compressed, that I can't tell much about the quality of the encode itslef. :(
Btw. The presentation looks bad, since the colors are washed out (VMR9 with TV-scale?).

I've also made some x264 encodes, using the default flat matrice, but I'm half-noob to AVC, so I didn't want to compare my results with my XviD ones. I played much with b-frames, I & P frames quality settings, with and without 4x4 partitions etc. I didn't trun off the deblocking though, used -2/-2 in the most extreme case, since it's already blocky at these settings. The samples I made are 50-60MB large (with 2 or 3 b-frames), QP 16, and I must admit I had expected worse results. :)

I'm comparig my two-pass XviD encodes atm, aiming at 46MB filesize, but the choice is hard. Gonna upload them today, when I've made my mind, so that they can be compared with those made at constant quantizer, uploaded above. I will attacht a bunch of screenshots as well. Do you think 46MB would be just for x264 as well, considering the source is Xvid-friendly ;), or 36-38MB, considering its more advanced features?

cheers
HDBR77

[check]

To compare in a useful and practical way, both codecs should output the same size files. You should also aim to have a net reduction in filesize, say to 75%?

[HeadBangeR77]

To compare in a useful and practical way, both codecs should output the same size files.
I must agree with you, considering the source has been carefully chosen to cause much trouble to x264; that's why I asked.

You should also aim to have a net reduction in filesize, say to 75%?
You mean 75% of the size I've already chosen, or in comparison to the original. If the latter is true, it's already less than that.

[DarkZell666]

Actually I used this script to generate the screens:

clip1 = directshowsource("BP_QP18_M4G-HighDetail-V3.1cqm_deadzone0-nodeblock.mkv").Subtitle("QP18_m4ghighdetail")
clip2 = directshowsource("BP_QP17_flatcqm_deadzone0-nodeblock.mkv").Subtitle("QP17_flatcqm")
clip3 = directshowsource("BP_QP18_flatcqm_deadzone0-nodeblock.mkv").Subtitle("QP18_flatcqm")
clip4 = directshowsource("BP_QP18_M4G HRM V1cqm_deadzone0-nodeblock.mkv").Subtitle("QP18_m4gHRM")

clip5 = m2v().Subtitle("Orig. M2V")
clip6 = clip5

flat = StackVertical(clip2, clip3)
m4g = StackVertical(clip1, clip4)
m2v = StackHorizontal(clip5, clip6)

video = StackHorizontal(flat,m4g)
video = StackVertical(video, m2v)
video = video.ConvertToRGB32().SelectRangeEvery(15, 2)
video = ImageWriter(video, start = 0, file="D:\_etienne\blackpearltest\grabs\", type = "jpg", info=false)
return video

function m2v() {
LoadPlugin("DGDecode.dll")
m2v = mpeg2source("Black.Pearl.Sample_xas.d2v", idct=7)
m2v = m2v.crop(4,58,712,360).LanczosResize(720,304).ConvertToYV12()
return m2v
}


This was the quickest way I found at lunch time at work (imagine me eating a sandwich and configuring x264 with one hand, you'll understand :p). I'm doing the encodes again, and I'll output png's this time (but they'll have to stay as they are, sorry ^^).

[*.mp4 guy]

...could you just upload the clips somewhere like megaupload (http://www.megaupload.com/), still frames are not the best way to compare video quality.

[HeadBangeR77]

I've just finished encoding and decided, what samples among the 2-pass ones are the best imo. I'm gonna post the download links here, together with a short comment and codec's settings. I will also attach RARed still frames: of course comparing e.g. P 2 with B 4 makes no sense, but the majority has exactly the same quantizer and type of frame.

1) The best sample according to metrics (PSNR, SSIM), one of the best according to my own eyes, yet a bit blocky:

http://rapidshare.com/files/14591117/Black.Pearl.Sample12.avi

Didee's SixOfNine, hybrid first pass at Q2 (MSP=5, VHQ=1, Chroma ME, VHQ for b-frames, Qpel, Turbo, B-frames 2/1.62/0), second pass with curve compression 5/5 (MPS=6, VHQ=4, Chroma ME, VHQ for b-frames, Qpel, B-frames as in the 1st).


2) The best one imho, with almost the worst metrics (:p), less blocky than the source:

http://rapidshare.com/files/14618487/Black.Pearl.Sample11.avi

Heini's SixOfNine, hybrid first pass at Q3 (MSP=5, VHQ=1, Chroma ME, VHQ for b-frames, Qpel, Turbo, B-frames 2/1.62/0), second pass with curve compression 5/5 (MPS=6, VHQ=4, Chroma ME, VHQ for b-frames, Qpel, B-frames as in the 1st).


3) Comparable to No 1, good metrics, yet a bit worse according to my sight, a bit less blocky than 1:

http://rapidshare.com/files/14603587/Black.Pearl.Sample13.avi

Didee's SixOfNine HVS, hybrid first pass at Q2 (MSP=5, VHQ=1, Chroma ME, VHQ for b-frames, Qpel, Turbo, B-frames 2/1.62/0), second pass with curve compression 5/5 (MPS=6, VHQ=4, Chroma ME, VHQ for b-frames, Qpel, B-frames as in the 1st).


4) Still frames taken from the source, the best 1-pass samples linked a few posts above, and the just mentioned 2-pass encodes:

http://xasonline.info/headbanger/DE BEST.rar ;)

cheers,
HDBR77

[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 ?!

[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

[ToS_Maverick]

come on, be nice to each other, we don't want to fight each other, we want to discuss in a polite manner ;)

@HDBR77: still waiting for your comment about my sample :D

[Sagittaire]

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 :

Well it's simply a completely useless profil for you and Tegedeeck then ...


Huh?

You can tweak ASP for change Size/quantisation scaling. With the same quantizer all the ASP don't use the same size. DivX for example use a higher size with the same quantizer.


REALLY? :D

I make the encoding for the "DivX CD test V2"
http://www.divxtest.com/sommaire.php3?lang=en

Scan the result if you want (more than 200 SAP tested)


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.

Well DivX3 is always developped with libavcodec. You can't compare DivX3 from libavcodec and DivX SBC with NanDub.


You've recommended it[/b] along with full command line:

1) I use my matrix for blocking problem with low inloop strenght, not for better Grain Retention.
2) My matrix is really flat matrix.
3) Grain Retention is not a CQM problem for H264. Flat16 is really good for that. Partitions, inloop, Pel Search and other internal tweak are really more important for Grain Retention.

[*.mp4 guy]

1) I use my matrix for blocking problem with low inloop strenght, not for better Grain Retention.
2) My matrix is really flat matrix.
3) Grain Retention is not a CQM problem for H264. Partitions, inloop, Pel Search and other internal tweak are really more important for Grain Retention.

1: -2:-2 is not "low inloop strength", infact when using a given crf -2:-2 usually gives lower filesizes then higher settings...

2: If its flat you would have just used the standard one, afterall its flat too and will always have better metrics then your matrix

3: I used 4x4 partitions without any problems in my encodes, you used rdo 7, the highest pel search in your encode, so thats not a problem, inloop isn't the problem, -2:-2 is just the most efficient setting for it, in spite of psnr it works better for the codec bit for bit then higher settings. You didn't tweak deadzone, or any other "internal" settings, you used trellis instead, so internal tweaking was not necessary for your sample, which indeed had good grain retention, but misteriously did not use the standard matrix despite your pontifications.

All of the encodes that used the standard matrix that I have seen in this thread had horribly poor grain retention, ToS_Mavericks encode looked ok, but it definately didn't keep much grain.

Sagittaire please stop acting as though your opinion is law, It doesn't bother me that you think all matrices are usless crap (though you are somewhat hypocritical in this), what bothers me is that you consistently try to silence people with different views, often with no actual proof that what you are saying is true. You usually end up twisting the facts to try and make your point, why bother just let people make up there own minds from the clearly available information, if you are right then people will naturally come to conclude so, if you lay out the facts clearly..

[foxyshadis]

Well DivX3 is always developped with libavcodec. You can't compare DivX3 from libavcodec and DivX SBC with NanDub.

In that case just call it MPEG-4 SP then, since it's barely related to DivX3 in any other way.

[HeadBangeR77]

@ Sagittaire:
I couldn't express myself better than mp4 guy did at the end of his last post (thank you). I'm not gonna point out all the mess you've made so far (like e.g. with the recommendation to use your matrix, while you denied that, or playing silence-of-the-lambs with many of my questions, or denying the sense of half of XivD's presets), but I will simply ignore your posts in the future. (...) Revealed-truth isn't a proper manner to discuss things these days, imo.

@ ToS_Maverick. Inventive Software:
It's so late I will surely kick the bucket soon. I've got all your samples, and I'm gonna have a closer look at them this week, though I don't know when exactly. I will try to remain objective, if it's possible. I have never tried to suggest that "XviD is better than x264" (sounds childish to me ;)) - all I ever wanted /tried to prove /examine /discuss is the idea it isn't so much worse for certain uses, though it's technologically less advanced, and it might look better to some people at high bitrates. Thanks for cooperation and excuse my harsh words, if spoken (I can't recall at this hour).

cheers,
HDBR77

[Manao]

1: -2:-2 is not "low inloop strength", infact when using a given crf -2:-2 usually gives lower filesizes then higher settings...In what way giving a lower file size at a given crf implies that the strength is low ? The strength of the deblocking can't be judged that way. Just for information, here's how deblocking behave at a fixed quantizer : Quantizer | Force | Size | PSNR
-----------------------------------
18 | 0 | 5011 | 45.927
18 | -6 | 5076 | 45.896
18 | 3 | 4941 | 45.779
18 | 6 | 5021 | 44.814
-----------------------------------
26 | 0 | 1817 | 41.089
26 | -6 | 1869 | 40.793
26 | 3 | 1797 | 41.002
26 | 6 | 1889 | 40.286
-----------------------------------
34 | 0 | 648 | 36.509
34 | -6 | 685 | 36.187
34 | 3 | 645 | 36.369
34 | 6 | 667 | 36.007

[aabxx]

There's a MeGUI profile called "CQ-ASP_Q2_equiv":

--qp 18 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "" ""


I'm wondering, is this setting usually supposed to give a substantially smaller size than xvid @ q2 default settings or is it supposed to give same-ish bitrate?

I ask because with the above settings xvid gives me smaller sizes on my vhs material, which sort of seems strange to me as the generally more efficient encoder's q2 equivilant surely should produce smaller file sizes than xvid Q2 default on most material, right? Well that's what I would've thought anyway.

Leading me to speculate in that MAYBE xvid is more efficient with a large subset of vhs material? This is only SPECULATION untill someone can confirm that indeed, CQ-ASP_Q2_equiv does generally give smaller filesizes than xvid @ q2 default. For all I know, CQ-ASP_Q2_equiv generally gives larger file sizes so of course there is no reason for me to pursue more testing on this untill someone can give me more input.

[check]

they are not intended to be in any way similar apart from the quality of the output file. x264 q18 == xvid q2

[aabxx]

they are not intended to be in any way similar apart from the quality of the output file. x264 q18 == xvid q2


Yes, but if x264 at q18 looking same-ish as xvid q2 produces higher bitrates than the latter, would not that indicate that xvid is more efficient on that particular material?

[westgroveg]

x264 MUCH better quality than XviD?
Yes. Try a 700MB encode of a 2+ hour movie & find out.

[DarkZell666]

Yes. Try a 700MB encode of a 2+ hour movie & find out.

This is exactly the sort of silly answer you would have refrained from posting if you had read the thread completely ... cheers.

[westgroveg]

This is exactly the sort of silly answer you would have refrained from posting if you had read the thread completely ... cheers.
It's not "silly" it's the truth.

[DarkZell666]

Man, did you actually read the thread ? There isn't only encoding 2 hour movies onto 700MB in the "encoding practice", and even if x264 is very good at that, it isn't always that good in other situations (which have been extensively studied in the thread).

We've actually found it was much easier to get something transparent out of XviD than out of x264 (and faster too).

[R3Z]

It's not "silly" it's the truth.

Well at least you didnt say "best" :p

[DarkZell666]

Well at least you didnt say "best" :p
I must say, I did burst out laughing reading this :D

[check]

Yes, but if x264 at q18 looking same-ish as xvid q2 produces higher bitrates than the latter, would not that indicate that xvid is more efficient on that particular material?

No, but it does indicate that using those particular settings, xvid is better.

[aabxx]

Well I've been trying out xvid at q2 mpeg plus a few more settings adjustments to make it more optimal (configuring xvid is not exactly hocus pocus) and x264 at various settings at both crf 18 and qp 18 (this is more hocus pocus at this point).

The material is 768x576 80s homevideos (always shaking :D) on VHS.

The idea was that I was sending my friend a clip and he wanted it in "pristine" quality. However when I told him xvid at Q2 with good settings would turn out 8-9 mbps (which I knew from many past experiences), he was surprised to hear they were so big so he suggested me trying out CQ-ASP_Q2_equiv to save some space. And they typically turned out between 9-11 mbps in my tests to mine and his surprise.

This testing was primarily non-interlaced encoding (the samples were interlaced and not resized/filtered further) but interlaced encoding showed approximately the same ratios but I did not do much of those because x264 interlaced does not playback properly here for some reason neither through ffdshow or VLC.

I'm using the newest stable xvid (1.1.2 or whatever) and x264 core:54 svn-634. I might add too that with most settings I tried x264 is MUCH slower than xvid, even though x264 is running multithreaded while my version of xvid is not. I have not tested x264 on quicker settings as I believe that would make the quality or the file size suffer more.

This was by no means any exhaustive test. I post this because I only encode VHS most of the time, and if my current findings hold any value (I'll have to do more testing), the mantra of "generally x264 is superior to xvid" does not mean much to me if it turns out that x264 is not better on 95% of the material.

I would be very interested if someone else has compared xvid to x264 with non-pristine VHS. Especially if they found some settings where x264 is better than xvid.

Next I will try some comparisons on DV-material. DV-material is usually much easier to compress than my VHS-material so I suppose maybe x264 will win there. We'll see.

[*.mp4 guy]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original, then try using a cqm in x264 that compresses high frequencies more aggressively (this may or may not help, and is highly source dependant), If you can't get X264 to outperform Xvid (make sure to try Xvid on the downsized encode aswell) you have probably found a source that X264 is bad at, comparatively speaking.

[aabxx]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original, then try using a cqm in x264 that compresses high frequencies more aggressively (this may or may not help, and is highly source dependant),

It looks slightly better when it's not resized. I know I pay a high premium in file size to keep it at a high resolution but buying big hard drives has almost become a hobby of mine and I have almost a dozen of them by now :)

If you can't get X264 to outperform Xvid (make sure to try Xvid on the downsized encode aswell) you have probably found a source that X264 is bad at, comparatively speaking.

Yes, but this is a big thing in my book when we're comparing x264 versus xvid, as the test samples I use I believe are representative for most of my family videos from the 80s. It would not be unreasonable to suggest that the situation will be the same with tons of family videos from the 80 and at least early 90s. Comparisons here on doom9 tend overwhelmingly to be on film material and sometime tv show caps. I suspect there has been little testing done publically here on old family videos. Unfortunately I'm not a good tester but I'm just coming with some suggestions that might interest someone.

I reckon that when the bitrates are "insanely" high, as they always are with most of my vhs material, the advanced techniques of x264 does not help and therefore xvid becomes equal or perhaps even better.

Having said all that, I'm no x264 expert so I don't find myself suitable to come to any real conclusions. I merely suggest new venues for comparison because my results at least indicate to me, that when it comes to old vidoes, x264 might not be superior.

Oh btw, I've done some testing on my DV material (which is only DV-material originating from MY camera) and x264 seems more efficient than xvid there. But DV from my camera is MUCH more compressible than my old VHS tapes.

[squid808]

No, the HCT vs DCT isn't a big problem. It really doesn't matter which exact set of approximations you use as long as the encoder and decoder agree. If the encoder and decoder use different approximations, then the low quality is due to the difference between them, not due to the difference from the ideal DCT.

By quantization, I mean given a quantized coefficient and the step size, how do you compute the dequantized coefficient. h264 uses level*qscale. ASP (both h263 and mpeg) uses level*qscale+qadd, with different values of qadd. (qadd is 0 for mpeg intra, but non-0 for h263 intra and both inter).


Xvid ME uses SAD (and then may refine with RD, depending on the setting of vhq).

Has adaptive updating of the quantization offset as described in the paper at http://adsabs.harvard.edu/abs/2005SPIE.5960.1041S been tested in x264? Seems like a candidate for grain retention at very high bitrates.

[akupenguin]

Adaptive deadzone is a half-assed version of trellis. Mine is optimal, theirs is just pretty close.

[weaver4]

I have not read every post in this thread so I will probably be "blasted". Has anyone seen this site that compares MOS scores for X264, DivX, and XviD. Any comments?

http://www.compression.ru/video/codec_comparison/subjective_codecs_comparison_en.html

Something looks "fishy" between the results of XviD and DivX.

What I tell my friends is that "XviD/DivX is just as good as X264 when you set the bitrate/filesize 20% higher". Based on these MOS scores it appears that my statement is mostly accurate.

[steve77]

Since I'm the orginal poster, I guess I should slip in another word. First, thanks to all of you who took the time to do the necessary tests and analyse (mostly objectively :p ) your findings.

I myself am mostly interested in lower bitrate encodes (1500kbps max, resolutions up to 768x432 for low motion, low noise encodes)... Though I haven't done extensive testing as you fine folks have done, to my eyes I find x264 is best with high motion scenes (w/ relatively high compression): often in the past I've used XviD and found some motion to become somewhat blocky for highish quantizer values.

Then again, I go all out with my x264 encodes: 5 reference frames, RDO level 2, Exaustive ME... yes I know many people discourage RDO level 2, and the "exaustive" Motion Estimation settings. I manage 8-10fps on my encodes with all the bells and whistles.

Question: Is it wise to use the "all" marcroblocks option? (Comaptibility set asside?) I always do.

Anyway, I think that both codecs are the very best of their kind, but can't help but think that h.264 is the "next big thing" in video distribution.

[bananacreamandpeca]

Basically how it pans out is that If you are encoding in a situation where artefacts will be unavoidable X264 is better becuase its artefacts are less annoying, and overall there are less of them. In any other situation (archiving, transparent format shifting, refiltering etc.) X264 is inferior to Xvid becuase it is much harder to get transparent results with X264 then Xvid, on some sources it is completely impossible to get transparent results with X264 unless you use lossless or neer lossless bitrates.

Im still getting x264-video with lots of macroblocks in places where you see lots of smoke or dust.
Like in scenes where there are explosions or debree falling from ceilings and stuff.

Personaly I think x264 gets its higher cmpression advantage due to lots of pre-filtering (?)
And I'm still hovering over what to use in wich situation.
Xvid gives good results, even when transcoding. I always use autogk for that myself.
Dunno why, autogk just gives good results when transcoding.
x264 is painfully slow and has lots of weird options, unless you can cluster computers to do a faster job.
(anybody clustering pc's for video edting?)
MKV is, well, pretty weird. I suggest you do encodes, than copy them mkv's to clean harddrive space
before play. Or else you might notice very long seeking and starting lag.

[imcold]

MKV is, well, pretty weird. I suggest you do encodes, than copy them mkv's to clean harddrive space
before play. Or else you might notice very long seeking and starting lag.

Remux the file.

[ToS_Maverick]

i got a hint from this thread (http://forum.doom9.org/showthread.php?t=125010) where a Dr.Khron had problems with his simpsons episodes. his screenshots, where he compared different AQ settings, made me try AQ on the black pearl sample... i have to say, i'm really suprised, it looks great! i'll post some screens in the next days, i wanted to post the settings, if anyone is interested in trying them out ;)


--crf 20.0 --deadzone-inter 9 --deadzone-intra 6 --ref 3 --no-fast-pskip --bframes 2 --weightb --filter -2,-2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2

[Dr.Khron]

Try playing with the "sensitivty" option, too. I found that 1.2 + caused artifacts, and so far I've been happiest with 0.6 & 10 (although bear in mind I'm encoding animated content, so 10 might be way too low).

[ToS_Maverick]

i found some time to test a bit, and got these settings for you guys. to give you a heads-up: i managed to get an even better quality than the last time i posted this (http://forum.doom9.org/showthread.php?p=956242#post956242), but with increased file-sizes!
screens will come if i have some time again ;)

@Dr.Khron: thx for the tip, sensitivity 10 works fine, but i had to crank up the strength to 1.2 to give satisfactory results for this file :D

"transparent" line, 52 MB:

--crf 22.0 --deadzone-inter 9 --deadzone-intra 6 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2 --aq-sensitivity 10


balanced line, good compression, good quality, quite slower, 32.2 MB:

--crf 20.0 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2 --aq-sensitivity 10

with crf 18, this line will give you better quality @ 42.9 MB

[akupenguin]

"transparent" line, 52 MB:
wtf? multiple reference frames and bime with subme=1?

[ToS_Maverick]

hell jeah :D

ok subme=1 is a bit extreme, i know, but at higher settings, subme is eating up all the grain, at least for this sample.

the first line was an attempt to get real good quality, and to keep most of the grain.
the second line is more suited for the common encoding ;)

[ToS_Maverick]

ok, as promised here are some screens :D

the sample was coded in 720x304. i resized the images, to give you a closer look.

from left to right:
Original, CRF20 with AQ, CRF20 with AQ and subme=1, CRF18 without AQ

http://img251.imageshack.us/img251/7133/101origsmallis5.th.png (http://img251.imageshack.us/my.php?image=101origsmallis5.png) http://img251.imageshack.us/img251/7895/101aqsmallgo1.th.png (http://img251.imageshack.us/my.php?image=101aqsmallgo1.png) http://img251.imageshack.us/img251/4163/101aqsub1smalley7.th.png (http://img251.imageshack.us/my.php?image=101aqsub1smalley7.png) http://img251.imageshack.us/img251/185/101noaqsmallyi4.th.png (http://img251.imageshack.us/my.php?image=101noaqsmallyi4.png)

http://img108.imageshack.us/img108/5862/300origsmallsw6.th.png (http://img108.imageshack.us/my.php?image=300origsmallsw6.png) http://img122.imageshack.us/img122/1142/300aqsmallzg8.th.png (http://img122.imageshack.us/my.php?image=300aqsmallzg8.png) http://img122.imageshack.us/img122/664/300aqsub1smallda5.th.png (http://img122.imageshack.us/my.php?image=300aqsub1smallda5.png) http://img108.imageshack.us/img108/4540/300noaqsmalllq0.th.png (http://img108.imageshack.us/my.php?image=300noaqsmalllq0.png)

http://img78.imageshack.us/img78/8987/815origsmallwe1.th.png (http://img78.imageshack.us/my.php?image=815origsmallwe1.png) http://img163.imageshack.us/img163/7523/815aqsmalljr0.th.png (http://img163.imageshack.us/my.php?image=815aqsmalljr0.png) http://img163.imageshack.us/img163/6979/815aqsub1smallei6.th.png (http://img163.imageshack.us/my.php?image=815aqsub1smallei6.png) http://img163.imageshack.us/img163/9257/815noaqsmallcs7.th.png (http://img163.imageshack.us/my.php?image=815noaqsmallcs7.png)

for the record, here again my commandlines:

CRF 20, AQ
--crf 20.0 --aq-strength 1.2 --aq-sensitivity 10 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

CRF 20, AQ, subme=1
--crf 20.0 --aq-strength 1.2 --aq-sensitivity 10 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 1 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

CRF 18, no AQ
--crf 18.0 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

[*.mp4 guy]

After looking at those samples, it looks like I will have to give AQ a second look, But I don't think subme 1 is helping with grain retention. I also think, that until X264 goes through some major changes, this topic had been examined about as completly as it can be.

[Sagittaire]

After looking at those samples, it looks like I will have to give AQ a second look, But I don't think subme 1 is helping with grain retention. I also think, that until X264 goes through some major changes, this topic had been examined about as completly as it can be.

Why major change ... ???
There are special functionality in H264 standard for Grain Retention at low bitrate: Film Grain Modeling.

[ToS_Maverick]

@*.mp4 guy
what things do think have to be changed?

i think including the aq-patch, and choosing a "sane" default value for it would be cool. or some other thing, to get rid of these ugly blocks, in the 2nd series of my screens.

[*.mp4 guy]

Why major change ... ???
There are special functionality in H264 standard for Grain Retention at low bitrate: Film Grain Modeling.
I would consider the addition of FGM in X264 a major change.

@*.mp4 guy
what things do think have to be changed?
I wasn't trying to say that things have to be changed.

[winkgood]

I know this is slightly offtopic since the thread originally compared XVid to x264 but here's my story.

I've been playing around with different encodings for Van Helsing HD-DVD. My original encoding was in virtual dub using DivX 6.6?(I think) codec (using the pro codec) with single pass coding on 'better' quality in 720p using 7500 bitrate for the video.

My second encoding was using MeGui with x264 codec with two passes in 720p and 8000 bitrate. Here's the log file for my x264 encoding:

*****

Looking for job processor for job...
Processor found!
Starting job job1-1 at 10:52:04 PM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 1 --bitrate 8000 --stats "V:\Van Helsing\VideoSync.stats" --level 4.1 --keyint 15 --min-keyint 1 --bframes 2 --b-pyramid --direct auto --filter -3,-2 --subme 1 --analyse none --vbv-bufsize 9781 --vbv-maxrate 29400 --me dia --threads 2 --thread-input --progress --no-psnr --no-ssim --output NUL "V:\Van Helsing\VideoSync.avs"
successfully started encoding
Processing ended at 2:32:42 AM
----------------------------------------------------------------------------------------------------------

Log for job job1-1

avis [info]: 1280x720 @ 23.98 fps (189337 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:16105 Avg QP:14.67 size: 98792
x264 [info]: slice P:99163 Avg QP:16.87 size: 47343
x264 [info]: slice B:74069 Avg QP:18.18 size: 20990
x264 [info]: mb I I16..4: 29.9% 0.0% 70.1%
x264 [info]: mb P I16..4: 31.0% 0.0% 0.0% P16..4: 56.5% 0.0% 0.0% 0.0% 0.0% skip:12.4%
x264 [info]: mb B I16..4: 4.0% 0.0% 0.0% B16..8: 31.7% 0.0% 0.0% direct:30.3% skip:34.0%
x264 [info]: final ratefactor: 17.19
x264 [info]: direct mvs spatial:94.6% temporal:5.4%
x264 [info]: kb/s:7942.7

encoded 189337 frames, 14.31 fps, 7943.33 kb/s

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

Starting postprocessing of job...
Job completed successfully and deletion of intermediate files is activated
Postprocessing finished!
Looking for job processor for job...
Processor found!
Starting job job1-2 at 2:32:42 AM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 2 --bitrate 8000 --stats "V:\Van Helsing\VideoSync.stats" --level 4.1 --keyint 15 --min-keyint 1 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 9781 --vbv-maxrate 29400 --me umh --threads 2 --thread-input --progress --no-psnr --no-ssim --output "V:\Van Helsing\VideoSync.mkv" "V:\Van Helsing\VideoSync.avs"
successfully started encoding

Log for job job1-2

avis [info]: 1280x720 @ 23.98 fps (189337 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:16105 Avg QP:14.81 size: 91949
x264 [info]: slice P:99163 Avg QP:16.13 size: 48936
x264 [info]: slice B:74069 Avg QP:17.37 size: 21105
x264 [info]: mb I I16..4: 20.8% 58.3% 20.9%
x264 [info]: mb P I16..4: 8.8% 25.6% 5.4% P16..4: 26.1% 16.2% 6.6% 0.0% 0.0% skip:11.3%
x264 [info]: mb B I16..4: 1.4% 3.3% 0.8% B16..8: 35.0% 2.8% 6.6% direct: 8.4% skip:41.8%
x264 [info]: 8x8 transform intra:62.3% inter:60.1%
x264 [info]: direct mvs spatial:82.5% temporal:17.5%
x264 [info]: ref P 71.9% 19.5% 8.6%
x264 [info]: ref B 78.8% 17.0% 4.2%
x264 [info]: kb/s:7999.8

encoded 189337 frames, 4.06 fps, 8000.39 kb/s
desired video bitrate of this job: 8000 kbit/s - obtained video bitrate (approximate): 8002 kbit/s





*****

With both of them I used AC3 Audio. However, the x264 took probably 14 hours to encode while the DivX one took only about 3-4 hours. I think the second pass was going at around 4 fps.

The point I'm getting at though is that I showed both video clips to a group of my friends to get their opinion on quality. None of them could really notice much of a difference although some said that one looked better and some said that the other did. This was done on a 37" 720p TV. So am I doing something incredible wrong in my x264 encoding or is there really just not much of a difference in the two at this high bitrate? If there isn't a significant difference, then I'd be better off going with divX as it would save me a lot of encoding time.

[Manao]

So am I doing something incredible wrong in my x264 encodingNo, but you're comparing two codecs at a bitrate at which you can't tell them apart, because the quality is "too good" for your eyes.
If there isn't a significant difference, then I'd be better off going with divX as it would save me a lot of encoding time.Not necessarily. You should be able to target 6000 or even 5000 kbit/sec with x264 and still have the same visual quality as DivX.

[foxyshadis]

Average q16 indicates that it's probably well above the threshold of transparency. (Which is normally q18-22 for most people.) The divx is probably q3 or 4 average, also generally transparent to the less-demanding (with the mpeg matrix). You might have to do side-by-side comparisons to find obvious differences, obviously very difficult from a DVD player, or freeze-frame at major action scenes.

You should look at constant quality mode (at 18 or so) for x264 to save time, probably almost a quarter of the encode time, and make it a bit smaller.

Overall you probably have reached the point where perceptually, either codec does roughly equally. (Especially if you denoised at all, which reduces bitrate requirements significantly.) If you don't care how large they are, and can't tell the difference in normal viewing, it'd probably be better to use divx and save the extra time. The only thing x264 could give you is smaller files.

[Sagittaire]

1) 8000 Kbps for 1280*544 resolution movie is a high quality compression. A this bitrate MPEG2 will make high quality, certainely "transparent" for your eyes and certainely with better speed than x264 or XviD.

2) DivX q3 - q4 encoding make generaly something like 3000-4000 Kbps for 720p with medium complexity source. In your case DivX use certainely something like average q2 or less.

3) Use 8 Mbps 1080p is a very better way for your encoding.

4) Your profil is a HDDVD profil encoding. This profil use 0.606 sec GOP. With this short GOP you must change the ratio quantizer between I and P (something like --ipratio 1.10). If you don't want use HDDVD profil (mean multiplexing in HDDVD project) you must use higher GOP lenght, the efficiency will be really better with large GOP.

[infoeater]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original (...)

This is not true, VHS have full vertically resolution of PAL B/G/D/K/I (576 lines) or NTSC, and is losing details only horizontally. More about it: http://forum.doom9.org/showthread.php?p=188998#post188998 (and in whole topic).

[*.mp4 guy]

480->384 corresponds to a kel factor of 0.8, which is extremely optimisitic for a vhs sampling system. Also, this thread is quite old, why did you raise it from the dead?

[infoeater]

Yes, you would keep at 480x384 most of horizontal details, but would lose some vertical, because vertical resolution of NTSC VHS is "digital" 480 lines, unless some blurring has been add.

I resurrected this thread, because I had to do so, to write in it something new. Large part of my knowledge about video encoding from years come from reading threads, even very old, from doom9.org forum. I thing many other people too, so it's important to maintain quality of this important source of information.

Also if I am wrong and/or understand something incorrectly from this topic, or topic to which I linked to, I can have hope, then somebody will explain it to my, and other people with similar mind to my, which may read this thread in future.

Finally lots of forums nowadays have in they rules not to resurrect dead threads, or to do it only in very important cases. This doesn’t, so I thought, that somebody intentionally didn't write such term, maybe thinking same as me.

[*.mp4 guy]

I have captured quite a few vhs tapes, and I can assure you none of them have usefull information above 384 lines. It is because of a combination of factors, two of the major culprits are interlacing and associated filtering, and the kel factor of the sensors used (more relevant for older vhs, before dvd was released). Newer Svhs releases (most modern vhs are actually svhs, which is backwards compatible with vhs) may have resolution above 384 vertical pixels, but only if they were created from a high quality dvd master.

long story short, just because a standard, such as vhs has 480 discrete pixels of vertical resolution, does not mean that they will actually contain information. Due to poor quality mastering, interlacing, and luma-chroma cross talk (dot crawl) it is extremely dificult to get even half of the theoretical vertical resolution on a vhs to yeild any usefull information.

Interlacing and and inadequate tbc alone can leave you with between 120 and 240 vertical resolution. Add in poor mastering (many dvd's struggle to reach 384 vertical resolution, and being a digital format they could easily have 440+, if mastered correctly) and 384 is pretty much impossible. Then, dotcrawl compounds the problem, in order to completely eliminate dotcrawl, more then 2/3rds of the frequency resolution, horizontal and vertical must be lowpassed; most modern systems, use a digital notch, or comb filter instead of a lowpass filter which can recover most of the resolution, while eliminating most of the dotcrawl, but there are still significant losses.

So theoretically, with a perfect master, perfect ivtc/deinterlacing, and perfect luma chroma separation, you could get 480 vertical pixels of resolution out of a vhs. However, perfect masters are nonexistent, even on dvd's, and still very rare on blu-ray, perfect ivtc/deinterlacing is an np-hard problem with no known solution, as is luma/chroma separation. Even if all of these step are done with very high (but not perfect) quality, 384 pixels of vertical resolution is an extemely unlikely benchmark to reach.

[weaver4]

I might as well throw in my results here.

I did 12 movies with DivX(6.8) Q=4, Width of 640. I found the quality of these moves to be very-good to me. I went back and tried to duplicate the "very-good" rating "for me" with x264 and found that a crf=21 or crf=22 was appropriate using StaxRip. I don't really know what all x264 parameters that Stax uses, but I assume he knows what he is doing. I found that the x264 filesizes were on average 24% smaller.

So my conclusion is: For "good-quality" movies the filesizes are approx 24% smaller with x264....but DivX movies are much more portable across hardware devices.

[Wilbert]

Originally Posted by *.mp4 guy View Post
VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original (...)
infoeater is right. The kell factor has nothing to do with the amount of vertical detail. It's about the perceived vertical resolution (and not with respect to pixels, but with respect to the analog signal):

"how much of the detail in an analogue signal can you actually discern with the human eye when played back on a TV screen (Which includes Kell).
This only comes into play when you are watching it afterwards, and depends on the player and TV/screen/beamer/??? used."
source: http://forum.doom9.org/showthread.php?p=415817#post415817

long story short, just because a standard, such as vhs has 480 discrete pixels of vertical resolution, does not mean that they will actually contain information. Due to poor quality mastering, interlacing, and luma-chroma cross talk (dot crawl) it is extremely dificult to get even half of the theoretical vertical resolution on a vhs to yeild any usefull information.

Luma-chroma cross talk has nothing to do with the vertical resolution, but has an impact on the horizontal resolution. Also, interlacing isn't "destroyed" by recording a pal/ntsc signal on your vcr, so it has no impact on the vertical resolution either.

Xesdeeni gave a nice explanation here: http://forum.doom9.org/showthread.php?p=184675#post184675

[*.mp4 guy]

interlacing will cause aliasing "jitter" if the image isn't vertically lowpassed, thats one way it negatively impacts resolution(most interlaced signals are vertically lowpassed at some point). The second way, is that, for films, at some point you have to undo the 3:2 pattern, with vhs this is much harder because of line jitter, and some fairly horrible results may be had (second way interlacing impacts resolution).

The kell factor is affected by the relationship between the scanning device (camera) and display device (television). If you are using a camera with only 720*480 pixels, you will only get aproximately 504*336 useful pixels for a tube camera, and 648*432 for a ccd. I assume most vhs were captured with fairly poor equipment, and so this becomes a factor.

Luma-chroma cross talk, alright, I made a mistake here, it can be removed by lowpassing either the horizontal or vertical axes to a bit less then 1/3rd the original frequency resolution. High quality comb filters usually use a combination of vertical, horizontal and temporal combinations, to cancel out the phase differences of neighboring pixels, this does affect vertical resolution.

You will note that I didn't say vhs has a resolution of 352*240, because it doesn't. 512*384, on the other hand, is more then adequate.

I have to admit, that it is theoretically possible for a vhs to have 480 vertical pixels of resolution, and that there isn't any reason it can't happen, it just doesn't.

[Wilbert]

interlacing will cause aliasing "jitter" if the image isn't vertically lowpassed, thats one way it negatively impacts resolution(most interlaced signals are vertically lowpassed at some point).
Do you think that a vcr does that?

The kell factor is affected by the relationship between the scanning device (camera) and display device (television). If you are using a camera with only 720*480 pixels, you will only get aproximately 504*336 useful pixels for a tube camera, and 648*432 for a ccd. I assume most vhs were captured with fairly poor equipment, and so this becomes a factor.
Ok, but this is not a problem of your vcr. If you cap from tv show you won't have that problem. In the thread that i linked, i4004 made a test dvd with alternating black and white lines. Recording it to your vcr and capping with a capture guide, retains that alternating black and white line image.

[*.mp4 guy]

1-Do you think that a vcr does that?


2-Ok, but this is not a problem of your vcr. If you cap from tv show you won't have that problem. In the thread that i linked, i4004 made a test dvd with alternating black and white lines. Recording it to your vcr and capping with a capture guide, retains that alternating black and white line image.

1. no, it is a problem with the master sources, a very prevalent problem, even amound dvds. Keep in mind my points are from the perspective of capturing studio releases and family films from vhs, and both sources are going to have sub-par vertical resolution, for reasons I have already outlined.

2 That was a thought experiment. It also handily avoids the comb filter issue. Give me a real world example where you can manage that with alternating green and magenta hued bars, in the same orientation as the luminance lines, at the maximum color frequency resolution, overlaid with alternating lines of 64 and 191 intensity (so the hue is visible), and I will acknowledge the point.

[Wilbert]

1. no, it is a problem with the master sources, a very prevalent problem, even amound dvds. Keep in mind my points are from the perspective of capturing studio releases and family films from vhs, and both sources are going to have sub-par vertical resolution, for reasons I have already outlined.
A few posts back you were talking about the vertical resolution that a vhs could retain. Of course if the source is crap, the output will be crap too.

2 That was a thought experiment. It also handily avoids the comb filter issue. Give me a real world example where you can manage that with alternating green and magenta hued bars, in the same orientation as the luminance lines, at the maximum color frequency resolution, overlaid with alternating lines of 64 and 191 intensity (so the hue is visible), and I will acknowledge the point.
That's an interesting experiment! I don't have my pc connected to my tv/vcr anymore, so unfortunately i can't do it myself. I will ask i4004 to do this.

[Inventive Software]

Why was this thread gravedigged? It's been dead a year and a half...