- From: Dave Singer <singer@apple.com>
- Date: Tue, 14 Oct 2008 14:35:19 +0900
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
Received on Monday, 13 October 2008 22:35:19 UTC