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

Kieran Clancy clancy.kieran+mplayer at gmail.com
Tue May 6 02:01:18 CEST 2014


On Tue, May 6, 2014 at 2:23 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
>
> What exactly do you mean by "for some"?
> For mp3lame it is this crappy workaround in ae_lame.c that should cause it:
> mux_a->wf->nBlockAlign=encoder->params.samples_per_frame; // required for l3codeca.acm + WMP 6.4
>
> I would hope we have no such hacks for all others.

How does that line cause the problem? I'm not really sure what it does.

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?

>> This patch checks mux_a->buffer_len and ensures any remaining data is muxed.
>
> Any reason to not just do it like attached patch?

It makes more sense to me to do it inside the audio loop than as an
addition at the end (ideally neither video nor audio frames would
require flushing after their respective loops). Also, it's easily
fixed but a_mux might not even be defined in the place you use it,
causing a NULL pointer dereference.

The other advantage of doing it inside the audio loop is that the
various muxer time adjustments and status messages will be correctly
updated too.

If there's something you don't like about the coding style in my
patch, feel free to change it, but I think it's the right place to put
it.

Kieran.


More information about the MPlayer-dev-eng mailing list