[MPlayer-dev-eng] [PATCH] VF Overlay
tack at urandom.ca
Mon Mar 1 16:38:46 CET 2010
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
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
Another possibility is to remove the shmkey arg from the vf, and create
a new slave command:
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
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
5. MPlayer attaches to the shm segment at key 123456, converts the
BGRA overlay to YV12(A) and unlocks the buffer, then starts
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
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?
More information about the MPlayer-dev-eng