This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9224 - It should be mentioned that setting playbackRate can be ignored. I.e. if playing backwards is not supported by the codec, if hardware acceleration does not support it, etc.
Summary: It should be mentioned that setting playbackRate can be ignored. I.e. if play...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-11 08:14 UTC by contributor
Modified: 2010-10-04 13:55 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2010-03-11 08:14:58 UTC
Section: http://www.whatwg.org/specs/web-apps/current-work/#dom-media-playbackrate

Comment:
It should be mentioned that setting playbackRate can be ignored. I.e. if
playing backwards is not supported by the codec, if hardware acceleration does
not support it, etc.

Posted from: 83.85.115.123 by annevk@opera.com
Comment 1 Anne 2010-03-11 08:16:09 UTC
The preferred solution would be to just ignore setting and not throw an exception. The indication that nothing will happen is that the value is simply not changed.
Comment 2 Jan Lindquist 2010-03-11 12:00:08 UTC
Ignoring may not be always the best response. It may be the case that the underlying player may simply select the closest playback rate. In this case the event ratechange indicates the closest value that was selected. For example, player supports 2, 8, 16. A web application may try to use 3 in which case the player selects 2 as the playback rate.

Knowledge of the available rates is also an issue.

Two issues should be resolved:
1. what happens when selecting a playback rate other than the available ones
2. what are the available playback rates

Note that (2) playback rates may change over time. Ads may not allow for fastforward.
Comment 3 Ian 'Hixie' Hickson 2010-03-30 23:01:02 UTC
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: playbackRate can't be ignored. How well you can actually play the resource at the given rate is a quality of implementation issue. (For example, at an extreme, the UA could render each frame to an off-screen buffer, and then play the frames backwards.)
Comment 4 Jan Lindquist 2010-04-01 15:13:52 UTC
If I may reopen the bug here is a more concrete proposal to try to address potential problems with existing media players that have no means of passing informtion through the video element.

1. Add an event, playbackRateChanged. This allows for players to indicate a change in playbackRate. If using RTSP for example the requested playbackRate may not be supported and only in the response to a RTSP PLAY is it possible to indicate what rate it is.

2. Add a property with a list of available playbackRates? It allows for platform to provide available rates. The application can then offer a clear list of options for example 2x, 8x, 16x. Then application can select the desired playbackRate without having to guess a playbackRate.
Comment 5 Philip Jägenstedt 2010-04-06 03:36:36 UTC
No matter what the spec says, the following will happen:

If on setting playbackRate the value isn't supported the rate is simply play at the closest supported rate. No exception is thrown.

The only question is what playbackRate should return, the actual rate or the one set by script?

The only difference is if the result is discoverable by scripts. I don't think it's very important, authors that really want to know the speed can query currentTime at some different times and see what the actual rate is.

I don't think the problem is important enough to warrant new methods or properties on HTMLMediaElement.
Comment 6 Philip Jägenstedt 2010-04-07 13:24:15 UTC
(In reply to comment #4)
> If I may reopen the bug here is a more concrete proposal to try to address
> potential problems with existing media players that have no means of passing
> informtion through the video element.
> 
> 1. Add an event, playbackRateChanged. This allows for players to indicate a
> change in playbackRate. If using RTSP for example the requested playbackRate
> may not be supported and only in the response to a RTSP PLAY is it possible to
> indicate what rate it is.

The event exists, but it's called ratechange.

> 2. Add a property with a list of available playbackRates? It allows for
> platform to provide available rates. The application can then offer a clear
> list of options for example 2x, 8x, 16x. Then application can select the
> desired playbackRate without having to guess a playbackRate.

The most complete (somewhat overkill) solution would be to have a list or ranges of rates which are supported. However, the media frameworks I have worked with (DirectShow and GStreamer) don't seem to provide this kind of information, so I'm not sure how browsers would implement it.

If anything at all, I would favor something like canPlayRate(r) I think. I said the problem isn't important enough, but I should be humble and am interested to hear about platforms which have such limitations on the rate and what kind of UI they have to handle it.
Comment 7 Ian 'Hixie' Hickson 2010-04-13 01:38:27 UTC
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: As Philip says, the event is present and called 'ratechange'.

Regarding the other part of the proposal: it is not conforming to not play the video back at the specified rate. You can play the video back in a very poor fashion, e.g. one frame per minute, or something equally terrible, or you can repeatedly stall as you rebuffer the previous few frames in order to play them backwards, or whatever you need to do, but the current playback position has to advance at the playbackRate when the video is playing. It is non-conforming to go at a different rate.
Comment 8 Jan Lindquist 2010-04-13 20:34:32 UTC
In response to the commnt relating not following playingRate is non conforming I would like to refer to external steaming protocols like RTSP. In RTSP the client indicates the desired playbackRate through the scales header in RTSP PLAY and the server will either confirm the same playbackRate or it may make the closest approximation to the requested speed. The response to the RTSP PLAY will indicate which playbackRate was supported. This can be supported through the rateChange event.

So there isn't a single rule how a media player will react to requested playbackRate.