Disclaimer:

I do 1 CD Rips, so this is relatively low bitrate. For 2 CD Rips things may be different. Only 1 movie tested, so limited representativeness, although I've done this twice before and the results were similar. I did the video quality test blind and had my girlfriend do it independently too.

Video quality:

The basic problem of XviD vs DivX seems to be noise and blockyness. Both the XviD 'stable' and 'latest' encodes had problems with noisy backgrounds and blocks during the tougher scenes. With XviD 'stable' this was sometimes very bad to the point of annoying, but with the 'latest' version things were a lot better. In some scenes, XviD appeared to preserve details a little better, but often so at the cost of noise and occasionally blocks. DivX smoothens out things more, which causes sometimes details to suffer a little, but visually this appears to be much preferable to the unstable blocks & noise of XviD. So in video quality for 1 CD Rips, DivX 5 wins out for me, although XviD 'latest' is not far behind. XviD 'stable' plays a league lower than these two.

Edit: Pictures removed since people don't seem to bother to read explanations anyway.

Speed:

XviD 'stable' and DivX 5 were similar, XviD 'latest' is 1/2 the speed with all options enabled

Usability:

DivX 5 has a polished commercial quality package, which is easily configurable and gives good defaults. I could not find any bugs. Both XviD's are much rougher, the defaults do not give good quality, and there seems constant controversy over what are good settings. I noticed some bugs with the 'latest' version, for example with the decoder getting stuck on the first playback (this is understandable as it's alpha software, but it's still a valid issue here).

Price:

DivX 5 Pro is available both commercially for a fee and in a free version with ads. XviD is free and open sourced.

Putting it all together, aka the result:

DivX 5 wins, XviD 'latest' is close, XviD 'stable' is far behind

Thanks for the evaluation. Can you post more details about your encoder configurations? I'm curious about what settings you used. For what it's worth, I really appreciate Divx's simple configuration and good default settings; it lets me rip more movies in less time. Still, if Xvid can be tweaked to provide better results, that would be worth noting.

XviD 'stable' was:

uManiac 27.11.2002

Motion search prec: 6
Quantizer: H263
Linear curve compression settings (from doom9.net forum)
No hinted ME
Quantizer 2-6, 2-16

XviD 'latest' was:

XviD-26012003-1 Koepi

Motion search prec: 6
Quantizer: MPEG first pass, New Modulated HQ second pass
Lumi masking, Chroma ME, GMC, Quaterpixel
B Frames: 3/150/100
DX50 VOP compatibility
Linear curve compression settings
No hinted ME
Quantizer 2-6, 2-16

I actually used settings from a document in the Doom9 XviD forum. I wanted to link to that document, but I downloaded the latest version and all recommendations are changed all over again, LOL.

Which quantizers did you use with xvid? MPEG or H.263? In most cases H.263 is better for 1 CD, although it gives less sharp picture.

AFAIK there's another difference between these codecs: xvid is 100% mpeg4 compliant, divx5 is not.

Wow, you're really fast, answered before I even asked

Modulated should figure out the correct one automatically I assume, in any case it's what all guides recommend. Why can't XviD figure out correct quantizer for itself anyway?? Switch to H263 is there are few bits per pixel per plane or something...DivX5 doesn't require this kind of configuration and works fine.

I used H263 for the 'stable' encode, but it had the same problems, so it seems that quantizer doesn't matter all that much.



I doubt this. XviD developers warn that XviD latest build can generate bitstreams that are incompatible with future versions. That makes no sense if it's really MPEG4 compliant. Moreover, compatibility doesn't interest me - playback happens on the computer anyway, and there seem to be devices out that play DivX nevertheless. But I admit that given the choice, standards compliance is certainly a bonus.

All I can say is, that from my experience the difference between H.263 (smoother) and MPEG ("sharper"), in the Xvid version I tested, was huge. Mpeg was terrible for lower bitrates, while h.263 was closer to your Divx screenshot.

I'd like to nitpick a little about the test.

