10837 2010-09-29 21:44:29 +0000 playbackrate: undefined behavior when the user agent can't play back at the requested rate 2011-04-27 22:11:11 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All RESOLVED FIXED a11y, media, TrackerIssue, WGDecision P2 normal --- 1 franko ian ian jfoliot laura.lee.carlson mike mjs philipj public-html-a11y public-html-admin public-html-wg-issue-tracking rubys w3c public-html-bugzilla oldest_to_newest 40019 0 franko 2010-09-29 21:44:29 +0000 In section 4.8.9.8: The spec does not define correct behavior when the user agent is not able to play back media at a requeted rate. (For example, the author sets playbackrate to a negative value, and the user agent does not support negative playback rates) Currenty, all browsers seem to handle this differently. SUGGESTED CHANGE: (Addition to spec) If the user agent is unable to play back media at the requested rate, ignore the requested rate; playbackrate must not change. 40153 1 philipj 2010-09-30 13:28:37 +0000 Indeed, Opera sets the playbackRate attribute but simply ignores it. The intention is of course to actually support it eventually, once compelling use cases come up. 40240 2 ian 2010-09-30 18:38:31 +0000 How can you not be able to support it? At the worst, you'll just have to keep seeking backwards and show a frame here and a frame there; it's just a quality of implementation issue. If you simply can't seek to that point the spec also defines how to handle that (same as if you can't seek forward, in fact). You just stall. I don't understand what the problem is here. 40564 3 franko 2010-10-04 17:03:25 +0000 there are cases where the user agent will be unable to change the playbackrate - for example, the user agent may be playing a live stream; the user agent may be unable to play media backwards (due to limitation of the media format - no keyframes) / at a high rate (limitation in hardware) - and 'faking' a playback rate with seeking behavior is not a viable alternative. The author should be able to determine that the user agent is not doing the 'true' requested playback rate. 40987 4 ian 2010-10-12 07:13:44 +0000 (In reply to comment #3) > there are cases where the user agent will be unable to change the playbackrate > - for example, the user agent may be playing a live stream When playing a live stream, either the browser has a local buffer or it does not. If it does, then playing backwards is fine (at the worst case, just seek back frame by frame). If it does not, then the "earliest possible position" will equal the current playback position and a playback rate that is less than the live rate will simply result in the browser continuously seeking forward to keep up with the live stream. In either case, this is already well-defined in the spec. > the user agent may be unable to play media backwards (due to limitation of the media format - no > keyframes) / at a high rate (limitation in hardware) - and 'faking' a playback > rate with seeking behavior is not a viable alternative. It's always viable -- in the worst case, you show the current frame then keep going backwards without showing anything (just moving the playback head on the seek bar) and then finally show the first frame. This is entirely a quality of implementation issue. Browsers that can decode such a stream and buffer it in a way that enables arbitrary seeking will be more usable and more competitive than browsers that can't. > The author should be able to determine that the user agent is not doing the > 'true' requested playback rate. If the problem is that the media doesn't support going backwards due to a lack of keyframes and due to a lack of implementations that can work around this limitation, then it's highly unlikely that the author will attempt to play the media data backwards in the first place. However, if the browser is faking it by seeking then it'll be quite clear: the browser will have fired a "seeking" event and then will not fire a "seeked" event, and the playback position will not be moving. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The spec already handles all the described cases. 41554 5 w3c 2010-10-19 15:19:31 +0000 The HTML Accessibility Bug Triage sub-team doesn't think this is an accessibility issue or TF priority. 42862 6 rubys 2010-11-29 19:42:08 +0000 http://www.w3.org/html/wg/tracker/issues/147 47279 7 rubys 2011-04-08 18:37:28 +0000 Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Apr/0213.html 47746 8 contributor 2011-04-27 22:11:11 +0000 Checked in as WHATWG revision r6033. Check-in comment: mention the problem with UAs that don't support playbackRate reliably. http://html5.org/tools/web-apps-tracker?from=6032&to=6033