x264 MUCH better quality than XviD? [Archive]

steve77

26th January 2007, 02:59

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

26th January 2007, 03:05

steve77

26th January 2007, 14:28

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

26th January 2007, 14:54

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

26th January 2007, 19:22

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

DarkZell666

26th January 2007, 22:56

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

26th January 2007, 23:43

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

26th January 2007, 23:58

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

27th January 2007, 06:55

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

27th January 2007, 09:21

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

27th January 2007, 15:53

Sagittaire

27th January 2007, 19:34

@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

27th January 2007, 20:36

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

27th January 2007, 23:31

@ 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

28th January 2007, 00:29

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

28th January 2007, 01:09

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

28th January 2007, 04:49

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

28th January 2007, 10:10

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

28th January 2007, 10:23

akupenguin

28th January 2007, 10:37

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

28th January 2007, 11:19

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

28th January 2007, 11:34

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

28th January 2007, 11:46

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

28th January 2007, 13:24

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

28th January 2007, 14:02

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

28th January 2007, 14:28

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

Manao

28th January 2007, 21:16

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

28th January 2007, 22:44

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

29th January 2007, 00:03

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

29th January 2007, 00:25

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

29th January 2007, 01:28

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

29th January 2007, 02:26

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

29th January 2007, 03:06

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

29th January 2007, 03:14

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

29th January 2007, 03:24

HeadBangeR77

29th January 2007, 04:04

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

29th January 2007, 06:53

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

29th January 2007, 07:22

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

29th January 2007, 08:49

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

29th January 2007, 10:40

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

29th January 2007, 11:57

check

29th January 2007, 12:33

Sagittaire

29th January 2007, 12:47

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

29th January 2007, 13:27

: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

29th January 2007, 13:35

: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

29th January 2007, 13:42

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

29th January 2007, 13:52

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

29th January 2007, 13:55

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

29th January 2007, 14:58

HeadBangeR77

29th January 2007, 15:20

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.