Re: [MPlayer-dev-eng] [PATCH] mencoder: detect end of audio stream while encoded data still buffered
- Date: Sun, 4 May 2014 13:28:00 +0200
- From: Grozdan <neutrino8@xxxxxxxxx>
- Subject: Re: [MPlayer-dev-eng] [PATCH] mencoder: detect end of audio stream while encoded data still buffered
On Sun, May 4, 2014 at 5:03 AM, Kieran Clancy
> On Sun, May 4, 2014 at 7:33 AM, Reimar DÃffinger
> <Reimar.Doeffinger@xxxxxx> 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,
>>> if(len <= 0)
>>> - len = 0;
>>> + len = mux_a->buffer_len;
>>> len = aencoder->encode(aencoder, mux_a->buffer +
>>> mux_a->buffer_len, aencoder->decode_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.
I don't see a patch
> MPlayer-dev-eng mailing list
MPlayer-dev-eng mailing list