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(-)