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

[Reimar Döffinger]

On Sun, Feb 28, 2010 at 12:34:28PM -0500, Jason Tackaberry wrote:
> On Sun, 2010-02-28 at 18:16 +0100, Reimar Döffinger wrote:
> > That depends (mostly) on the graphics hardware.
> > xv and gl are generally limited to around 2048x2048, I have tested gl2
> > to work fine with 3840x2160 - in theory it should be "unlimited".
> 
> We could force the application to run -identify on the files in the
> playlist beforehand, and setup a shm buffer large enough to accommodate
> the largest overlay.

I don't know the details of the code well enough, but an alternative would
be that the application creates a buffer with any size it wants.
If MPlayer fails to open the buffer with the size it needs, it will open
it with the minimal size it requires and write the value it needs somewhere,
then going back to trying to open it with the size it requires.
(of course it also has to handle the case that the buffer itself is large
enough, just the layout within is wrong, too small or too large stride).

> Your alternative suggestion (MPlayer creates the buffer but the
> application destroys it) is a bit cumbersome, because what if a
> subsequent file requires a new buffer?  In that case, MPlayer will
> destroy the old one and create a new one.  So then the design would be
> that MPlayer creates and destroys all buffers except for the last one,
> which is the app's responsibility.  That's very sloppy, IMO.

If you describe it like that, yes.
I would have described it as "the application create and destroys the buffer
(since it knows the required live-time) whereas MPlayer resizes the buffer
(since it knows the required dimensions)".
Of course it is much uglier in practice since SHM does not have a concept of
"resizing".