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

Grozdan neutrino8 at gmail.com
Sun May 4 13:28:00 CEST 2014


On Sun, May 4, 2014 at 5:03 AM, Kieran Clancy
<clancy.kieran+mplayer at gmail.com> wrote:
> On Sun, May 4, 2014 at 7:33 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>>>
>>> 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);
>>
>> That doesn't make sense, len is the amount of data to _encode_ here,
>> so it needs to be the amount of data in aencoder->decode_buffer.
>> But mux_a->buffer_len is the amount of already encoded data.
>> If we ignore the fact that we lose some amount of audio data at the end
>> for now, the only issue is that not all data is _muxed_.
>> There is no problem with the encoder or the amount of data it creates,
>> gets or anything at all.
>> I think your original patch was close to right, I just think it should
>> call the muxing function one last time with whatever remains in
>> mux_a->buffer_len (if anything).
>
>
> Please re-check my latest (inline) patch; it should do exactly what
> you describe.
>
> Since it is breaking out of the loop, len is not the amount to encode,
> but the amount of bytes to mux.
>
> I do admit that 'len' here is an inherently confusing variable as it's
> used in two completely different ways. During the loop it's used for
> the number of bytes decoded. Outside of the loop it's used as the
> number of bytes ready for muxing. It would probably be sensible to
> have two separate variables to avoid confusion.
>
> Kieran.

I don't see a patch

> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng



-- 
Yours truly


More information about the MPlayer-dev-eng mailing list