[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 #34 from Sebastian Dröge <slomo at circular-chaos.org> 2013-06-10 10:47:53 UTC ---
(In reply to comment #33)

> > 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.

And your plan is to make it the same for all backends?

> > > 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.

Once it's merged in -bad, I'll make it work on Android :)

> > 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.

Any comments on the shaders and also the Meta support would be appreciated, I'd
like to learn :) Same goes for questions about how it works currently in
eglglessink (which I really like to get rid of in favor of a great unified GL
sink).

> > 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.

How is it negotiated between the elements other than the ALLOCATION query? And
do you plan to have the same pool for a chain of GL elements in the future?

-- 
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.