This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
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.
(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.
The HTML Accessibility Bug Triage sub-team doesn't think this is an accessibility issue or TF priority.
http://www.w3.org/html/wg/tracker/issues/147
Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Apr/0213.html
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