HTML video element: negative playbackRate

[jamesplease]

The Problem

The spec does not require support for negative playback rates. Some browsers support a negative playback rate, others do not.

Browser	Support?
Safari	✔
Chrome	✘
Firefox	✘
Edge	?

Should I add other browsers to this table?

Proposed Changes

1. an update to the spec to require support for negative playback rate
2. browser willingness to implement the functionality

Perhaps it would make sense to require the same playback rates in both directions. So if a browser supports from +0.1 to +16, then it would also need to support -0.1 to -16.

Previous discussion

Firefox

@cpearce from the Mozilla team summarized the opinion of the Firefox team over in #2754 (comment) :

As a feature, it seems more of a gimmick, a usage pattern left over from the days of VCRs, rather than something which will have significant use in the modern web. We don't see a compelling use case for it.

Chrome

It has probably been discussed somewhere, but I do not where the discussion is at this time. I couldn't find an existing Chromium issue.

Usefulness

I originally described this example over in #2754 (comment)

Video editing in the browser is one area where negative playback rates would be useful. In Adobe Premiere, a popular video editing tool, there are 3 hotkeys that are used for "shuttling" (moving through the video): J, K, and L.

Hotkey	Behavior
J	play the video in reverse. continually press it to increase the (negative) playback speed
K	pause the video, and set the playback speed to 1
L	play the video in the forward direction. continued presses increase the (positive) playback speed

Users of Premiere are constantly using this system to navigate videos, and anyone who is making a video editor in the browser will likely want to reproduce this same workflow.

A tutorial demonstrating shuttling in Premiere can be viewed on YouTube here.

Relevant links

I'll find and/or create links on the relevant browser issue trackers, but I haven't yet.

• Chromium issue
• Bugzilla issue
• Motivating comment: This is the comment from @annevk that motivated me to open this issue.

[hober]

cc @whatwg/media

[johannesodland]

A negative playback rate would be really useful.

In my work at a public broadcasting company in Norway (NRK) we sometimes use videos with prerendered graphics for visualisations and explainers in our articles. The videos are synced with the text as you scroll, and follows the user even if the user scrolls backwards.

At the moment we use the playbackRate when the user scrolls down the document, but have to resort to setting the currentTime when the user is scrolling back up.

An example can be seen in this article. Scroll down until you get to the graphics with a skier drawn on a black background.

https://www.nrk.no/vitenskapen-bak-medaljen-_-didrik-tonseth-1.14405976

[bes]

I work at a company trying to build a video analysis platform on the web, and rewind support would be really very useful for us. We are using HLS and in the future potentially MPEG-DASH through MSE (HLS.js/Shaka/etc.)

[johannesodland]

See also New York Times explainer: https://www.nytimes.com/interactive/2019/03/29/business/boeing-737-max-8-flaws.html

Negative playback rate when scrolling up the page would be nice.

[johannesodland]

Another example from The New York Times:

https://www.nytimes.com/interactive/2019/07/16/world/europe/notre-dame.html

[johannesodland]

One final example from The New York Times:

https://www.nytimes.com/interactive/2019/09/25/world/americas/hurricane-dorian-abaco-island-bahamas.html

I hope it is clear that this is not a gimmick, nor a pattern left over form the days of VCR.

[gerasimvol]

It could be very useful in animations based on videos. Rewind back and forward. playbackRate is way more straightforward and performant than setting currentTime in interval.

Moreover, animating with currentTime causes FPS drop (https://medium.com/@akella/story-of-one-animation-webgl-and-not-webgl-c733c44f489e) and needs conversion to fix keyframes.

[worldoptimizer]

+1

Although nobody is addressing this from a technical perspective. Might there not be the buffer and progressive video codec issue holding this back. It would require much more memory and a slight performance overhead than just playing back the spaced full key frames and applying progression until the next full key frame is extracted from the stream. I believe premiere allocates much more memory than Chrome currently does to offer reverse playback on h264 clips?

[johannesodland]

I assume supporting a negative playbackRate would require more memory. Maybe there should be a declarative way to tell the browser that we intend to seek/use a negative playbackRate?

We see more and more use of this, and native support would provide a much smoother user experience.

I'm adding more examples:

https://www.nrk.no/norge/xl/slik-virker-den-nasjonale-koronadugnaden-1.14947139
https://www.vg.no/spesial/2019/hercules-ulykken/

[johannesodland]

A related issue with frame-accurate seeking is discussed in w3c/media-and-entertainment#4

[jjeff]

My use case is for short, silent video clips that "bounce" forward and back as an alternative to the loop attribute, by setting the playbackRate to -1 in the onended handler. While this is currently supported in Safari, it would be great to expect this behavior for the other browsers as well. Not (necessarily) a gimmick, this can be used to create more seamless video loops akin to Instagram's popular Boomerang feature.

[dabinat]

Why is rewinding a video seen as a niche use-case? That seems like basic functionality to me. I looked at some of the top desktop video players and they all have either a dedicated button for rewinding or the ability to initiate rewinding through keyboard shortcuts.

I run a video platform and users are frequently complaining to me about the inability to properly rewind (we have an imperfect solution that decrements currentTime). Our users expect smooth playback and navigation and are surprised when I have to explain to them that this is a browser shortcoming and direct them either to Safari or our dedicated desktop player.

I understand there may be issues with frame caching, but this could be specified as an attribute on the video tag if necessary. However, Safari does not appear to have an issue with supporting this functionality as-is.

[Moebits]

I just want to say that I REALLY want negative playback rates to be supported. I am creating a video player and since I want it to have the ability to playback in reverse, I guess the only way that I'll achieve that is by encoding a reversed version of the video and then replacing the source.

It would be nice to see this being supported for HTML audio elements as well (so basically on all HTMLMediaElements). As previously stated, this functionality would be really useful for anyone making online video/audio editors where the ability to rewind is a core feature.

Plus, there's already one browser that supports this (Safari). I would love it if this became standardized and received support on the other browsers.

[designerfuzzi]

Hint: In theory backward playing is just a buffer reverse. You can achieve same on unsupported browsers by providing a reverse stored mp3 that is skipped to the playposition needed (length - playpos), original silenced and or stoped and the play on the backward version from the new playposition and to the original again.. You just have to determine what is the slowed allowed speed forward or backward. And exactly in this browsers differ very much.

There are even js libraries that do the job automatically by organising a shadow reverse buffer and handling the timing.. as far i know in example p5.js does it.. but p5 has other problems, like no 100% support below safari 15.. well you actually dont need it as safari knows reverse playback for a long time.

[heyakyra]

For those who want to track/help browsers implementing this:

• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1468019
• Chrome/chromium: https://issues.chromium.org/issues/40410591 (incorrectly closed as duplicate. the linked duplicate ticket correctly closed as negative playbackrate being"ignored" is fixed by throwing an exception, but as worded this bug is not).

Each tracker has a "vote" or "+1" button, so no need to spam "me too" comments