I use it to inspect video frames by frames, particularly being able to go back one frame. VLC doesn't support it, this thread about the feature is hilarious https://forum.videolan.org/viewtopic.php?t=120627
replies(19):
The claim that you would have to decode all previous frames in the entire video is... completely baffling to see coming from the dev. He's arguing a stupid technicality that a video might not have keyframes. That's not a reason to omit the feature entirely.
Going backwards might be hard because if you structured your code in certain ways you may not be able to go backwards efficiently. You can "seek", but how far back to you want to seek? A second? Two seconds? current-X frames?
key frames may be in a standard cadence, but they may not be. So again, how far back do you seek to go back one frame? And keyframes may be abstracted away from the player itself, since really, the codecs are the ones that deal with that stuff. For example, I believe mjpeg doesn't do frame differencing (I'm probably wrong about that).
The ideal implementation would save the last X frames then re-render once you go back like X/2 frames. But again, it depends.
Going back from frame 500000 to frame 499999 is in the limiting case as complex as seeking from 1 to 499999, and in most cases far better.
I think the forum thread would be better answered "you do it, I don't need this feature" which is basically the gist of it and is a completely fair answer.
Efficiency is not as important as having the feature at all. "Go back 5 seconds and then run forward to the right frame" is a sufficient algorithm, as long as it can track and combine multiple presses of the previous-frame key. Improvements can come later. Maybe buffering, maybe tracking keyframes, maybe other things. But this is a big case of letting the perfect be the enemy of the good.
If it fails to find a keyframe, that sucks, but 99% of the time it'll work.
Seriously, I don't get these people that have infinite demands from open source developers and contribute zero.
The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.
That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.
I'm relatively sure this can be implemented in terms of timestamp-based seeking. Quite possibly the metadata of the frames is already in the memory, further simplifying the process.
It's not about "technical chops", it's about being constantly available, reliable person that shows to contribute day after day. If you don't do that why should a dev make the scope of their work bigger if they won't be able to keep putting the same quality of work?
Variable frame rate (VFR) videos break this approach. It might seem like an esoteric edge case, TV and movies aren't VFR after all, but VFR is extremely common in videos from smartphones.
They shouldn't...but that's not at all what the primary developer said.
The issue is the primary dev seems to require reverse seek functionality to work with all codecs, and since some obscure codecs can't efficiently support it, they're not interested. Their challenge to others to submit a PR is counteracted by all the signs that they might provide a high-to-impossible barrier to approval.
It's not clear that even a trusted contributor would be able to sway this person's mind. Most likely, contributors either agree, or keep quiet on the issue if they disagree.
I expect it to work unless the frame rate is wildly varying, e.g. 60 fps and 60 spf in the same video. I guess one reasonable use case would be video that's triggered by motion, though. It would still work for almost every video.
There are TV shows that have telecined film segments and also interlaced VFX sections. While this wasn't broadcast as VFR the best way (as in highest quality result) to convert to a fully progressive frame sequence for display on modern displays would end up recombining the two fields for telecined segments (keeping the framerate) while doubling the framerate during deinterlacing for the VFX segments.
But VFR is also irrelevant to the problem at hand since it doesn't make it harder to find the next keyframe before the current frame - you need an index for that anyway.