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

[Uoti Urpala]

On Fri, 2006-06-23 at 14:36 +0200, Michael Niedermayer wrote:
> mplayer design if i understand it correctly is:
> 1. decode frame
> 2. send though filter chain (this can lead to an arbirary number of frames
>    0-n being sent to the vo)

The filters which send the flip event directly were meant for MEncoder
use only and were not even meant to work under MPlayer when they were
implemented as far as I understand it. So the "-n" part is not really
"MPlayer design".

> 3. sleep
> 4. send flip page to vo from mplayer.c
> 
> 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.

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