[e00E]

mpv has fast inexact (key frame based) seeks like default hotkey RIGHT seek 5 and slow exact seeks like Shift+RIGHT seek 1 exact, . frame-step, ab-loop. This is especially noticeable and annoying when going back in time to what you have just watched one second or one frame ago. Stepping back one frame can take a full real time second to apply on regular high resolution low key frame files. This makes analyzing and rewatching short time ranges tedious.

This change improves this by adding an optional default disabled cache for recently decoded content. With this change, jumping in time within the cache is instant. Configurable with a time and memory limit.

The cache uses a lot of memory because it stores raw decoded video. This is fine as an advanced not by default enabled feature. My intended use case for this feature is to enable it specifically when you want to perform this kind of exact backward jumping, not enable it all the time.

Could handle subtitles more correctly but I wasn't sure how to do it right and is likely complexity overkill for this feature.

Tested on my machine.

Generate an example low key frame video to test with:

ffmpeg -hide_banner -loglevel warning -y \
    -f lavfi -i 'color=c=black:s=1920x1080:r=60' \
    -vf "drawtext=fontsize=64:fontcolor=white:x=80:y=80:text='Frame %{n}   Time %{pts}'" \
    -t 60 -an -c:v libx264 -preset veryfast -crf 18 -pix_fmt yuv420p -g 3600 -keyint_min 3600 -sc_threshold 0 -bf 3 \
    -movflags +faststart out.mp4

Play the file with default mpv. Let it play into the middle or end of the file, then step back one frame (default hotkey ,). Observe that it is slow (not instant).

Then test with this branch. mpv --no-config --hwdec=no --video-history=2 out.mp4. Repeat test and observe that it is fast (instant).

I used AI assistance for this change. Claude Code with Opus and Chatgpt Codex with Sol.

[guidocella]

This has limited usefulness if it doesn't work with hardware decoding, and with your example or --video-history=2 frame-back-step becomes slow again after like 1/10th of a second even though it makes mpv use 300 more MB of memory.

Have you tried cycle play-dir and using frame-step, or seek -0.01 to seek to the previous keyframe instead?

[e00E]

The main use case of this feature is to enable it when you want to repeatedly analyze small video sections. You then press a hotkey to turn on the cache. You would not enable it all the time so usually there is no memory overhead. I made this specifically because I often do this kind of video analysis and found it impossible on some files because of the latency when stepping back.

It works with the copy hardware decoding modes. I use those anyway but not sure how commonly used they are. It is also fine to disable hardware decoding while using this feature.

With video-history=2 it is fast for the most recently played 2 seconds (up to the memory limit). So it should be 2 seconds not 0.1. It does work that way for me. You do have to play through the section you're going to seek back to first. For example, if you fast seek to 10 seconds, then the previous 2 seconds are not cached because you didn't play them.

play-direction=backward does not work on my files. It stalls a lot and doesn't play smoothly. Seeking to the previous key frame doesn't work because they key frame is usually not in the right position (too far in the past). The exactness of the seek is important.

(I updated the PR description with some details from this comment.)

[e00E]

I think this is niche use case but enough people run into this that it would be useful for mpv to have as an advanced feature. This kind of feature is why I like mpv. Linking some previous issues I quickly found. There might be more.

#4019
#18439
#6095
#15305