[whatwg] Video : Slow motion, fast forward effects

[Eric Carlson]

On Oct 13, 2008, at 3:41 PM, Ian Hickson wrote:

>
> On Thu, 7 Aug 2008, Chris Double wrote:
>> On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> On Thu, 7 Aug 2008, Biju Gm at il 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.
>
   Some media formats and/or engines may not support reverse playback,  
but I think it is a mistake for the spec to mandate this behavior. Why  
is reverse playback different from other situations described in the  
spec where different UAs/ media formats will result in different  
behavior, eg. pitch adjusted audio, negotiation with a server to  
achieve the appropriate playback rate, etc?

   I think the current sentence that talks about audio playback rate:

   When the playbackRate is so low or so high that the user agent  
cannot play audio usefully, the corresponding audio must not play.

could be modified to include reverse playback as well:

   When the playbackRate is such that the user agent cannot play audio  
usefully (eg. too low, too high, negative when the format or engine  
does not support reverse playback), the corresponding audio must not  
play.


Eric


>
> 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.   `._.-(,_..'-- 
> (,_..'`-.;.'