1) If you intend to use New Modulated HQ quantiser for second pass (H263 for q<=3, MPEG for q>=4), the first pass (where everything is encoded in q=2) should have been encoded using H263 quantiser instead of MPEG. Anyway for a 2.5 hr encode on 1 cd, H263 should be used for both pass. I don't see the point in dissing XviD for providing a choice of quantiser settings while DivX only provides a constant quantiser. In fact XviD allows you to customize quantiser matrices, as is part of the MPEG4 standard. You can't be saying "choice is bad. users being forced to only one choice is good.", can you? It sounds microsoftish...

2) If you intend to compare encoding time, then you should enable the same advanced features in XviD and DivX. Currently you have enabled only Bframes in DivX and Bframes+GMC+Qpel in XviD. Naturally XviD would be slower.

3) One result cannot be representative of which codec is better. To illustrate that, there are many tests which can be found in the Doom9 forum which gives varying results for different clips, sometimes one codec is better sometimes one codec is inferior. Very often within the same clip, you get frames which are better in one and frames elsewhere which are worse.

4) Divx Pro is not free, and using the normal version of Divx 5 means you can't use the advanced profile features of GMC, Bframes and Qpel.

I recently did my own short test. For this test, I enabled GMC, Qpel and Bframes for both XviD and DivX. Constant quantiser of 2 for I/P frames and 4 for B frames. The clip is from the Lord of the Rings: Fellowship of the Rings extended edition, the chapter where Gandalf and Saruman are discussing the rising of Mordor in the tower of Isengard and ending in Saruman kicking Gandalf's ass in a wizard catfight.

Let me remind all that this result is also not representative of what happens all the time. I also use an objective PSNR measurement which may not be accurate and may not always agree with subjective opinions. From my own subjective, I see very little difference between the two clips and cannot pick one over the other. But there are some interesting objective results.

XviD: output filesize 23,706kb
Total frames processed: 5009

Minimum Average Maximum
Mean Absolute Deviation: 2.6088 3.2778 3.7446
Mean Deviation: -0.7626 -0.2289 +0.4060
PSNR: 24.7667 25.5778 28.9123

DivX: output filesize 27,462kb
Total frames processed: 5009

Minimum Average Maximum
Mean Absolute Deviation: 2.6061 3.4833 4.4347
Mean Deviation: -1.1968 -0.2162 +0.7798
PSNR: 24.7404 25.5365 28.9258


You can draw your own conclusions and your preferece, but I will list the reasons why I would choose XviD over DivX.

1) XviD is open sourced. OSS fanboy? Maybe, but that's a reason for me.

2) DivX did a despicable and evil thing before. Remember the time when they started Project Mayo to create OpenDivx where they invited opensource developers to work on OpenDivx. Just as OpenDivx was about to be ready for released, they closed down Project Mayo and released their own Divx 4 which they have been secretly hiding. The Open Source community has never been so royally backstabbed before, and out of OpenDivx's ashes came XviD.

3) Some may call it newbie-unfriendly, but XviD is way more customizable than DivX, allowing lots of things to be customized. Such as quantiser matrices, bitrate curves, bframe quantisers, etc.

4) Many nice and useful features such as start/end credits encoding.

5) I'm often in contact with the developers in irc.freenode.net #xvid, and I learn a lot about video encoding technologies from them.

6) XviD is rapidly developing and improving, and more people to help test and report bugs would be really nice.

The guides are saying exactly the opposite!



Giving a choice is not good when there is no way to get a good default automatically! The user should be able to use the software even if he's not an expert. I'm not stupid, but apparently it's still impossible for me to set up the codec completely right. Is it so hard to understand that setting good defaults is essential?

And it seems that even people with much more knowledge about XviD do not understand how to set up the codec correctly, see the modulated quant issue, which even reinforces my point.

I like choices, but I don't like them stuffed down my throat!



My main criterium was quality with the best recommended settings. My conclusion was that even with all options on XviD is worse than DivX, AND is significantly slower then. Maybe if I turn them off, it can get even in speed, but then it'll lose out even more badly on quality, which makes it even worse for me...



