[MPlayer-dev-eng] [PATCH] VFCTRL_PERIODIC_UPDATE

[Uoti Urpala]

On Thu, 2007-01-11 at 10:07 -0500, Jason Tackaberry wrote:
> There are a couple mistakes, but that statement is harsh, and if it sets

OK I could have phrased it it nicer, but still the patch did contain a
lot of errors for such a short one.

> > If you're trying to show video with good timing in the overlay then
> > there should be a proper timing mechanism for it instead;
> 
> That is a goal, yes.  What would you suggest as a proper timing
> mechanism?

Either timing done in the MPlayer process according to timestamps in the
input or at least non-polling timing triggered from outside.

> >From your later email ...
> 
> > What's the intended use case for the filter?
> 
> For my purposes, the intended use-case of VFCTRL_PERIODIC_UPDATE is
> vf_overlay, which I described in my original email.  The idea is to

> But basically any controlling application that wants to overlay an
> arbitrary image (with alpha blending) over a video will benefit from
> vf_overlay.  Another goal is to provide picture-in-picture.  We are
> using it in the Freevo project.

Your earlier mail already said it was going to be used as part of
vf_overlay implementation; what I meant to ask was how vf_overlay would
be used (I asked for use case "for the filter"). When would you want to
show 30 FPS video in the overlay? If you'd use it to show another stream
as picture-in-picture then what would decode the other stream, and
should that really be done in another process? Or if you decode it in
the same MPlayer process then you could probably also time the frames
better in it.

> > Well, quite bad for what? For displaying smooth video or low-latency
> > interactive content maybe, but if those are desired then IMO the
> > implementation should not be polling-based to begin with (and possibly
> > the whole idea of using slave mode from another process is
> > questionable for those).
> 
> Maybe not.  But the idea here is to get this functionality with minimal
> disruption to mplayer's core.  It's easy to say that if shouldn't be
> polling-based, but I suspect to do it "the right" way would require a
> far more intrusive change that have even less chance of getting
> merged.

Avoiding the polling should be reasonably easy. If the timing is
generated by the filter in the MPlayer process then it can return the
time it wants to wake up rather than wait to be polled again. If it's
generated by the controlling process then instead of changing the sleep
timings change the sleeps to use a select-based sleep function that can
be woken up by writing to an fd.