Re: ABR encoder: bits in reservoir

Hello Elio,

when encoding a frame, each granule per channel consumes some bytes
for its data. The ResvAdjust function gets called each time and
decreases ResvSize by the amount used. At the end of the encoding
of one frame, a frame-size needs to be chosen, such that ResvSize is
greater or equal to zero again.

So 'ResvSize >= 0' is a pre- and postcondition of ABR_iteration_loop
but not an invariant.

Ciao Robert

Am .06.2019, 19:54 Uhr, schrieb Elio Blanca via Lame-dev <[email protected]>:

> I'm investigating bug #501 ( https://sourceforge.net/p/lame/bugs/501/ )
> and I need some support.
>
> The assertion fails into quantize.c in function ABR_iteration_loop, as
> no valid results are found into the previous 'for' loop. The reason is
> the called function ResvFrameBegin returns -9 . It is not a positive
> value and the 'if' condition (ResvFrameBegin(gfc, &mean_bits) >= 0)
> doesn't become true. Now, into ResvFrameBegin (source reservoir.c) the
> returned value is called fullFrameBits - from the comment above the
> function I read:
>
> fullFrameBits:  maximum number of bits available for encoding the
> current frame.
>
> and it sounds weird to me that a "maximum number of bits" holds a
> negative value. Going above at fullFrameBits calculation, I see the
> formula:
>
> fullFrameBits = meanBits * cfg->mode_gr + Min(esv->ResvSize,
> esv->ResvMax);
>
> which gives -9 as a result because:
> meanBits=272
> cfg->mode_gr=2
> esv->ResvSize=-553
> esv->ResvMax=4088
>
> Looking back again at the comment, I see:
> gfc->ResvMax:   maximum allowed reservoir
> and
> gfc->ResvSize:  current reservoir size
>
> and, as ResvMax value is 4088 (max reservoir for mpeg1 is 511 bytes, so
> 4088 bits), I would expect ResvSize to have values into [0..4088].
>
> Are those assumptions valid ?
> Can any developer shed some light on this ?
>
> Elio