How does DivX5 handle end-credits?

[JimmyBarnes]

Under DivX3.11a those scrolling end credits can really blow-out your filesize. With no ECBR reduction, credits can occupy 70 MB instead of a fifth that size (I like my ECs to be clearly legible).

I'm still very new to DivX5 but so far the filesize has been within
1 % with no apparent end-credit bitrate reduction or control that I'm aware of (following Doom9's DivX ripping guide).

Just wondering if the new codec has some inherent way of limiting the size of the frames produced from scrolling text.

thanx
JB

[N_F]

If you encode the credits using constant quality instead of the other bitrate controlls. I personally use ~28 as quantisizers. A five minutes clip should be around 5 MB (I think) with these settings, no sound included.

[JimmyBarnes]

Originally posted by N_F
If you encode the credits using constant quality instead of the other bitrate controlls. I personally use ~28 as quantisizers. A five minutes clip should be around 5 MB (I think) with these settings, no sound included.

Oops, I should have mentioned: I meant including end-credits processing along with the main movie rip, not processing end credits as a separate task, then appending them to the rest of the movie.

JB

[N_F]

As far as I know the codec itself can't to this for you. But it should be possible if you edit the logfile between the first pass and the second pass (assuming that you do a 2-pass-encoding). I guess you could do it manually (if you have a lot of time and want to get bored ;)). Otherwise I think Divx4log can to it for you.

Or did I misunderstand you again?

[JimmyBarnes]

Originally posted by N_F
As far as I know the codec itself can't to this for you. But it should be possible if you edit the logfile between the first pass and the second pass (assuming that you do a 2-pass-encoding). I guess you could do it manually (if you have a lot of time and want to get bored ;)). Otherwise I think Divx4log can to it for you.

Or did I misunderstand you again?

Yes and no.

What puzzles me is that though I didn't do anything in particular to rein in end-credits size in the final AVI, the overall AVI filesize came out almost exactly right (2-pass rip). Maybe that was just lucky??

JB

[khp]

OK let me take a stab at this....

As I understand it, jimmy is asking, how good divx5 is at compressing the endcredits, compared to divx3.11, in general without any special modifications (the entire movie converted as one job).

AFAIK the answer to this is: not much has changed (but I have not tested this). Q-pel and GMC might be able to improve the situation for divx5, but again I have not tested this.

edit: OK I have setup a few tests to figure this out, should be done in 2 hours.

What puzzles me is that though I didn't do anything in particular to rein in end-credits size in the final AVI, the overall AVI filesize came out almost exactly right (2-pass rip). Maybe that was just lucky??

Why is this strange ? filesize prediction works very well in 2-pass mode in divx5, if one part of the movie is more complex than the rest, the codec will simply use more bits for that part and less for the other parts.

[N_F]

Originally posted by khp
Why is this strange ? filesize prediction works very well in 2-pass mode in divx5, if one part of the movie is more complex than the rest, the codec will simply use more bits for that part and less for the other parts.

As I understand it he didn't include the length of the credits when he calculated what bitrate he should use. When he then encoded the movie with credits he was surprised that it wasn't a little oversized since he added the credits to the encoding. That's why he's wondering if DivX5 automatically compresses the credits at a very low bitrate (of course the codec can't tell when the credits start, but it can detect the changes in the picture).

I may be wrong...

[khp]

OK I did some testing ...

Method: I have encoded 7 minutes of endcredits, using quality based encoding at 100% in divx4 and divx5, for the divx3.11 test I used the lowmotion codec with a bitrate setting of 6000.

Results:
divx3.11.....121.264KB
divx4.........134.324KB
divx5.........135.858KB
divx5Q.......125.080KB
divx5QG.....123.100KB
divx5QGB.... 83.602KB

As expected this test clearly shows that encoding the subs is still well worth the effort.

I'am kinda dissapointed that Q-pel and GMC doesn't give us much improvement.

As for the last result, using B-frames, you should keep in mind that the B-frames are encoded with dubbled quantizers.