[MPlayer-dev-eng] [PATCH] vf_osd: OSD filter for MPlayer

[Jason Tackaberry]

Hi,

The attached patch implements a filter that provides an OSD buffer to an
application controlling MPlayer in slave mode.  The features and
interface is similar to the OSD of the Hauppauge PVR-350 and likely
other hardware.  Taken from the documentation (included in the patch),
here is a brief feature overview:

   * Image buffer stored in 32bpp BGRA.
   * Supports both per-pixel alpha and global alpha.
   * Compositing is MMX accelerated and performs quite well.  On a 2GHz
     Sempron, it is possible to overlay a translucent video on the OSD
     with no frame loss in either video (and with 20% CPU to spare).  For
     an OSD buffer that is not changing, vf_osd can composite an 800x600
     OSD at 24 fps with about a 7% CPU usage overhead (on the same 2GHz
     CPU).
   * Fixed OSD frame rate (of about 30 fps) regardless of the video frame
     rate or whether the video is paused.
   * OSD buffer accessible over shared memory.
   * OSD controlled via slave commands, rather than a fifo.
   * OSD state maintained across 'loadfile' commands.
   * A slice region can be defined to limit what portion of the OSD
     buffer is drawn.  (This will improve performance for an OSD with
     little content, such as a line of text.)

vf_osd is similar in concept to vf_bmovl (insofar as it allows an
external application to overlay an image onto a running MPlayer video),
but differs considerably in its interface and features.  (Most notably
that vf_osd is controlled by a slave command, rather than by
constructing a separate fifo.)  vf_osd is also significantly faster than
than vf_bmovl, even for the non-MMX case.  Updating bmovl for these
things would basically mean rewriting it anyway.

A screenshot demonstrating vf_osd in action is here:

   http://sault.org/~tack/vf_osd.jpg

Note the X2 image in the lower left corner is actually a running video,
rendered translucently on the OSD.  (Another MPlayer instance is playing
X2 using another filter called vf_outbuf that copies the video to
another shared memory buffer.  I'll submit vf_outbuf at a later date.)

vf_osd will be used by Freevo and also my project, MeBox.  The obvious
use-case is to display information about the video or other events (say
the user wants to be notified on the OSD of new email).   vf_osd could
also be used to render full interface elements such as menus.  Suppose
the user wants to toggle deinterlacing at runtime.  (Ignoring the fact
that MPlayer can't do this [yet].)

  http://sault.org/mebox/images/livetv2.png

The above screenshot shows a possible OSD interface.  (This was built
using vf_bmovl2, which I had submitted here last year.  vf_osd succeeds
vf_bmovl2.)

The patch includes documentation with a short, trivial example in Python
demonstrating how to draw to the OSD.  vf_osd has been tested and
compiles cleanly on x86 and x86_64.

Comments and criticisms welcome.  Because one requirement of vf_osd is
that it be usable even while the video is paused, and also that the OSD
can be updated at a rate independent of the framerate of the current
movie, there are some changes in mplayer.c that might be considered
disruptive.  I've done extensive testing on multiple systems and haven't
observed any negative side-effects.  But obviously this is what the
review process is for.

I and the Freevo developers (and users, no doubt!) would quite like to
see this in MPlayer.

Cheers,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_osd-2005-07-17.diff
Type: text/x-patch
Size: 43912 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050717/3b724dcc/attachment.bin>