[MPlayer-dev-eng] [PATCH] VFCTRL_PERIODIC_UPDATE

[Jason Tackaberry]

On Fri, 2007-01-12 at 03:44 +0200, Uoti Urpala wrote:
> 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.

The purpose of vf_overlay is to allow a controlling application, such as
Freevo, to layer an arbitrary overlay on a video.  This overlay could
contain OSD information (where the OSD would be rendered according to
the Freevo's current theme), menus and other interface elements, or
another running video (for picture-in-picture).

The goal here is to be generic.  We don't enforce any policy about what
can be rendered or when (within the upper frame rate constraint that
is).  If you can stuff it into a BGRA buffer, vf_overlay will blend it
over the video.

A video playing on the overlay (in the picture-in-picture example) is
managed by the controlling app, and could be rendered using another
mplayer instance (via another filter, vf_outbuf, which is similar to
af_export, and which I would like to submit later should I manage to
survive this first round).  It could also be rendered using Xine.

This isn't vaporware stuff either.  This has been working for well over
two years (mplayer playing a video on xine's overlay, or xine playing a
video on mplayer's overlay), and it performs pretty well.  So this
stuff, while it may not be perfect, is fairly baked.


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

Timing is controlled by the application.  The filter doesn't know it
needs to update the overlay until the app controlling mplayer in slave
mode issues the relevant slave command.

How about we create a small function in input/input.c that selects on
the input fds.  This way any slave command (particularly one to control
the overlay) would wake mplayer so it can call periodic_update().
Something like a stripped down version of mp_input_read_cmds() that just
selects on the input fds, or perhaps just the one used for slave
commands (is it always stdin?)

Cheers,
Jason.