On Tue, May 6, 2014 at 2:23 AM, Reimar Döffinger <Reimar.Doeffinger@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.