Mpv – A free, open-source, and cross-platform media player

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

i wonder why he's such an ass about it, and totally adamant that it's impossible when multiple players already do this fast. ego?

I think technically he’s correct (I haven’t worked on media decoding code, but I understand how common video encoding formats work). If you have a long video with only a single key frame at the beginning then to step back you would need to, starting from the beginning of the video, decode every frame up to the previous frame you wanted to jump to in order to apply frame deltas, also assuming you have some sort of frame counter to determine when you’ve reached the target frame. In the worst case this does require a lot of compute, but this is an edge case if you primarily care about common video formats with normal encoding settings. I assume seeking backwards is also painfully slow on videos encoded in this manner, so why stepping back 1 frame is out of the question when compared to seeking backwards, I don’t fully understand, it must have something to do with precise frame counts being unavailable on some hardware decoders for some formats (and there being no good workaround) so you _may_ not actually go back 1 frame.

I don’t see any reason it couldn’t be supported for a set of formats with reasonable encoding/decoding settings, and provide some error message for other formats if a user attempts to step back, e.g. reverse frame stepping unavailable for current video due to format/encoding/decoding settings.

Wouldn’t creating in-memory key frames for every nth frame resolve substantial computations on a frame-by-frame basis?

you'd have to "rebase" all the other frames to be derived from those

You wouldn't have to any more than you need 0 through N frames in memory to calculate frame N+1. Whatever your decoding state completes at frame N can be considered a key frame.

decoding state can be bulkier than a key frame and opaque to the CPU if hardware acceleration is used

I wonder if caching semi-compressed frames would be more efficient in either case (CPU or GPU)