[Bug 677012] gst-plugins-gl: Port to GStreamer 1.0

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=677012
  GStreamer | gst-plugins-gl | git

--- Comment #33 from Matthew Waters <ystreet00 at gmail.com> 2013-06-10 10:42:19 UTC ---
(In reply to comment #32)
> (In reply to comment #15)
> 
> > What doesn't work:
> > 1. interoperability with any of the other GL/VAAPI/VDPAU/... plugins (we fall
> > back to the slow download/upload. maybe GstVideoGLTextureUploadMeta and its
> > non-existant download counterpart? or meta transforms ?)
> 
> GstVideoGLTextureUploadMeta + potentially specific support for some things,
> especially EGLImage if EGL is used.
> 
> > 2. marshalling based on GMainContext in all backends.  Currently only the
> > wayland backend has it.
> 
> What does this mean? Does it *depend* on a main loop running on the default
> main context, or does it have its own main context where it runs a loop in some
> thread and there does the marshalling? And it's only implemented for Wayland so
> far, and not existing for other backends?

The GstGLWindow (where the context-specific stuff happens) has its own mainloop
that is used for marshelling.  Yes, only the wayland backend has it, the others
rely on platform specfic code.

> > 6. GL + GLES (it may never)
> 
> You mean using GL and GLES in the same process and having GL elements
> interoperate with GLES elements? Interesting idea but that really sounds
> complicated... and not that important? ;)
> 
> > 7. libvisual (waiting on GstAudioVisualizer)
> 
> What's missing there?

To be honest, I haven't had time to look at that.  However last I looked
GstAudioVisualizer explicitly mapped the output buffer, not giving us the
chance to say we wanted the data on the GPU.

> > Unknown:
> > 1. the cocoa backend (it works with GNUStep, no idea about OSX)
> 
> And an EAGL backend for iOS :) What about the backends for WGL, EGL and GLX?

WGL and GLX work fine.  EGL works under x11, I haven't really tested anywhere
else.  I had a brief stint at getting it to work with android but ran into
issues getting the libraries to link properly.

> Also, what about support for GstVideoMeta (i.e. arbitrary strides) and
> GstVideoCropMeta? You can steal some code for that from eglglessink (and
> GL_UNPACK_ROW_LENGTH probably is of use here too). You can probably also steal
> some YUV conversion shaders from eglglessink (I think more formats are
> supported there and they're also a bit more optimized, at least last time I
> looked).

GstVideoMeta and GstVideoCropMeta are unsupported at the moment.  I have eyed
off those shaders.

> Do the GL elements handle ALLOCATION queries properly, i.e. sharing the GL
> memory allocator and potential pools with each other through that query?

Nope. One pool between each pair of elements at the moment.

> I asked others on IRC and it seems having the GL stuff in gst-plugins-bad would
> be a good idea. Giving more visibility and after feature-equality we can get
> rid of eglglessink.

Sounds good.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.