W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: ISSUE-147: playbackrate-undefined - Straw Poll for Objections

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 29 Mar 2011 11:23:23 +0200
To: public-html@w3.org
Message-ID: <op.vs3lo92nsr6mfa@localhost.localdomain>
On Mon, 28 Mar 2011 22:57:47 +0200, Sam Ruby <rubys@intertwingly.net>

> On 03/28/2011 08:00 AM, Sam Ruby wrote:
>> If something is produced in the next 36 hours I would support adding it
>> to the existing survey and extending the closure date by a corresponding
>> amount of time.
> The 3 co-chairs met and agreed that if a new proposal comes in by  
> 11:59pm PDT on the 29th, we will evaluate the proposal and if we find it  
> acceptable we will add it to the existing survey.  If we do so, we will  
> also change the closing date from April 4th to somewhere around April  
> 7th, depending on how long it takes for us to evaluate the proposal.

Thanks, here it is:

Summary: Consider inability to play at a given playback rate a hardware  
limitation and don't expose it via a dedicated API


In general, a user agent cannot know if it's possible to play at any given  
rate without actually trying it, as it depends on the size/bitrate of the  
video and available CPU, memory and other hardware resources, all of which  
can change at any time. Consequently, the actual playback rate must be  
exposed asynchronously some time after playbackRate was changed. As it  
happens, the raw metric for determining the actual playback rate is  
already available: currentTime. Working with it is not trivial, but  
entirely possible. Unless web authors request a simpler API and have  
strong use cases for it, we should accept this status quo.

Both Frank Oliver's [1] and Silvia Pfeiffer's [2] change proposals claims  
as a positive effect that "Script can reliably detect when an unsupported  
playbackRate has been requested." Yet, neither suggested API would allow  
scripts to detect the situation in a way that enables meaningful use  
cases. In particular, neither would allow the fast-forward button in a  
scripted UI to be dimmed or removed, as it's only possible to detect after  
the fact that playing at particular rate is not supported. At best, the  
fast-forward button would be dimmed/removed after the first time it's  
used, which has not been requested and seems like an obviously flawed UI.

An API that would be useful for scripts would have to expose the available  
playback rates synchronously and without trying to change the playback  
rate. Since it is not possible to expose this information in general,  
simply not adding an API for it is the only reasonable conclusion.


The behavior when the user agent can't play at the requested rate is  
already quite well defined:

  * playbackRate and defaultPlaybackRate reflect whatever value was set.

  * currentTime changes at a rate as close to playbackRate as possible.

To clarify the situation for authors, note in "Playing the media resource"  
or "Best practices for authors using media elements" that scripts must not  
assume that setting playbackRate to x causes currentTime to advance  
smoothly at exactly x, as hardware, software or format limitations may  
cause video frames to be dropped, audio to be choppy or muted.

Positive effects:

  * User agents are encouraged to support arbitrary playback rates rather  
than advertise their inability to do so.

  * Web authors are encouraged to make their video players degrade  
gracefully if the exact requested playback rate isn't possible to achieve.

  * No premature spec change without understanding the use cases.

Negative effects:

  * IE9 has to change.

[1] http://lists.w3.org/Archives/Public/public-html/2011Feb/0113.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0357.html

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 29 March 2011 09:23:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:34 UTC