Re: HTMLMediaElement defaultPlaybackRate and playbackRate

>> I know that Ian is also concerned that having a single playback rate
>> will lead to contention when multiple controllers are driving the  
>> same
>> media engine - making sure that a second controller's play() button
>> "does the right thing". This doesn't seem like a very frequent use  
>> case,
>> but even if is we still have contention because defaultPlaybackRate  
>> is
>> also mutable.
>>
>> We are concerned that people will end up using defaultPlaybackRate  
>> to do
>> "trick" modes (fast forward, slow motion, etc) because with the  
>> current
>> model it is the only way to ensure that media starts playing at the
>> desired rate while avoiding the artifacts mentioned above. In other
>> words, to play at 2x they will set defaultPlaybackRate to 2.0 and  
>> call
>> play(), and then set playbackRate *and* defaultPlaybackRate back to  
>> 1.0
>> when they want to resume regular playback.
>>
>> We believe that two playback rates are not necessary, and that the
>> current model will actually cause problems. Lets get rid of
>> defaultPlaybackRate, playbackRate is sufficient.
>
> We need the two otherwise there's no way for controllers to  
> cooperate when
> doing fast-forward over a resource that is playing at an accelerated  
> rate.
> It's the same as muted vs volume, except that defaultPlaybackRate  
> doesn't
> really _do_ anything now (except during the load() method).

I wouldn't say defaultPlaybackRate / playbackRate = muted / volume:  
they are really different concepts. A better parallel is paused /  
playbackRate or a non-existing defaultVolume / volume.

In any case, you said in a different thread something I found really  
valuable: "The whole point of <video> is to not provide too many ways  
that authors can screw things up.". Well having both a  
"defaultPlaybackRate" and "playbackRate" is certainly increasing the  
"can screw things up" factor. Just explaining which one does what in  
which exact case is already complex...
Now that we removed the "zero is not supported restriction" on  
playbackRate, we really have a parallel with volume and it's dead  
simple to understand: it's just a rendering attribute (like volume),  
but doesn't affect the play state (like volume). And like volume  
(volumechange), it fires an event when changed (ratechange). The only  
difference is that the volume event also fires when "muted" is  
changed, contrary to the ratechange one which doesn't when pause() is  
called (but since "paused" is r/o contrary to "muted", that might be  
ok after-all).

Regarding your example UI scenario, first of all, IMHO it's enough of  
an edge case to be negligible against the benefits of not having both  
playbackRate and defaultPlaybackRate, and second of all, I just don't  
understand it: considering you can "bind" your UI to  
"playbackRate" (you both set it and observe it), and it's the same for  
other states, how would the 2 controllers not be in sync?

________________________________
Pierre-Olivier Latour - pol@apple.com
Rich Media Team - Apple, Inc.

Received on Tuesday, 2 December 2008 00:01:47 UTC