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

[Kieran Clancy]

Changes to mencoder introduced by r36905 (2014-02-24; mencoder: Finish
encoding only when audio and video reached EOF.) introduced a
regression when using mp3lame and possibly other audio encoders.

This was first reported by Alexander Roalter on mplayer-users:
https://lists.mplayerhq.hu/pipermail/mplayer-users/2014-March/087288.html

$ mencoder -msglevel all=6 -o out.avi -oac mp3lame -ovc lavc input
...
(works normally until the end of the audio stream, but after the end
of the video stream, an endless loop of messages begins:)
...
ds_fill_buffer: EOF reached (stream: audio)
ds_fill_buffer: EOF reached (stream: video)
ds_fill_buffer: EOF reached (stream: audio)
ds_fill_buffer: EOF reached (stream: video)
...

After running a debugger, I found that the new code introduced by
r36905 assumes that mux_a->buffer_len == 0 on end-of-stream, but it is
often not the case for mp3lame (and probably other codecs).

Due to technicalities in the way LAME works, it may generate a partial
audio frame before the input stream ends, and mencoder lacks the
architecture to request that audio codecs in this situation complete
their partial frames on end-of-stream. I suspect other audio codecs
have the same issue.

In any case, the fix turned out to be very simple; there is no need to
assume that mux_a->buffer_len is zero on end-of-stream. Even if there
is outstanding data in mux_a->buffer, end-of-stream means it will
never be muxed into the output because dec_audio() will not provide
any more data for aencoder->encode().

Kieran Clancy

---
 mencoder.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mencoder_audio_eos_mp3lame.patch
Type: text/x-patch
Size: 600 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20140427/06fda1c5/attachment.bin>