[MPlayer-users] feature request

[Robert Henney]

On Wed, Apr 27, 2005 at 08:59:23PM -0400, Rich Felker wrote:
> On Wed, Apr 27, 2005 at 05:25:49PM -0400, Robert Henney wrote:

> > > No it wasn't. This sort of feature is inherently not possible without
> > > a huge seek-and-decode chain for each step. It will probably never be
> > > implemented in any movie player simply because it doesn't belong. If
> > > you need this function, decode all frames to jpeg files and look at
> > > them with an image browser, or use a specialized nle program.
> > 
> > cache thrashing and the unidirectional nature of the decoding are certain 
> > to hinder any attempt to implement a feature such as this.
> 
> Huh? How is cache thrasing related??

I'm probably underestimating the cache handling in mplayer, since I've
not taken a look at that part of the source.  when seeking, especially 
seeking backwards, I was under the impression that the cache was 
refilled from the new stream point.  A repetitive jogging back and forth
along a section of a few dozen frames, as would happen with reverse 
stepping I would think, might cause this to occur and might be fairly 
noticeable.

> > putting the cache thrashing aside for now, one way to lessen the seeking
> > difficulty would be to keep a short history of the position of keyframes
> > encountered while playing.  then the nearest keyframe previous to the frame
> 
> This is pointless. In any good format you can find the keyframes
> easily without having to remember their positions.

good to know.  hopefully the formats in common use today fall under
this 'good' design.  :)

> > keyframe occurence is not exactly predictable and what constitutes a keyframe
> > may not be clear from codec to codec.  another hurdle, and no good solutions
> > I can think of for.
> 
> Nonsense; a keyframe is totally well-defined. Otherwise there'd be no
> way to seek.

likewise, glad to hear that.  it may not be nearly as unsurmountable as I 
had thought then.

> > one thing in our favor here is that no one expects seeking backwards to be
> > the same as playing backwards.  even with terrible inefficiency and the poor 
> > resulting performance of such a feature, something that would allow backing
> > up by n frames would be thought of as invaluable by many.
> 
> Remembering locations won't help you do this. You actually have to
> buffer all the frames. That's roughly 130 megs per gop.. :)

here's where you loose me.  seeking to the earliest previous I-frame at the
start of the current gop and decoding until the desired frame is reached
doesn't sound that bad.  not aiming for good fps here of course, because
we'd never get it this way.  but with eliminating the post-processing and 
video-out cycles in the recoding of the target frame (except for the target 
frame itself) the time required to step back from frame to frame may not 
prove too horrid.

buffering the whole decoded gop could gain really fast shifting of a 
displayed frame to the next earlier frame, but..  yeah, that approach would 
be more for video editing software on a powerhouse of a machine, but 
unthinkable for mplayer.

> > getting the sound re-synced quickly after leaving the framesetting state is 
> > another potential difficulty.  stepping forward right now does enough
> > damage to the A/V sync, and stepping backwards can only be worse.
> 
> This is just because mplayer sucks. With a good player design (albeit
> no good players exist) this is a non-issue.

:)