[MPlayer-dev-eng] [PATCH] DeckLink video output

[Uoti Urpala]

On Tue, 2009-08-18 at 00:20 +0200, Georg Lippitsch wrote:
> Am Monday 17 August 2009 22:40:30 schrieb Reimar Döffinger:

> > > +static int get_space(void)
> > > +{
> > > +    return 38400;
> > > +}
> > > +
> > > +static float get_delay(void)
> > > +{
> > > +    return 0.0;
> > > +}
> >
> > At least in some cases this combination is going to cause severe
> > issues. E.g. with audio only files it might cause an extremely high CPU
> > usages (e.g. 40% instead of 0.5%).
> 
> Audio only files won't work at all, as stated above.
> 
> > Unfortunately I do not remember the details.
> 
> These would be interesting, since I tried a lot of values for get_space.
> Large values (>65kb) made mplayer hang, small values gave broken sound.

You're supposed to return the amount of space you actually have free in
your output buffer, not a constant. The hang probably occurred because
your driver first requested a lot of data, then refused to accept it
because buffers were already full.

> > There is also the issue that A-V sync will not be remotely good without
> > an accurate get_delay.
> 
> The video card does all timing, AFAIK the dxr2/3 drivers do it in the same 
> way. A-V stays in sync because the same amount of time for audio and video is 
> buffered.

Note that some existing drivers are broken in various ways; it's not
really safe to use anything except maybe xv and gl as examples.

> What I wanted to achive with this, is to disable mplayers internal timing and 
> let the card do that. What is the best way to achieve this? The video driver 
> has to return "VFCAP_TIMER" in query_format, but for the audio driver I 
> didn't find anything comparable.

Doing that in the video driver should be enough to make the main MPlayer
code not sleep itself. Note however that that output mode is a marginal
corner case which is of no interest to most users and is not really
guaranteed to work.