...which is exactly what I said in my post.



Which is why I did a comparison over several scenes, and made a conclusion based on that.



There is an ads supported version which is free, and supports all advanced options.

Last time i tried, some options in Xvid were doing more harm than good, i don't think things are so simple

Garf> Could you make a link to the guides saying you've got to put MPEG quantiser for New Modulated HQ ?? I didn't found it anywhere... and since this new Modulated HQ interest me... i'd like to dl a complete guide... I've been wandering around on doom9 forum but I found only iago's guide and there's no indication on this (I just says to select either MPEG or H263 in 1rst pass...).
(what to use in 1rst pass ??? I just know you had to use H263 in old modulated mode but i didn't find anything about what to choose with new Modulated HQ mode)...


And what filter did you use to render the encoded files ??? Is it the same filter configuration for both of encoded files ??

I also used iago's guide. The version I used had 'With Koepies builds, if you chose MPEG as the first pass quantization type, now you can consider choosing New modulated HQ type..."

I downloaded the latest, and it no longer has any recommendation on what to use in the first pass, and some recommended settings are different (though they're small changes).



XviD for XviD and DivX for DivX, both using their respective maximum postprocessing

Could you try to post screenshots with the same filter ?? (ffdshow by example)

And could you try with last recommandations and unstable build ??

It's would be good to see if it change something....

And it would be good to test some samples with H263 and MPEG in 1rst pass to see if this changes anything...

Or one could say in video processing a picture is worthless. In that particular frame Divx5 looks smoother/better. But with video there is not so much concern about individual frames as there is to the over all experience. For me Xvid easily equals or is better than Divx 5 for everything I do.



How untrue. DXN purchased "Sparky's" encore2 code he submitted to the opendivx CVS for use in Divx 4. There was a bit of fenagling as to whether or not it would be left in CVS and allowed to be used in opendivx. In the end it was. If anyone backstabbed anyone it was Sparky. He represented the encore2 code as his own work in it's entirety. If it was not then he was the culprit. Also opendivx did not cease before or at the time Divx 4 was released. There was a time they co-existed. I have talked with those on the inside in the know and back in early 2001 DXN was shutting down it's facilities left and right and laying people off. They were having financial problems. Go fig. And as part of the consolidation opendivx was EOLed. I was very upset at the time as I did not have full details on the situation and DXN has not to date come out and said they have ever had any problem with money. But DXN, Project Mayo, and opendivx begat Xvid. That is right. Xvid started out as pure opendivx code with DXN and Project Mayo's blessing.

For me I still preffer the development versions of Xvid over Divx. But I preffer Koepi's builds over U-maniacs personally. U-maniac's builds are just vanilla CVS checkouts for the most part. Koepi starts with the same base but from time to time he will add in code and patches to his build before they are submitted and hit CVS by their respective authors. The recent Dev builds were having oversized problems with B frames. Koepi's build was the first and I think still the only to be patched so size predictability is back.

Did you notice that I wrote:



I included them because they illustrate the difference with the codecs, which is also very apparent when watching the moving video itself.

I was not so much replying to you Garf as I was to Tangent. But yes I read your post. BTW give koepi's last dev build a try see if it does better for you. U-maniacs are fine. But Koepi's often have that extra something.

well, the point is that xvid would really need a good default settings and a bit more of automation, anyway i think the test is flawed by using the postprocessing (it is like using 2 different audio players with different eq settings), imho you would also need to compare the files without any postprocessing, and the H263 mode is recommended for 1cd rip afaik (at least is was when i last checked the doom9's guide).

edit:
from http://www.doom9.org/xvid-vdub-dev.htm

I used Koepis latest for 'latest'. The 'stable' build from him is (quite a bit!) older than uManiacs stable build, so I used uManiacs for that.

IMHO this is nonsense. What matters is what quality you get when playing back the file and postprocessing is a part of that. If DivX has better postprocessing than XviD, then DivX is the better solution. Or if DivX's raw output's flaws can be corrected with postprocessing whereas XviD's can't, then DivX is also better.

I'll give you another analogy: not using postprocessing is like judging an audio codec from looking at how nice the MDCT coefficients it outputs look.



Aha, *this* is interesting, because it's opposite of what the other guide claimed. If an XviD developer can tell me what is right and if it's the above (i.e. my settings were wrong), I'd give XviD another try.

man that is an ass-ugly shot of xvid! hard to believe xvid stable could look worse.

In my experience, xvid proponents always lay the claim that xvid is far 'sharper'. Well to me it almost always looks blocky. I would much rather have a slightly blurred picture with no blocks, than an encode thats very sharp with no motion but goes crazy with blocks now and then. Reason: you'll have to look side by side with the original dvd to determine blurrieness, but you don't need any reference to determine bad blocky artifacts.

First, i don't agree with Iago's guide...
Second, here's what i would do: First, i'd use Koepi's latest 27.01.2003, wouldn't use lumi-masking, it often gives much worse results when it's enabled. I wouldn't use GMC either.
I'd use max 2 B-Frames. My B-Frame quantizer ratio would be 140 or below. I wouldn't use DX5 B-VOP compatibility. I'd use only H.263 and not any modulated quant type.
Just my suggestions.

sure, but the point is that the decoder is just another unknown factor, (btw you can change the xvid file so it will use the divx decoder) and decoding at level 6 is not really recommended for neither codec afaik, also that is very subjective and could also very much depend on the tv/monitor/resizing abilities of your card/dontknowwhatelse that you are using, personaly i dont use any postprocessing for most movies, only for really low-bitrate ones (1 cd rip), again depending on the movie, i would choose level1 at divx decoder + really small amount of the film grain thingy. (maybe it would be wise to use the ffdshow as 'independent' playback filter for the comparision)

I actually tried this because the XviD decoder bug I mentioned above, but it doesn't work. The video gets screwed up after a while.

I don't think it would be fair to say that XviD is better than DivX if XviD needed DivX's playback routines in any case!



As is written on the first few lines of my report, the goal was to get an idea about low bitrate performance. I would imagine that especially for higher bitrates the issue of smoothing vs noise & blocks is totally in reverse. But high bitrates are uninteresting - I'll leave it up to someone else to do that test.

imho divx is better, i was just trying to point out the possible improvements of the ab routine/procedure (was it blind test btw, rotfl? )

oh, with low bitrates i meant 'a really long movie on 1 cd, probably with average bitrate around 450-600 kbps...'.
they are quite interesting really, especially this year as it seems that divx hardware might appear, 'good stuff' will happen much lower than with mpeg2.

Garf, you must have misread Iago's guide. I'm looking at Iago's guide right now. Updated 25012003. Page 4.

Note that before the middle of last year, only a Modulated HQ was available and it was reversed: H263 for >= and MPEG for <= 3. The New Modulated HQ reverses that.

Artemis:

Things changes very fast in the development and it can be quite hard to keep up with what is the best options to use for each revision, as sometimes things are broken, things are improved etc. There was a time when luma masking was broken, but now RefDivX's code works great. There was a time when Bframes has a crash bug with high quantisers, but that was fixed. There was a time where qpel smearing was occuring, and that was fixed to. There was a time where GMC totally sucked, but Gruel implemented 2-vector GMC and now it's great.

Actually when it comes to hardware players etc you will not be able to rely on the Divx decoder or even the Xvid decoder. Not to say they should be ignored. But when it comes to the hardware players a better raw stream will generally give you a better processed stream. So there is something to say for not using post processing when comparring.

Also Garf I did not see you mention the RC averaging periods you used. I assume you set Xvid to 10,000 frames and divx to half or higher. It makes a big difference.

Is it proper to evaluate codecs by static frames rather than their datastreams in motion?

Static frames are nice and can provide some usefull info. But just as with the comman addage here that you can guage very little of a lossy audio codecs performance by looking at frequency/wave graphs the same can be said for a single frame of a lossy compressed video. If we were comparing GIF, JPEG, and PNG then single frames would indeed be the acid test. But much as glitches can show on an audio graph that you can not hear glitches can show on single frames which you can not see. That is unless you step frame by frame. And who watches movies like that?

In this instance Garf says he can see the displayed effect even while watching the movie. I will take his word on that. But there are some settings to which he may or may not have used which I am curious to find out as they can make quite a difference. In my experience Xvid-dev binaries and Divx 5 Pro perform nearly exactly the same most times with Xvid edging Divx 5 Pro out every now and again. Most of my decoding is done with FFDshow though. I rarely use the actual Divx or even Xvid decoder.

No, I quoted DIRECTLY from the version I have. As I already said, I also downloaded the latest and it doesn't have any recommendation what to use.

But mine literally says that you must use MPEG in the 1st pass if you want 'New Modulated HQ' in the second...

I don't see the point of doing another XviD run unless an actual developer can tell me what works and what doesn't and what are good settings, because even in this thread people can't agree what the correct settings are.

Ok, this is a good point. Maybe I should qualify that I'm only testing PC playback (actually, the goal of this test was to determine for me how I should do this encode for my GF. I don't want to have to explain her how to set up 10 codecs and 20 decoder filters, so it's either pure XviD or pure Divx) or include a non-postprocessed comparison.





Neither XviD 'latest' nor DivX 5.0.3 has this option.

I could make sense to use ffdshow for decoding. Only one decoding filter for everything, with the same configuration. To my mind it's more simple.

About XVid interface, I think that it's similar to Lame command-line interface. Nice for developpers because you can set up every option that you want to test. But not very user-friendly as an end-user is able to screw encoding because of options used in a bad way.

For end users, there's still up-to-date very good guides on doom9... If you follow them strictly, there's no way to screw up things... And if you're good enough, you'll try to use your own settings ;-) (and even your own quantisation matrix...)


But I agree comparison tests should be made with the same postprocessing filter (ffdshow do it very well)...

Indeed, what's important to test is encoding and not rendering...
rendering test should be made in a new test, with the same encoder to really test them...

Mixing two distinct tests in a single one isn't the serious way to do it...

Plus, some people doesn't use the same decoder (ffdshow, ffmpeg,...) and not on the same hardware (PS2, PC, DVD/Divx Player).

I used a guide, and people are still saying the settings were bad. There's people who think the guides are no good, the guides don't agree with each other, it's a total mess.

Someone make an APS for XviD, PLEASE!



Exactly the opposite, what matters is how the video actually looks on the screen.

IMHO using a different decoder than the codec's is testing two different softwares at once. But maybe it is nice to see how much difference they make by using a common decoder for both.

There can't be an APS for XviD (or any video codec) for a few reasons reasons.

1. Different people have different preferences as to how many CDs they want to use, quality vs resolution tradeoffs etc.
2. XviD is in very rapid changing developement. "Best settings" change quickly from revision to revision of the stable alpha.
3. Every movie is different (noisy? anime? action-packed?) and can require different treatment which is going to be a very hard process to automate.

I have to agree, if you test XviD vs. DivX you should test only encoder or encoder/decoder separated. I always use ffdshow to decode all kinds of MPEG-4 (including M$-MPEG4 and WMV1), because it has the best post-processing at all.
If you test lame, do you also test how good the decoder is? No, you test only the encoder, because lame is normaly used to encode, not to decode, like XviD.
Of course it is important what you see on screen, but MPEG-4 is a standard like MP3, so you can play DivX-videos with XviD and XviD with DivX, or even use an completly different decoder, like ffdshow or a hardware player.
Post-Processing is like dithering in audio-decoders, you shouldn´t test with it.

Then why does DivX 5 have excellent defaults?

I didn't have to configure (almost) anything and the video looks great.

Did you try with lots of different video (anime, fast movie, slow rythm movie) and with diffrent size (1CD - 2CD)...

I think having more options, even if it takes time to set them, gives everyone the opportunity to set the codec exactly how he wants and for the video he wants to encode...


I don't think rendering test is that important... because it's possible the post processing will evolve in each codec but the encoded video won't move... So you'll have better results with same encoding... so your precedent tests about codecs were all wrong...

It's possible to compare this with audio...
Video codec can be compared to audio compression and video post processing is like DSPs...
Do you think it's good to test different audio compressions with differents DSPs selected ??

Someone make an APS for XviD, PLEASE!

MPEG-4 video is just a tad more complex than MP3 audio..

There is work being performed on some global rate-distortion optimization tools that will use heuristics to better determine when features should be enabled or not. Things will get better.

-h

Please read the original posts, I do not like to explain everything 50000 times for people that are too lazy to read.



Yes, of course this only reflects the situation at this current point in time. If DivX releases a new version tomorrow or XviD gets a large update, the situation will OBVIOUSLY change.



If there would be DSP's that improved audio quality to get it more transparant yes.

Here's another analogy since you seem to like them: It's like comparing MP3Pro and MP3 by playing them through a non-MP3Pro capable player!

I gave XviD another run this afternoon, using the latest iago guide I found, H263 in both passes, only using B frames and Chroma ME. Encoding speed is about 3/4 of DivX5.

I used DivX's playback filter (It didn't work with the previous XviD encode but it does with this one, I guess because there's no qpel/gmc).

This seems to solved most (but unfortunately not all) of the noise issues. There's still some occasional twinkling. The codecs would be very close now, if it weren't for the occasional harder scene; on those XviD seems to detoriate much faster and gets quite a bit of blocks. DivX5 also gets blocks but not nearly as much. Other than this, there is not much difference left I can see.

So, it seems DivX5 still wins, but the differences between the two are small.

I tried ffdshow, but there's obvious distortion in the XviD decode with the stable ffdshow version, I'll try the latest alpha on next reboot.

Edit: Ok, with ffdshow postprocessing both codecs look (quite a bit) worse than with DivX postprocessing. Without postprocessing the same. I don't feel there is any significant difference between the two codecs in this mode.

afaik 11/12/2002 alpha is the most stable for me

@Garf you are partly correct. The RC averaging period setting has been removed from 5.03. It is still there but I believe it has been automated and integrated as part of the Nth pass mode and 2-pass mode. And there is good and bad to that. But all recent Xvid builds even koepi's old stable one has the RC averaging period. It is known by a different name under Xvid though. On the config dialog it would be Two Pass->Curve Compression->Bitrate Playback Delay (frames):. The max value is 10000. It will make a marked differnece on longer clips when set to 10000 instead of the default of 1000. If I am not mistaken it should clobber most of the noise and ringing you are getting under Xvid. For 1-pass CBR it is Debug->CBR options->Averaging Period. Again the max is 10000. If you are gonna be encoding clips of 10000 frames and over then leave it set to 10000 for both. It makes a "BIG" difference. Also Garf if you have credits in your movie(and why wouldn't you?) try the mode to encode credits with a lower bitrate. You can get a similar effect with Divx but it involves cutting the movie into clips, encoding all clips, and joining all clips. And for all those clips you will have to figure out propper bitrates and file sizes. With Xvid it is as simple as credits start here. End there. And reduce the bitrate by 20%. Under a 2-pass encode vertical scrolling credits uncontrolled will chew up a tone of bitrate you will probably rather use elsewhere. Unless you are a credits freak and then it is not for you.

I already handle credits for both codecs by simply cutting them out. Then they use exactly 0 bits with either codec

K. I tend to leave me credits in. It just seems incomplete otherwise. But be sure to try setting the bitrate playback delay to 10000.

Erm... So, focus on transparency and not file size? Do you care if the movie takes 5 CDs on hard samples?

I don't think that a video APS would be appropriate here, except in certain circumstances. I think you're looking more for an --alt-preset 700MB or something.

The other thing is that video and audio are very different media. Audio is always time limited. If you slow something audial down, you shift the perception of the audio. With video, when you slow it down, you just slow it down without necessarily doing the same things to the perception, and thus, artifacts are more easily seen.

That said, someone needs to make an ABX tool for video codecs, heh. That'd be cool.

I don't think Garf was seriously suggesting that XviD could be "transparent"; the concept is meaningless with video. After all, what is the reference for transparency? "Looks like the DVD"? That's not possible, since DVD is already so degraded in comparison to real-life images that it's easy to see the slightest difference if one looks closely at the encoded video (and I'm talking about full-speed playback, not freeze-frame analysis with a magnifying glass). Compare that to CD audio and transparent audio encoding, which are (for me) indistinguishable from any audio source played through speakers.

