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

[Kieran Clancy]

On Sun, May 4, 2014 at 4:31 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> I still think you are looking at the completely wrong thing.
> Yes, the encoder can't flush data, so some audio data will be lost.
> However the data buffer_len refers to is _already encoded_ data.

You are right, that sounds reasonable.

> Since you talk about "whole frame" you seem to (I believe mistakenly?)
> assume that frames have some fixed size?
> Whenever we get data back from the encoder it should be a frame.
> Which might mean the fact that buffer_len becomes > 0 is a bug in the
> first place.

I'm aware that frames have variable sizes.

Perhaps there are several problems then.

After the last encoded data is produced

len = aencoder->encode(...);

is giving > 0 bytes, but then the while(1) loop continues.

Then, on a subsequent loop,

len = dec_audio(...);

is returning 0, overwriting the previous non-zero value of len, and
preventing muxer_write_chunk(...) on line 1394 from ever seeing the
data.

Could the solution be as simple as something like this?

Index: mencoder.c
===================================================================
--- mencoder.c    (revision 37181)
+++ mencoder.c    (working copy)
@@ -1362,7 +1362,7 @@
                 len = dec_audio(sh_audio,aencoder->decode_buffer,
aencoder->decode_buffer_size);
                 if(len <= 0)
                 {
-                    len = 0;
+                    len = mux_a->buffer_len;
                     break;
                 }
                 len = aencoder->encode(aencoder, mux_a->buffer +
mux_a->buffer_len, aencoder->decode_buffer, len,
mux_a->buffer_size-mux_a->buffer_len);

This should ensure that a non-zero buffer_len will still cause one
last call to muxer_write_chunk(...) on line 1394, and on the next loop
through it will properly reach the EOF condition.