jamesplease2@ Thanks for the issue.

Request you to provide a sample file/URL where this issue can reproduced, which will help in further triaging.

Thanks..

We are not interested to implement negative playback rate because the effort to do this correctly is significant.

This said, it's mostly a backend question so I will assign this to dalecurtis@ and see if he has changed his mind.

We won't add support for this. It's not worth the complexity.

Thanks for the update, Dale. Is there more information that you could provide as to why this feature is complex?

Is it the initial development cost, or the maintenance, or a combination of the two

Also, would you be open to external contributors helping to add it?

It's development and resource usage. You need to decode from some point prior to the current playback head to account for keyframes and keep that entire decoded amount in memory. For video this would mean decoding the entire set of frames from the nearest keyframe to playhead and then playing them backwards. You'd then need to reissue a seek in the file for the next set of keyframes once a given block is elapsed.

Seeks are pretty expensive to do in the SRC= case, and in the MSE case the entire spec doesn't understand backwards playback rate, so current concepts around running garbage collection ahead of playhead would need to be flipped. Which is also non-trivial on the implementation side.

For audio the need for constant seeking would require lots of overhead since generally each audio packet, while a key frame, is still slightly influenced by the preceding packet. I don't know if it's always limited to 1 preroll packet either.

For anyone that needs this, it'd be much more resource effective to just keep a copy of the media encoded backwards.

Thank you for the details, Dale!

It sounds like it could helpful if _other_ specifications were updated before the HTML5 video spec, so that negative playback rates are more straightforward to work with in the browser. With that said, I am not sure if making the necessary changes is realistic; I am not at all familiar with the MSE spec, for instance.

> it'd be much more resource effective to just keep a copy of the media encoded backwards.

I think that this solution will work for a subset of use cases. I am working with the entire Netflix catalog, and encoding every video backwards is not an option.

For now, I am going to do what the engineers at Apple are doing: constantly seeking to mimic negative playback. It is not great, but it sounds like that is the best option available as a general-purpose solution.

I can't think of any implementation that doesn't involve seeking, we'd probably just do the same thing in C++ assuming we implementing something like this.

Understood.

Well, I am holding out hope for the implementation – whatever that may be – getting upstreamed into browsers. Right now, individual developers are responsible for solving it on their own over and over again, which is never a great place for us to be in!

Eh, for things like this with both low/non-existent usage and where there can be many hidden performance costs that are content+usage dependent, it doesn't makes sense to build into the browser. It's not even built into any desktop players that I can find. FFmpeg will allow you to re-encode it in reverse, but does so by decoding every frame into memory :o

Instead we probably want to get to a world where developers would have the primitives to implement this as efficiently as we would be able to. That might mean some sort of JS decoder API and output surface which could be strung together for a seamless implementation.