bug report: problem with constant quant 26 & 27

[canadian_fbi]

this is something of an odd bug that i remember seeing once a few months ago back when i first started using xvid... i was testing encoding some of the end credits of toy story 2 to see how much they could be compressed, and i found a bug that only seemed to appear when using a constant quantizer of 26 and 27 (it appeared for both h.263 and mpeg types). virtualdub was showing a keyframe as being inserted every 6 frames (the minimum), and frame sizes were much higher than normal too. the quality was not any better however. i've encoded 25 frames that show the problem in huffyuv and i could reproduce the error with them; hopefully someone else will be able to too.

with this short of a clip it's hard to see in vdub the higher frame sizes and frequent keyframe insertion, but the filesizes are pretty obvious:

quant 28: 22 kb
quant 27: 72 kb
quant 26: 72 kb
quant 25: 24 kb

i've uploaded the clip to my website here:
http://www.disconnect.net/temp/ts2bug.avi

oh, and this was using nic's version, may 2.

[Teegedeck]

Hi canadian_fbi,

OK, I've reported it to the authorities. Nothing more I can do about it, I'm afraid. :( And thanks for your report. We always need loyal citizens like you. ;)

[gruel]

It's not a real bug, it's a missing feature.

There is a part in XviD that decides for every macroblock if it should be INTER or INTRA coded. That decision is optimized to work well for quantizers up to 15. For quantizers larger than 20 it sometimes chooses INTRA too often, which leads to too many keyframes and therefore too large filesizes.

However, this does not happen for "normal" quantizers and no sensible person encodes anything at quant 20 or larger.
The algorithm could of course be changed, but then results are slightly worse for "normal" quantizers and also things get slower, so I decided to leave it as is it.

[Acaila]

Gruel wrote:
However, this does not happen for "normal" quantizers and no sensible person encodes anything at quant 20 or larger.

Does this also affect the seperate credits compression? Most people use a very high quantizer for that (I use 31). Or does this only apply to 2-pass encoding?

[Teegedeck]

gruel advised us not use quants > 15 on xivd.org, but he hadn't got credits in mind when he stated that. Just try to find out yourself which quants you can use safely, it should depend on the bitrate. The main thing is filesize-predictability, so I'd recommend encoding credits at the same fixed quantizers in 1st and 2nd pass. If the credits don't get too big, this bug is not very interesting, I think...:p

[gruel]

Originally posted by Teegedeck
gruel advised us not use quants > 15 on xivd.org, but he hadn't got credits in mind when he stated that. Just try to find out yourself which quants you can use safely, it should depend on the bitrate. The main thing is filesize-predictability, so I'd recommend encoding credits at the same fixed quantizers in 1st and 2nd pass. If the credits don't get too big, this bug is not very interesting, I think...:p

No, I didn't consider credits, because a) I don't encode them, b) encoding them with high quantizer is not a feature of the codec itself.

Anyway, "normal" credits consists mainly of black with white text. It should not be a problem there if the codec chooses too many I-frames there. However, if anyone really finds a problem with credits getting too big at high quantizers (bigger than with lower) please post again and we might come up with a solution.

[canadian_fbi]

well, the sample i had was 50 kb larger for one second at those quantizers. if your average credits run about five minutes long, that's about 15 mb extra space that those five minutes of credits are taking up. which is not insignificant. still though, i wouldn't trade a decrease for overall speed to fix this problem, seeing as i could work around it just by not using those two fixed quantizer values.

although one thing that wouldn't affect the overall encoding speed would be to have the current algorithm remain the same for the movie, and have one that wasn't optimized for quant <= 15 to be used for the credits-only part, or any constant quant > 15 encoding. i don't know how long this would take to implement however, so i couldn't say if it would be worth the effort, or even possible.