[MPlayer-dev-eng] [PATCH] audio file truncation

[Alan Curry]

Uoti Urpala writes the following:
>
>On Mon, 2006-06-05 at 21:45 -0400, Alan Curry wrote:
>> +    if(sh_audio->a_in_buffer_len==0 && sh_audio->a_buffer_len==0)
>> +      playflags |= AOPLAY_FINAL_CHUNK;
>
>This is wrong. You can't detect the final chunk this way; it's normal
>for those buffers to be empty in the middle of playback.

Well, I'm not surprised that my solution wasn't the best possible. It did
help in my test cases though.

>-  if(d_audio->eof && sh_audio->a_in_buffer_len <= 0 && sh_audio->a_buffer_len <= 0) eof = PT_NEXT_ENTRY;
>+  if(d_audio->eof && sh_audio->a_in_buffer_len <= 0 && sh_audio->a_buffer_len <= 0 && sh_audio->a_out_buffer_len <= 0) eof = PT_NEXT_ENTRY;
>
>While the change here isn't for the worse, the original and resulting
>line are questionable. It's not impossible for the decoder to have some
>internal buffering which cannot be seen from public buffer sizes. In my
>opinion this code should not attempt to detect EOF before decode_audio()
>returns <= 0.

So this is another case of
>
>> +  after the call is made. If flags & AOPLAY_FINAL_CHUNK, the end of the audio
>> +  stream is being played, so it should try to play the full "len" amount.
>
>AOPLAY_FINAL_CHUNK does not mean there's any more need to play the full
>"len" amount than without the flag. What it does mean is that the ao
>should not permanently reject the input because of its size; it's still
>ok to buffer it only partially on this call.

That's a better way of describing it. Or simply "try not to return 0". And I
think it's equivalent in the case of my implementation of the flag in ao_oss.

So... there was no comment on the demux_lavf patch. That means I got one
right?