This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML media elements have a playbackRate attribute which can be used to adjust the playback rate. For video this just involves changing the display rate for frames. For audio the situation is more complicated. The simplest method is to resampling the audio relative to the audio device's playback rate. This results in a pitch shift: playbackRate > 1.5 or so is high and squeeky, playbackRate < 0.8 is low and echo-y. There are also more sophisticated methods which attempt to preserve the spectral character so that perceived pitches are preserved, though usually with some reduction in fidelity where music is concerned. There are reasonable use cases for both pitch-preserving and pitch-shifting cases, and the specification currently leaves the decision to implementors. Apple initially implemented the pitch-preserving case, but later added a 'webkitPreservesPitch' boolean attribute to control this choice.[1] Looking at how we'd support playbackRate in Firefox, we found this a useful distinction and suggest such an attribute be added to the specification. e.g.: interface HTMLMediaElement : HTMLElement { attribute boolean preservePitch; }; The element could default to true, since this is the less objectional behaviour and is compabtible with webkitPreservesPitch. [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021100.html
When would you _not_ want to preserve pitch in a media player? (I understand that you might want to do a pitch change for special sound effect purposes, but that's the kind of thing I'd expect to see in Web Audio, not in media elements.)
This bug was cloned to create bug 17809 as part of operation convergence.
Mass move to "HTML WG"
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: Additional Information Needed Change Description: No Spec Change Rationale: For IE's playbackRate support, we preserve pitch and do not offer a way to change this behavior--so both Chrome and IE agree on the default anyway. I'd love to hear from someone on the Chrome team that knows the motivation behind their property, or what "reasonable use cases" there are for the non-pitch preserving scenario--the folks I polled at Microsoft haven't had any customer requests for this and couldn't come up with compelling use cases.
This is absolutely essential for creative uses (pitch-able DJ-style players that work akin to record/tape players) and very much desirable for a wide range of applications. Could it be please reconsidered? In many cases, preserved pitch is also not aesthetically pleasing for slow motion video. The pitch down effect has cultural significance and would be highly appreciated in several scenes (skateboarding videos, for example).