[MPlayer-dev-eng] [PATCH] mencoder: detect end of audio stream while encoded data still buffered

[Grozdan]

On Tue, May 6, 2014 at 8:45 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Wed, May 07, 2014 at 01:10:25AM +0930, Kieran Clancy wrote:
>> On Tue, May 6, 2014 at 2:24 PM, Reimar Döffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > On 06.05.2014, at 02:01, Kieran Clancy <clancy.kieran+mplayer at gmail.com> wrote:
>> >>
>> >> It may well be in practice that mp3lame is the only codec affected. In
>> >> theory though, I don't see how a VBR codec can be expected to guess in
>> >> advance exactly how long its audio frame will be?
>> >
>> > It can't but this line above claims that all audio frames are exactly samples_per_frame long.
>> > I am not completely sure it is this line though, it might be that the get_frame_size function instead returns something wrong.
>>
>> When I was debugging the problem, mp3lame was returning many different
>> frame sizes, it wasn't fixed. Is it possible that the frame size is
>> not "wrong" but just LAME's best guess based on previous data?
>>
>> I just checked; ae_lame.c's get_frame_size is more-or-less just:
>>
>> mp_decode_mp3_header(encoder->stream->buffer);
>>
>> All this function does is calculate frame size from the current VBR
>> bitrate. So LAME is choosing a bitrate based on the first chunk of
>> audio data it receives and then get_frame_size is calculating the
>> expected frame size. Looking at the MP3 file spec, this seems
>> reasonable.
>>
>> In fact, I believe this means my first intuition was probably correct
>> after all; this means the data in a_mux->buffer is from a incomplete
>> frame and should not be written at all!
>
> Oh dear. I forgot how crappy mp3lame is. That design makes
> no sense but they seem to have done it like that anyway.
> I thinking of it I remember the annoyance this caused for FFmpeg.
>
>> As I said in my first email, it would be nice if mencoder had the
>> architecture to request encoders complete their frames on EOS (both
>> LAME and lavc have capabilities for padding the final frame
>> appropriately, though this can result in slightly longer audio than
>> the original file), but it would require big changes.
>
> I don't think so. I haven't tested it properly, but I just sent
> a patch that should do it.
> It will work fine for lavc and faac without further changes and needs only
> a tiny change for mp3lame.
> I couldn't find any documentation for toolame...

Hi Reimar,

Is this patch committed yet so I can pull a new version with the patch
included? My mplayer is betting a bit old and I'd like to compile the
latest SVN

Thanks :)

> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng



-- 
Yours truly