[MPlayer-users] feature request

[Rich Felker]

On Wed, Apr 27, 2005 at 10:41:35PM -0400, Robert Henney wrote:
> 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.

oh, to me cache means cpu cache, not mplayer -cache. sorry i was
confused. anyway you're right this is an issue with -cache enabled,
but normally it's not needed or useful, at least in my experience.

> > > 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.

well if decoding the video takes 25% cpu, that means it takes 1/4
realtime to decode up to a point. so if a gop is 10 seconds long
(typical), stepping backwards could take up to 2.5 seconds for each
frame. not horribly long, but going non-responsive for 2.5 seconds at
a time it rather annoying and unwieldy, imo.

rich