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

[Alan Curry]

Uoti Urpala writes the following:
>
>It's clearly wrong, not just "not the best possible". Writing the test
>like that will often set AOPLAY_FINAL_CHUNK unnecessarily, in many cases
>for every play() call. If you think the ao drivers should always behave
>as if the flag was set then adding the flag is pointless.

I never found it setting the flag prematurely in my tests. And it can be
clearly wrong to someone who understands how the sh_audio interface is
supposed to work, but to me that's just a big undocumented mess so nothing is
clear except this: The result of the patch was an improvement in playing some
short WAVE files.

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

What I was going to say there, before I got distracted editing another part
of the message, was that this sounds like another case of the same kind of
bug found in demuxer_lavf: peeking into the wrong buffering layer.

>Cut sentence? Anyway here's a way to implement this test and the
>AOPLAY_FINAL_CHUNK test based on return value of decode_audio(). Not a
>complete patch and untested but hopefully it shows the method.

It should at least teach me something... I hadn't been paying attention to
the return value of decode_audio.