[XviD-devel] Adaptive quantisation

[Michael Militzer]

Hi,

> Well, this problem of "annoying degrading quality after iframe" should
> be solved with the new "scene based" curve compression which foxer was
> so kind to implement. Now the quality should be stable if no consecutive
> keyframes occur (which is a generally hard to handle thing, I think the
> treatment we inserted there helps it a lot, at least it does when I head
> for 1CD with "action" movies).

well, I did a 1pass fixed quant encode when I noticed this problem, so curve
compression won't help and unfortunately it looks like a core problem. I
remember that doom9 mentioned that all codecs (DivX, SBC, XviD) had this
problem, so maybe it's a common MPEG(4) problem, but it's really pretty
annoying. Some days ago some guy told us that accumulative idct errors could
lead to decreasing quality and "jumping keyframes" under some extreme
conditions. We didn't quite believe that such a situation could occur in
reality but you'll never know. I'll at least try to figure out what causes
this problem, then we'll see if something can be done against it or not...

> Michael, could you please test the first scenes of SPR if they still
> look that nasty when heading for 2CDs bitrate with the old luma code?
> I'm really eager to see that... The bitrates I get with the matrix now
> in the 1st pass are amazing compared to those with the former code, but
> I'm not sure if this is really good as it could have visual impact (I
> mean this as in: very easy to see).

I've started an SPR encode, however my computer is pretty slow and the first
still needs 5 hours :-(

> It would be really nice if this only derives from the "wrong" luma code
> (btw., luma masking was switched on in all XviD tests of Doom9 for this
> comparison).

Hm, somehow I can't believe that only the other lumi masking code could mess
up the whole encode especially because doom9 more or less reached his
desired filesizes - but let's hope...

bye
Michael