w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-147: undefined behavior when the user agent can't play back at the requested rate - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2011-03-27 to 2011-04-05.
3 answers have been received.
Jump to results for question:
- Objections to the change proposal to describe what to do if the user agent is unable to play media at the requested rate
- Objections to the change proposal to Introduce requestedPlaybackRate/actualPlaybackRate
- Objections to the change proposal to consider the inability to play at a given playback rate a hardware limitation
1. Objections to the change proposal to describe what to do if the user agent is unable to play media at the requested rate
We have a Change Proposal to describe what to do if the user agent is unable to play media at the requested rate. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the change proposal to describe what to do if the user agent is unable to play media at the requested rate |
|---|---|
| Robert O'Callahan | This change proposal requires the browser to determine immediately and synchronously whether it can play back the media at the new playback rate. As an implementor of the <video> element, I don't think we can implement this in general; we won't know whether we can maintain a given playback rate until we try to play back at that rate. Even then, whether we can sustain the rate will vary from moment to moment. |
| Ian Hickson | This proposal would break the ability for Web apps to be able to tell when the user has switched to "fast-forward" mode in a UA interface for the media element, as while the UA would know the user was in such a mode, the Web app would be unable to notice a difference in the playbackRate API. (And also vice versa, with the UA unable to tell when the Web app thought the user was fast-forwarding.) Also, the proposed text would be incompatible with a situation in which the user agent _can_ apply the requested rate for some part of the media but not all of it. |
| Theresa O'Connor | If the user agent is unable to play back at the requested rate, it may be able to choose a rate better than that which was the case before the request. For example, suppose a video is playing back at 1x. The user interacts with a fast forward widget, which requests a playback rate of 5x. The user agent is incapable of playing back at this rate, but it can do 4x. This Change Proposal would have the UA ignore the 5x request and leave the playback rate at 1x, but it would be much better to play back at 4x. |
2. Objections to the change proposal to Introduce requestedPlaybackRate/actualPlaybackRate
We have a Change Proposal to introduce requestedPlaybackRate/actualPlaybackRate to the HTML5 spec.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the change proposal to Introduce requestedPlaybackRate/actualPlaybackRate |
|---|---|
| Robert O'Callahan | This proposal seems under-specified. In particular it is unclear how the "actualPlaybackRate" should be computed, in particular what time window should be used. Given that actualPlaybackRate can vary from moment to moment, it's unclear how scripts should use it. And actualPlaybackRate may not be adequate to reflect the quality of the user experience; e.g. if the UA plays a the requested playback rate, but only at one frame per second, should we report actualPlaybackRate == requestedPlaybackRate and let the script assume everything is OK? There is interest in developing "media statistics" APIs for a broader variety of use-cases, such as performance analysis and adaptive streaming (and Webkit and Gecko already have demonstrated prototype implementations of such APIs). Those APIs will probably subsume "actualPlaybackRate" in a more general and better specified way. |
| Ian Hickson | There seems to be agreement to add a general metrics feature. Given that, this proposal has been retracted: http://lists.w3.org/Archives/Public/public-html/2011Mar/0709.html |
| Theresa O'Connor | No use case is given for script to be able to access the requestedPlaybackRate after attempting to set the playback rate. Instead of adding an additional attribute, it would be simpler to retain just playbackRate, and to have it return the actual playback rate. This would also be more compatible with existing user agents. |
3. Objections to the change proposal to consider the inability to play at a given playback rate a hardware limitation
We have a Change Proposal to consider the inability to play at a given playback rate a hardware limitation and not expose it via a dedicated API.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the change proposal to consider the inability to play at a given playback rate a hardware limitation |
|---|---|
| Robert O'Callahan | I agree wholeheartedly with the arguments in this proposal. This seems like the safest approach for now, and we'll still have the option of adding new APIs in the future if this approach turns out to be inadequate. |
| Ian Hickson | |
| Theresa O'Connor |
More details on responses
- Robert O'Callahan: last responded on 30, March 2011 at 08:35 (UTC)
- Ian Hickson: last responded on 30, March 2011 at 22:33 (UTC)
- Theresa O'Connor: last responded on 6, April 2011 at 00:37 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project