Re: [MPlayer-dev-eng] [PATCH] mencoder: detect end of audio stream while encoded data still buffered
- Date: Tue, 6 May 2014 20:45:50 +0200
- From: Reimar Döffinger <Reimar.Doeffinger@xxxxxx>
- Subject: Re: [MPlayer-dev-eng] [PATCH] mencoder: detect end of audio stream while encoded data still buffered
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@xxxxxx> wrote:
> > On 06.05.2014, at 02:01, Kieran Clancy <clancy.kieran+mplayer@xxxxxxxxx> 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:
> 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
> 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...
MPlayer-dev-eng mailing list