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@xxxxxxxxxxxx
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
_______________________________________________
MPlayer-users mailing list
MPlayer-users@xxxxxxxxxxxx
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
