divx4log with divx5.01

[Vran]

I am trying now to encode my first movie with divx5.01+divx4log (which worked great with divx4)
In the guides it is said that you must do the first pass at 6000 bps for divx4log to work, which was the max for divx4.
Now divx5 supports up to 10000, so should I still use 6000 or should I put it to 10000 ?

[Acaila]

You don't have to wonder about what bitrate to input at all. All you have to do is set both MinQ and MaxQ to 2. That way you'll have a constant quantizer mode and the bitrate become irrelevant (setting bitrate to 1 or 10000 will now give you the sme result).

You didn't even have to use 6000 for DivX4...

[Vran]

Thank you very much.. now that you point it out it is abvious, but since ut wasn't explained in any guide, I didn't realise it would not have mattered :D

[N_F]

Will there be a new guide (or is there already one?) that explains the new futures in Divx4log that supports DivX5? For instance, exactly how do those B-frames work in DivX4log and what settings are good there?

[DmitryR]

Originally posted by N_F
Will there be a new guide (or is there already one?) that explains the new futures in Divx4log that supports DivX5? For instance, exactly how do those B-frames work in DivX4log and what settings are good there?

B-frames are treated like P-frames, but separately. As you can mention, Divx4log 0.46 has full set of controls for B-frames like for P-frames.

[InfoCynic]

I had been using Divx4log with Divx 5.00 and generally liked it. Had a few bugs, most noticeable was that the last Zone defined would not be updated with new quantizers if you autosplit. I know some people use the last zone for end credits, but I just encode them seperately using 1-pass quality-based anyway.

Now with Divx 5.01, my files are coming out way too big when I use the exact same methods as I used before. I've done probably 20-30 movies/clips with divx4log and Divx 5, so it's not like I'm doing anything wrong... is it possible that Divx 5.01 changed something that makes the patches you apply to the log file function incorrectly? One movie that I was aiming for 1 CD with came out to 1.2 GB without the audio or the credits appended! Another 2 CD movie that I intended to use the 5.1 audio track on came out 1.19 GB. I reopened the original log files with divx4log and did 2nd passes again, no change. I have a 3rd movie working right now, and while VirtualDub isn't known for accurate file size estimation while an operation is in progress, it does estimate that the output file will be about 1.04 GB, when it should be closer to 585 MB.

After this one finishes, I'll use the original, unmodified log files and run 2nd passes again. We'll see how things turn out. In the meantime, can anyone say if they're using divx4log OK with divx 5.01?

[DmitryR]

Originally posted by InfoCynic
I had been using Divx4log with Divx 5.00 and generally liked it.

Now with Divx 5.01, my files are coming out way too big

Please inform what exact settings did you use while encoding with 5.0 or 5.01. Did you use bidirectional encoding?

[InfoCynic]

1st pass performed at 6000, quants 2/2, keyframe every 240, with GMC and Bidirectional.

2nd pass performed at gknot bitrate with divx4log log file, all other settings the same.

[DmitryR]

I found out (using the VirtualDub Hex editor) that in bidirectional mode all B-frames are 8 bytes long. And if the bidirectional is switched off, the codec duplicates the key frame and drops the frame before the key. So I think DivX 5 is not usable still.

[InfoCynic]

I don't know much about how your program works behind the scenes... is this something you can easily work around for a .47 version in a couple days, or is this going to require a major rewrite (and if that's the case, will you even do it?). It was quite a nice little program :)

[DmitryR]

Seems that you do not understand me. These bugs in DivX5 were found while NOT USING divx4log. So I will wait these bugs fixed in the codec and then will test the divx4log with it.