[MPlayer-users] feature request
dalias at aerifal.cx
Thu Apr 28 09:39:20 CEST 2005
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
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.
More information about the MPlayer-users