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

[belcampo]

Phil Rhodes wrote:
>> 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.
Do you know any, where I-Frames/Key-frames are more then 12 (PAL) or 15 
(NTSC) between. Where are larger GOP-sizes used ??

In mythtv the internal-player is based on ffplay and that is also used 
to 'edit-out' commercials. It is able to step back frame by frame, or 
forward/backward to the next I-Frame. But it therefore needs/uses a 
database with a 'seektable'
> 
> 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
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users