[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 #35 from Matthew Waters <ystreet00 at gmail.com> 2013-06-10 11:00:31 UTC ---
(In reply to comment #34)
> (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?

Yes.  It will hopefully make the marshalling code more consistent.

> > > > 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 :)

Cool :)

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

Will do.

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

It does use the allocation query, it just doesn't pass on the pool between
multiple elements.  It probably could though.

(In reply to comment #32)
> (In reply to comment #15)
> > 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? ;)

Correct, however choosing between GL and GLES via an env variable is on the
radar.

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