- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 29 Mar 2011 11:23:23 +0200
- To: public-html@w3.org
On Mon, 28 Mar 2011 22:57:47 +0200, Sam Ruby <rubys@intertwingly.net> wrote: > 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 Rationale: 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. Details: 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