[MPlayer-users] how to "step backforward" ?

[Phil Rhodes]

> stepping forward is rather simple, it is 'normal'play at non-standard 
> speed.
> Going back is difficult in the sense you have to calculate several
> frames plus/minus the differences to 'know' how that former frame has
> looked.

Precisely.

However, "several frames" can actually be many tens or of frames, maybe a 
hundred frames in some edge circumstances, and with intensive codecs that's 
a very big job.

As far as I can see this boils down to two scenarios:

- We want a frame we have played recently, which is probably the most common 
situation. Most of the time, stepping backwards is used to find a specific 
frame of interest, through which we will probably have recently played - you 
wait till you see what you want, hit "pause", then step back until you find 
it. This situation is probably best handled by caching frames.

Or:

- We want a frame we haven't played recently. This could happen with DVD 
chapters or if you stepped through a long video with the arrow keys, and 
then tried to framestep back before the start of that part of the video. 
Regardless of the circumstances the only solution is brute force, although 
if you are at frame 100 and you want frame 99, if the last keyframe was 50, 
you have then mandatorially decoded frames 50-99 and should be able to 
revert to the cached-frame strategy. Virtualdub does not do this, which is 
what moves it from "slow" to "really freaking slow", because it seems to 
decode from last keyframe regardless of whether it just passed through the 
target frame enroute to another.

Refinements:

If you'd paused at frame 100, decoded from a keyframe at frame 50 all the 
way up to 100 so as to step back through it, you could implement a strategy 
such that as the user neared frame 50, and it looked like you were going to 
need frames below 50, you could start preemptively decoding from 50 back 
down to the previous keyframe.

With some codecs, you could probably greatly optimise memory consumption by 
creating a smart caching strategy to avoid needing to store entire decoded 
frames. For instance, if you had a chunk of image that was used in frame X 
and then in every frame up to the target frame at X+50, you'd only need to 
store that chunk of image once. This would effectively mean storing a 
partially-decoded version of the footage, enough to make realtime reverse 
play possible, and could potentially get very complex and would be codec 
specific, as well as subject to greater or lesser effectiveness depending on 
image content. I may be talking drivel here.

Do I know how to do any of this? Only in theory, I'm afraid.

P