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

[Reimar Döffinger]

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...