fixed i-frame problems

[saVe]

i'm using koepi's build from 28/02/2002 for the trailer from "entrapment". settings: modulated quant type, credits enabled (30%), cc low 15% high 25%, quantizers 1-31, i-frame 2-5, smooth quant enabled.

got good quality and almost exact filesize, so nothing to really complain about, but in debugview i found some intra-frames that have quants of about 6 or 7. since my i-frame lock is set to 2-5 this shouldn't happen though. i read that foxer's curve compression isn't dealing with i-frames so i think that this isn't the problem, and almost all intra-frames do have a quant of 5 after all so the restrictions at least got recognized by the codec.

any ideas on this?

edit: just came to my mind that the tilte might give the impression i fixed a bug so i changed it. sorry!

[-h]

Hrm this isn't "possible", unless you're using lumi masking (which can change the value of the frame quantizer reported back to vfw).

If you're not using lumi masking, then your computer is very bad at math :)

-h

[saVe]

nope, no lumi masking here...

thought it might be because of foxer's curve compression. does it never override the i-frame settings for the sake of size predictability?

well, at least i'm the only one here whoose computer has free will (windows xp ;))!

[-h]

The thing is, the I-frame constraint is applied *after* the curve compression has had its way with the data (even though it isn't applied to I-frames atm). So no matter what happens beforehand, the frame quant is constrained at the end of the function.

Odd stuff :)

-h

[Koepi]

That problem appears here as well (so it's confirmed).

I'm in the middle of a second pass now, restricted intraframes to 2-4 - and there are plenty of them showing up with quant 5.

The CVS is in a bad state ATM :-/

We should correct the curve compression stuff ASAP.

Regards,
Koepi

[Foxer]

Correct the curve compression stuff asap..

Has it now become the cause of all the problems the codec has? lol

I found the cause of this and e-mailed -h a corrected version.

The implementation of keyframe spacing ignored what get_quant() had set frame.intra to and if it was nolonger trying to space out keyframes, it set it so that the core could decide whether to make it an i-frame or a p-frame.

That is why those shown i-frames get clamped using the p-frame range.

[-h]

Yeah why bother blaming curve compression, when it's just a good old -h bug?

:D

-h

[Foxer]

rofl :)

[saVe]

the bugs here really get fixed over night!
(when you're european)

thank you guys!

[Koepi]

Uh, sorry pals :)

I prematurely assumed that this bug introduced itself along with the new code added ;)

My bad, and all my apologies!

Regards,
Koepi