XviD really could use an "--alt-preset 700MB", like you said, but XviD is still in alpha status, under heavy development with things constantly changing, so no collection of settings could stay optimal for any length of time. Still, it would be nice to have some decent default settings that the developers could update with each semi-stable release. But part-time programmers often aren't interested in that aspect of application development when the project is at such an early stage, and I can't really blame them.


Mmm, side-by-side video comparison. I tried doing that with two video players, but my video card overlay will only draw to one player at a time.

This may be correct for the early DVD releases circa 1997-8 but most current releases exhibit excellent visual quality. If there are visual problems in current releases, the culprit is most often shoddy transfers not compression artifacts. I think the DVD format can support film-like transparency, just as red book CD can provide aural transparency. When these formats fail their missions, there's probably some person in the chain to blame rather than the format specifications (though the ancient AC-3 spec IS a liability).

film like? (maybe 'uncompressed digital video' like transparency), anyway a really good picture is possible when one is taking uncompressed source and feed that into divx, mpeg2 is just not a very nice source (transcoding ).

<offtopic> iam still looking for a 'perfect' (pal) deinterlacer, video must run smootly even on not the latest/greatest cpus so bob is not an option (or any 50fps stuff).
tested few of them (smart deinterlacer 4 vdub, fielddeinterlace for avisynth and greedyhma 4 avisynth), so far greedyhma is a winner, any suggestions? (i cant seem to find a good explanation or maybe even a home page for greedyhma - of what is actualy happening)</offtopic>

