Re: Change Proposal for ISSUE-147

On Mar 18, 2011, at 2:34 PM, Philip Jägenstedt wrote:

> On Fri, 18 Mar 2011 21:53:54 +0100, David Singer <singer@apple.com> wrote:
> 
>> 
>> On Mar 18, 2011, at 1:39 , Philip Jägenstedt wrote:
>> 
>>> 
>>> In principle, this seems OK, if a bit unnecessary. We already have the  
>>> raw snapshot metric for determining playback speed: currentTime. Would  
>>> actualPlaybackRate be the derivate of that over a defined period of  
>>> time?
>>> 
>>> Anyway, it's not at all clear to me what scripts would actually do with  
>>> this information. Tell the users that their browsers sucks?
>> 
>> 
>> Please remember that there are sources that might not be seekable at  
>> all.  For example, if I have a URL form to address a TV tuner, you are  
>> either tuned in, playing at 1.0, or not.  Similarly, a hypothetical URL  
>> that asks for the source to be your camera cannot do anything. If your  
>> connection is RTSP/RTP, you can ask for non-1.0 playback rates, but the  
>> server might 'suck' and refuse.
>> 
>> So it might not be your browser (or mine) that sucks.
> 
> Of course, I was being ironic. It's depressingly common for web authors to  
> tell users to "get a better browser" or other kinds of insults in this  
> kind of situation. If there's no better use case than annoying users for  
> allowing scripts to detect this situation, I think we should not change  
> the API at all.

Well, scripts can ensure that the user interface they present aligns with what is happening in the video - i.e. the fast forward icon isn't lit up if the video is not actually playing faster than 1.0. Some people may want to display the actual playout speed ( "x 5" ) etc.

Also useful would be to find out the supporting range of playback speeds in advance, so that fast forward/rewind icons could be dimmed when those features are not supported.

...Mark 

> 
> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software
> 
>

Received on Friday, 18 March 2011 22:03:59 UTC