[MPlayer-dev-eng] sharedbuffer vo?
wm4
nfxjfg at googlemail.com
Wed Oct 30 21:33:36 CET 2013
On Wed, 30 Oct 2013 20:20:18 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Wed, Oct 30, 2013 at 01:10:13PM -0600, Kevin DeKorte wrote:
> > Hi,
> >
> >
> > I was noticing that in the corevideo code there is a shared buffer
> > option. That made me wonder if a generic shared buffer vo would be
> > useful. The reason I am asking this is that as display servers move to
> > wayland we lose the -wid option in mplayer (or at least we appear to
> > be at the moment). So how will applications like gnome-mplayer or
> > smplayer work on wayland without X?
>
> Wayland could work harder to be compatible?
AFAIK Wayland can pass GPU surfaces to other processes very easily.
It's what it was made for. But there doesn't seem to be X-like nesting
of windows. (Although it should work within the X emulation?)
> > If we were to use something like the shared buffer perhaps that would
> > work on newer display servers without reverting to the X11 layer.
>
> It will still offer bad performance and we will have to either
> drop all the features that e.g. vo_gl offers (in particular, scaled
> subtitle rendering) or re-implement it in each and every frontend.
> There is an alternative: EGLStream
> http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream.txt
>
> Problems:
> 1) It's still messy/a good bit of effort
> 2) It's EGL only so far. I expect both wayland and GLX would need to
> be extended with support for it/something similar.
There are other methods of transferring GPU surfaces from one process
to another (Chrome made it work on all 3 desktop platforms, win32, X,
OSX!), but they're all awfully platform-specific.
I expect this would have to be implemented sort of like backends in
vo_gl, and the client application would still have to worry about
presenting the received buffers.
More information about the MPlayer-dev-eng
mailing list