DivX 5.1 - Home Theatre Profile - N-Pass worse than 1 Pass

[acanthis]

I've just done a short test of DivX 5.1 and encountered a problem that I've never seen before when using previous versions of the codec.

I have a short 4 minute clip which I'm passing thorugh VirtualDub to deinterlace, crop, resize then encode. The source is a PAL DV Type 2 AVI, and I'm going from 720x576 to 640x480.

When I encode using Home Theatre Profile at 780kbps, with Psychovisual enhancements switched off, and choose 1 Pass I get a reasonable encode; Nothing brilliant and certainly no better than 5.0.5 - but acceptable.

If I encode the exact same clip, but this time perform two passes (using the settings to save and read the mvinfo.bin file) I get similar quality for the first ten seconds of the clip then at the first scene change I see a dreadful falloff in quality - as if the bitrate has dropped through the floor. Watching it reminds me of ultra-low bitrate RealMedia! The quality gradually recovers but for a file that is almost the same size as the 1 pass version I'm astounded that it looks so awful! In fact, unwatchable.

Has anyone else seen this, or might be able to point me to what's changed in the new codec that has caused this behaviour.

Sigh ... every single time a new version of DivX comes out .... :(

[DigitAl56K]

I take it that you are de-interlacing that video *before* you resize it...

[acanthis]

Yes, but I'm not sure that even if I'd made that common mistake it would cause this behaviour. It looks to me as though the rate control has gone wrong on the second pass.

Anyway, I'm currently trying a four pass encode and will compare passes 3 and 4 to see what the results are.

[acanthis]

I've just finished the 4 pass test and the problem disappears in the third and fourth passes; while the same part of the second pass looks like a washed out oil painting.

This bothers me quite a lot because the effect was so pronounced. OK, it's corrected in a later pass, but it raises two points:

1) Is 2-pass out and 3-pass now the minimum that can be used?

2) Why is this behaviour so widely different from 5.0.5?

Point 2 has been my gripe about DivX all long; it's an excellent codec but every new version seems to introduce a whole pile of changes that break everything that went before and I'm getting really tired of having to "re-learn" my encoding techniques every time the next decimal point release comes out.

I really don't want to revert to 5.0.5 but otoh I don't relish the prospect of being forced to do a third pass, especially when 5.1 seems to be so much slower than the previous version.

btw I'm a registered user running the Pro version.

[temporance]

@acanthis:
I hate to state the obvious things, but are you sure that you used the correct logfile and mv file (the ones that were generated by the first pass)? And did you let the first pass run all the way through?

I only say this because everytime something weird like this has happened to me with DivX, it's nearly always been my fault. Either I used the wrong logfile, or set too small max bitrate, or something.

If you can replicate the problem, then I'm sure the guys at DXN will be interested in finding out what's going wrong.

[acanthis]

I know what you're saying, but it's definitely the same log and MV files used for all four passes. My gut feeling is that the codec is making an error when allocating bits on that second pass and only when the third pass is run does it pick up that error and put it right.

For the moment I'll go back to 5.0.5 - because I know that version works and I'm not left feeling that I have to sit down and examine every single frame of every encode that I do for errors and anomalies, like I'm feeling with 5.1 right now!

No doubt 5.1.5 will come along soon enough.

Thanks for your help anyway.

[DigitAl56K]

Please note that it appears under 5.1 the option to "Update log file" is off by default for nth pass. Unless you enable this option, there is no benefit in running more than 2 passes.

[acanthis]

Why is it turned off? Surely the correct setting would be for it to be enabled as the title of the setting is "nth pass" and not "2nd pass" clearly indicating that the intention was to use multiple passes.

I will check this again; I'm fairly sure that I checked it, but if I didn't then that just compounds the problem because it seems to imply that I didn't do a third pass at all, but a new "first" pass. And it does nothing to address the fact that my two pass encode produces a video with a quality that looks like its been streamed at 500 baud across a length of wet string between two empty bean cans! ;)

[DigitAl56K]

You're right, it should be on by default - I was merely pointing it out :)

I'm not sure why your encoding went wrong, its quite plausable that there might be bugs present in 5.1, although so far nothing serious has turned up (nothing widespread at least). I'll be keeping my eyes open over the next few days :)

[acanthis]

Just checked. I have "Update Log" checked for subsequent passes.

I've just repeated the two pass encode at 850kbps vs 780kbps. The effect is still clearly visible (i.e. a sudden drop of quality at the first scene change) but the quality recovers much more quickly. To reiterate, the effect is like a sudden massive reduction in allocated bitrate. I then ran a third pass, reading the same log and MV file, and the problem is corrected; clear, crisp image across the whole duration of the clip.

If I had my whole life to waste beta testing production releases of commercial software I suppose I could go in with EKG and see what's happened, but I'm not going to, because it's boring and that's not why I paid for DivX!

Just to finish this thread:

How can it be that a two pass encode at the same bitrate produces a lower quality result than a single pass encode. Surely the whole purpose of the second (and subsequent) passes is to *improve* the quality by better allocating the available encoding bandwidth?

I'm not interested in all these percentile comparisons and compression ratios and fitting all seven seasons of Star Trek: The Next Generation ripped from DVD onto a single 8cm CD-R ;) what matters to me is how does the video look.

So far, I remain to be convinced ... but at least the flying saucers look nice :)

[DigitAl56K]

Its possible there may be a bug somewhere, can you post your CLI?

[acanthis]

1st Pass = -bvn1 850 -psy 0 -key 300 -log "c:\divx.log" -w -mv "c:\mvinfo.bin" -b -sc 50 -pq 5 -profile 3 -nf

nth Pass = -bvnn 850 -psy 0 -key 300 -log "c:\divx.log" -w -mv "c:\mvinfo.bin" -b -pq 5 -vbv 6951200,3145728,2359296 -profile 3 -nf

[LordIntruder]

Do you erase the divx.log file before each new test? I think it is automatically overwritten but I remember once in the past I got some problems. So rather than suppose that divx codec overwrite the log file, I do it myself like that i'm sure it is gone! ;)

What I HIGHLY recommend to everybody is to name the log file exactly the same as your avi.

If you make 4 tests at 805K bitrate you will have:

805a.avi and log file named 805a.log
805b.avi and log file named 805b.log
805c.avi and log file named 805b.log
805d.avi and log file named 805d.log

Of course if you use MV file from one pass to the next, it's same: 805a.bin, 805b.bin, etc...


Like that you will never screw anything, you won't go into trouble.

I don't think it is the cause of your problems but it's a good taking.

[acanthis]

Nope. I've tried that as well :) but thanks for the suggestion. As for the naming of log and MV files, that's a very sensible approach.

No doubt if I were prepared to shell out $50 for Doctor DivX ($20 of which pays for a codec that I've already licensed!!!!) all of these wondrous functions would be handled with breathtaking ease :)

[DigitAl56K]

They will be when Dr DivX 1.0.3 is released :)