[MPlayer-dev-eng] [PATCH] VF Overlay

[Jason Tackaberry]

     I. On Sun, 2010-02-28 at 18:59 +0100, Reimar Döffinger wrote:
> Of course it is much uglier in practice since SHM does not have a concept of
> "resizing".

Right, which is what makes things complicated.  Of course, the only real
problem here is growing.  If the buffer is oversized it can still be
used.

Another possibility is to remove the shmkey arg from the vf, and create
a new slave command:

    overlay shm=123456

Which tells vf_overlay to start using the new shm buffer referenced by
the given shm key.

It might also be nice to formalize the overlay size by outputting
ID_OVERLAY=WxH.

So the sequence would then look something like, as an example:

     1. Controlling app spawns MPlayer: mplayer -slave -identify -vf
        overlay anamorphic-widescreen.avi 1080p.avi
     2. MPlayer outputs: ID_OVERLAY=854x480
     3. Application sets up a shm buffer sized 16+854*480*4 under shm
        key 123456, initializes its contents with some image, and sets
        the lock byte on the buffer to BUFFER_LOCKED.
     4. Application issues slave command: overlay
        shm=123456,invalidate=0:0:854:480:visible=1
     5. MPlayer attaches to the shm segment at key 123456, converts the
        BGRA overlay to YV12(A) and unlocks the buffer, then starts
        blending it.
     6. anamorphic-widescreen.avi ends and 1080p.avi begins.  The
        overlay is set to visible=0 (since the overlay configuration is
        wrong now) and outputs ID_OVERLAY=1920x1080.
     7. Application creates a new shm buffer sized 16+1920*1080*4 under
        shm key 654321, initializes it and locks it.
     8. Application issues slave command: overlay
        shm=654321,invalidate=0:0:1920:1080,visible=1
     9. MPlayer detaches from previous shm segment, and attaches to the
        new one at key 654321.
    10. Application destroys the shm segment with key 123456.
    11. After MPlayer outputs ID_EXIT, Application destroys the shm
        segment with key 654321.

In the case where the existing shm buffer is large enough to hold the
new overlay, the application wouldn't bother creating a new shm segment,
but would still need to redraw the image in the overlay (since its
stride will be different) and issue an invalidate/visible command.

If a subsequent video has the same overlay dimensions as the previous
one, ID_OVERLAY wouldn't be output and everything would just carry on
with the last buffer.

How does that sound?

Jason.