[MPlayer-dev-eng] [PATCH] audio file truncation
clemens at ladisch.de
Thu Jun 8 11:45:13 CEST 2006
Uoti Urpala wrote:
> On Tue, 2006-06-06 at 18:03 +0200, Clemens Ladisch wrote:
> > Uoti Urpala wrote:
> > > [...] This does raise a question though:
> > > if it's OK for the ao to play 0 bytes on this call, how do we
> > > distinguish cases where the ao will accept data later (presumably after
> > > some sound has played and buffers have emptied), and cases where it will
> > > never succeed in playing the remaining bytes (assuming this is a
> > > significant possibility)?
> > (USB device unplugged, network down, sound server killed, ...)
> None of those potential reasons are specific to playing the last
> samples, and so aren't really relevant.
I just wanted to illustrate that there actually is a significant
possibility of play() never succeeding.
> > My understanding of the API is that play() guarantees to accept at least
> > as much data as indicated by get_space().
> I haven't seen such a requirement mentioned anywhere, nor does it match
> what the code does (it clearly expects to handle play() accepting less
Sorry, I wasn't very clear. play() guarantees that the _exact_ amount
returned by get_space() can be accepted. play() can accept less data
than its 'len' parameter only if 'len' is not equal to the return value
of get_space(); in other words, get_space() rounds its return value
according to the requirements of play().
This means that the truncation problem could be solved^H^H^H^H^H^Hworked
around by padding the last output to the size last returned by
A better solution would be if the driver would communicate to its users
what its internal alignment requirements are. Apparently,
ao_data.outburst seems to be such a value, but it is ignored by
mplayer.c when playing a video, and not all drivers bother to set it.
http://www.fastmail.fm - And now for something completely different
More information about the MPlayer-dev-eng