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 <> 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.


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

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