It's those jerks who use single-layer DVD's for 3-hour movies (examples I've run into recently: The Patriot, Gandhi) who make DVD's that look like DivX straight out of the box. The Patriot in particular had horrible macroblocks, while Gandhi just had bad edge noise.


What I meant by "DVD is already so degraded in comparison to real-life images" was that looking at a TV screen playing a DVD is nothing like looking through a window at the actors. I guess the audio-equivalent would be a CD, playing on good speakers in another room, sounding indistinguishable from a live band in the other room. I've been fooled by a CD on more than one occasion, but I've never actually believed that Russel Crowe was talking to me through the TV set! Seriously, though, human faces lose a lot of detail when they get put on a DVD.

But even compared to film, I don't think DVD has the necesary resolution to provide film-like transparency. And even though not many playback devices can generate blindingly-bright light like the movie theaters can, I'm not sure the DVD format itself has the dynamic range necessary for that kind of extreme contrast.

I just made a 5-pass Divx503 encode of "The Red Violin", with Garf's GT3b1 -q5 for the audio (turned out 144kbps) and it looks really good for a 1cd rip (GMC & B-frames, no qpel, "constant quality" biasing). I'm making an XviD comparison-encode, and I just want to make sure my settings are okay. I'm using the 02-02-2003 unstable build from Koepi's site, along with the Doom9 guide. My settings: luma masking, chroma motion estimation, GMC, qpel, B-frames (max 2 in a row), no curve compression, 10000-frame biased bit payback delay (this will probably cause Xvid to miss its target filesize?), no restriction on quantizers, H.263 motion estimation first-pass, New Modulated second-pass.

The movie is almost all low-motion, so I'm encoding it at 608x336 with sharp bicubic resize filter, although that gives it 0.148bits/pixel*frame. So far only the first-pass is being done, and it's going quite slow; about 0.4x realtime on my dual XP1600+, compared to 0.9x realtime for Divx503. It would be going faster, but I have to use Decomb's IVTC to fix the mastering engineer's screwy captioning job. But speed isn't the issue here, quality is. So are my settings not optimal for Xvid?