SportContract is an online video platform for professional video analysts, and our users need to be able to have precise control over video forward and playback. Users expect to have an ability to play videos backwards because they got used to this in professional desktop software.

The feature to play videos forward / backwards / fast forward / fast backwards is needed otherwise a professional video editing solution in the browser is impossible.

It's clear, that not every video can support reverse playback out-of-box: only videos without intra-frame coding (that have I-frames only) don't require extra computational efforts and resources.

Our customers will be extremely happy if they can use this feature on any video, even at the cost of better hardware!

We are definitely not the only who are interested in this, for example: https://github.com/whatwg/html/issues/3754#issuecomment-472425603

We at Spiideo https://www.spiideo.com/ would also like to have support for negative video playback.

We are a video platform for Sports Teams to do training and match analysis (live and after the fact). Our customers are a number of major Football (soccer), American Footbal, Basketball, and clubs as well as medium to small size clubs.

Here is a YouTube video of our web player in action https://www.youtube.com/watch?v=oICaePA1_zI

We utilize many web APIs for creating our web app, e.g. WebGL and the media APIs (and we are actively looking at the standards of WebGPU / wasm to see if we can utilize those as well)

It is very important for our end-users - coaches and professional video analysts - to be able to quickly move forwards and backwards at varying playback speeds. Fast/slow forward usually works flawlessly and it would be a boon to our users to be able to play backwards as well. Our native app (iOS) does this already but professionals seem prefer the full computer experience and are requesting this feature from our web player.

There are other issues with video on the web (death by a thousand cuts), but solving this one would be one of the major hurdles for us.

Thanks!

Bryce, based on comment 2 and comment 3, it may make sense to reconsider priority here?

Thanks.

From the technical perspective there is significant complexity in implementing this:

• Decoding pipelines operate on the assumption that time will advance 'forward'.
• This is baked through not only Firefox but through broader codec design. E.g. encoders will pack data in an order that normally relies on frames being decoded in a forward order. I imagine decoders we rely on in operating systems are built with only forward playback in mind.
• So I think the way that backward playback would need to be done is by seeking back to the last key frame, decoding everything after that and storing those frames, playing those backward and then repeating. I think this would be a large rework, and that care would need to be taken in order to have a robust implementation.

Chrome have indicated a similar unwillingness to implement this, due largely to the difficulty in doing so. My understanding is that only Safari implement negative playback rate at this stage.

I think P3 is the appropriate priority for this, as even if we work on it, it is unlikely to be something we ship in the next release or so (as P2 would indicate). I'll defer to Adam as to if this is a feature that we'd like to put on the roadmap.

Thanks for your feedback, Bryce!

Thanks everyone for the feedback.
Bryce, I agree with your assessment, we should leave this as P3 for now.

Would even a rudimentary implementation be worthwhile, basically reimplementing the workaround many use in lieu of this being supported by browsers: don't actually play the media, but on an interval update the currentTime repeatedly in a backwards direction.