At 22:41 +0000 13/10/08, Ian Hickson wrote:
On Thu, 7 Aug 2008, Dave Singer wrote:
>
> Would you expect the audio to be played backwards too?
I think that's extra credit and optional.
It's now not allowed, though I suppose an author could always have two
<video> elements and could make the hidden one seek back and play samples
forwards as the other is playing the video backwards.
I think that the spec. should say that degraded playback (e.g. I frames
only) or no playback (non-reversed audio) may occur...
I think that's a quality of implementation issue, I don't really see what
the spec can say about it.
It's a warning to authors and a permission to developers; a helpful
note, that's all.
On Thu, 7 Aug 2008, Dave Singer wrote:
I'm sorry if I wasn't clear: I agree. If you want your implementation
to shine, or be used heavily for audio scrubbing, or something, go ahead
and implement. But it should not be required. ("For extra credit")
We don't want some to do it and some not to do it, because then we get all
kinds of interoperability problems (e.g. someone who hides his video and
rewinds it at a particular rate for some reason or other, and doesn't hear
audio in one UA, deploys, and finds his users get audio on another UA).
I don't think I agree. I can't think why you would do such a rewind
(media files are not usually that much like physical tape), and if
you want to do it and be muted, you should mute. The spec. can be
perfectly clear that at non-unitary playback rates, including
negative ones, media may be presented degraded or, particularly for
audio, not at all. If muting is needed, then it should be explicitly
requested.
Working around this prohibition for the case of an implementation
that could do it and a site that *wants* audio scrubbing, would be a
pain in the neck.
--
David Singer
Apple/QuickTime
