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