Re: [Lame-dev] lame_encode_flush() emits too much data

[Daniel S. <daniel@InstantHarmony.com>]

Well, dang! Why didn't i check the dev-branch in the first place? :-)

Anyway, lame.c revs 1.323.2.{5,6,7} totally fix the problem *and* emit
one less packet than the code did previously, which correspondingly
reduces the transcode 'growth'.

Thanks!
-daniel


> On Thu, Apr 30, 2009 at 6:27 AM, Robert Hegemann <Rob...@gm...> wrote:
>>
>> You may check out current CVS (main-branch or lame3_98-bugfix branch).
>> There we have a workaround for the FFmpeg bug already. The "accumulating
>> any returned samples" thing wont work, it never really did.
>>
>> Ciao Robert
>>
>> ----- Original Message ----- From: "Daniel Steinberg" <daniel@InstantHarmony.com>
>> To: "robert" <Rob...@gm...>
>> Cc: <lam...@li...>; "Gabriel Bouvigne" <bou...@mp...>
>> Sent: Thursday, April 30, 2009 3:17 PM
>> Subject: Re: [Lame-dev] lame_encode_flush() emits too much data
>>
>>
>> Two things to note:
>>
>> 1) The style of flushing that i described was working in older versions of
>> lame, and it works perfectly with the changes i suggest.  I don't think
>> there is any downside to those changes....they fix some cases where
>> lame_encode_flush() is called only once, as well.
>>
>> 2) That style of flushing was cribbed from ffmpeg sources, which do the same
>> thing.  Ffmpeg does some additional buffering, and each call to
>> avcodec_encode_audio() with a NULL input buffer results in a call to
>> lame_encode_flush(), accumulating any returned samples,
>> until avcodec_encode_audio()  returns zero.
>>
>> -daniel
>>
>> On Thu, Apr 30, 2009 at 2:39 AM, robert <Rob...@gm...> wrote:
>>
>>> Am 30.04.2009, 11:01 Uhr, schrieb Gabriel Bouvigne <bou...@mp...
>>> >:
>>>
>>> > robert a écrit :
>>> >> The lame_encode_flush function has to be called once and for all at
>>> >> the end of encoding. The buffer has to be large enough to get all
>>> >> data left in one go. If we wanted to support the way Daniel is using
>>> >> it, then we will have to add a new output buffer stage in LAME, or add
>>> >> a state machine for the possibility of several calls to
>>> >> lame_encode_flush.
>>> >
>>> > Then I have a question:
>>> > If flush should be called only once, which buffer size should be used,
>>> > and how to be sure the buffer was big enough? (flush doesn't report -1
>>> > is the buffer is too small, does it?)
>>>
>>> lame_encode_flush does return -1 if the buffer *was* too small, there is
>>> no way to recover then.
>>>
>>> > It seems to me that the 7200 bytes is a "safe" value only if the user
>>> > provided buffers big enough during the last lame_encode_buffer calls. Am
>>> > I missing something there?
>>>
>>> If the buffer passed to lame_encode_buffer is constantly too small, then
>>> at some point LAME's internal buffer will overrun and this may result in
>>> a fatal error, meaning abort/exit.
>>> The internal buffer is round about 144000 bytes large. This is likely
>>> too small if you feed in all of your input data in one go.
>>>
>>> The estimation taken from lame.h is quite conservative:
>>>       mp3buf_size in bytes = 1.25*num_samples + 7200
>>>
>>> Compare that one with a single 640 kbps frame at 32 kHz samplerate:
>>>       framesize = 2 * 72000 * 640 / 32000 + 1 = 2881;
>>>
>>> Ciao Robert