Re: Change Proposal for ISSUE-147

On Mar 18, 2011, at 15:03 , Mark Watson wrote:

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

So, if 
a) when I 'set' the rate, it actually sets to what can be supported (closest equivalent rate)
b) rate-changed is posted when it actually changes

I can achieve these two, right?  Do I need the engine to remember what I asked for?

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

Nice to have, for sure, but sometimes the answer will be 'maybe', or contextual:
a) if I have to ask a server, I don't know until I ask
b) if it depends on where you are; if you have a buffer of a live signal, as Ian suggests, and you are in the middle of it, for sure, you can fast forward; you can't if you're at the 'now' end of it.
...

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

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Saturday, 19 March 2011 14:16:49 UTC