[MPlayer-cvslog] r18780 - trunk/mplayer.c

[Michael Niedermayer]

Hi

On Fri, Jun 23, 2006 at 04:31:22PM +0300, Uoti Urpala wrote:
[...]
> > its clear that this cannot work, one (dirty) solution is to send flip through
> > the filter chain,
> 
> This is not a solution at all IMO, not even a dirty one. It only allows
> you to undo the "-n" behavior in some filters. Current MPlayer cannot
> handle adding frames; this "solution" allows you to use a hack with
> another filter to (badly) undo the adding of frames, while it would be
> about as easy to make those filters just not add extra frames under
> MPlayer. It doesn't allow you to add frames which would get displayed
> properly.

ok, ill explain it again, the frames MUST be added as the next filter NEEDS
them its not possible to not generate them
again as i said the example is yadif (doubles frames), mcdeint (uses all
frames for motion estimation and compensation ) and framestep to discard
every second frame again
you could of coarse not generate any flip is any filter ever but that also
would make the half working double framerate filters non working, IMHO
theres no advantage in doing this until we have a better solution in place

btw, in what case exactly does the "not even a dirty solution" break
something which was working before it?


> 
> >                   another would be to move the timing & flipping code to the
> > vo where it IMHO belongs to, then a vo could decide to either flip in a
> > hardware interupt handler, by a seperate (realtime/high priority whatever)
> > thread, a simple sleep until X in case the vo is out of buffers but a new
> > empty buffer is requested or a flip on vsync if the vo supports that
> 
> Doing vo-specific timing might perhaps be a good idea for other reasons,
> but it's not really a solution to the frame-adding problem either. If
> you only change the part after the filter chain, all final frames from
> the chain corresponding to one input frame would need to be complete
> before the filtering call returns. That could be quite suboptimal in
> case of several added frames.
> 
> My current idea for a frame-adding implementation is to allow filters to
> indicate before returning that they want to produce more output frames
> before getting new input. Then the next time the MPlayer main loop wants
> to produce a new output frame it calls the registered "more frames from
> this point" function in the filter instead of starting the chain from
> the beginning.

ive no objections, and i hope it will be as easy in practice as your
description of it :)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is