ABR encoder: bits in reservoir

Elio Blanca via Lame-dev <[email protected]> Fri, 21 Jun 2019 19:54:28 +0200
Newsgroups gmane.comp.audio.mp3.lame
Message-ID <20190621195428.512cc4be@cindy>
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