On Thu, 7 Aug 2008, Chris Double wrote: > On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote: > >> > >> So can I assume HTML5 spec also allow playbackRate to be negative > >> value. ie to support go backward at various speed.... > > > > Yes. > > Would you expect the audio to be played backwards too? > > Given that codecs are often highly optimized for forward playback the > cost in memory can be excessive to go the other way. Could there be a > possibility to say 'reverse playback not supported'?
The spec now requires audio playback not to occur when going backwards, and allows the user agent to mute audio playback for rates less than or greater than 1.0 if desired. On Thu, 7 Aug 2008, Maik Merten wrote: > > An interesting case would also be how to handle playback speeds smaller > than "1x" in the streaming case, given that you cannot possibly have an > infinite buffer of input data. Irrespective of whether the file is streaming is not, you'll always have problems like this to do with. (Streaming makes them much more obvious though.) > Streaming mostly forces a playback speed of "+1x" in all cases. I don't think that's accurate. On Thu, 7 Aug 2008, Philip J�genstedt wrote: > > I suggest that the spec allows raising the NOT_SUPPORTED_ERR exception > in response to any playback rate which it cannot provide for the current > configuration. With a netcast you couldn't support any playback rate > except 1.0 without first buffering all the data you want to play at a > faster rate, so changing the playback rate doesn't make sense. Throwing > NOT_SUPPORTED_ERR must be better than just ignoring it, but the question > is if script authors will remember to check for exceptions when setting > the attribute... I think you should definitely be able to slow down or speed up locally, and I think it would make perfect sense for a UA to buffer the last N minutes of data, to allow pausing and seeking in the recent stream. This is what TiVo does, for instance, with live TV. I agree that we need to do something to stop seeking backwards past the start of the buffer, though. I've redefined "effective start" and company to make the UA seek when the buffer's earliest possible point moves. 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. 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). On Thu, 7 Aug 2008, Charles Iliya Krempeaux wrote: > > This feature would be used to implement "scrubing". Like what you see > in Non-Linear Editors... for making movies, etc. (I.e., grabbing the > "position handle" of the player, and moving it forwards and backwards > through the video, and varying speeds, to find what you are looking > for.) > > In those types of applications, the audio is on. And it is important > for usability, for the video editor to hear the sound. I agree that on the long term we would want to provide this, but I think that is something we should offer as a separate feature (e.g. a flag that decides whether reverse-playback audio is muted or not, defaulting to true for compatibility with today). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'