[Bug 739681] GstGL: let applications use the glimagesink's output texture

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Matthew Waters <ystreet00 at gmail.com> 2014-11-06 01:07:19 UTC ---
(In reply to comment #2)
> About the "last-sample" property it is actually more similar to what I suggest.
>  Also it makes not easy to tell glimagesink to use surface-less context
> (http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/egl/gstglcontext_egl.c#n419).
> It would require another property to setup that.

It probably makes sense to create a glappsink in order to seperate out the
GstGLWindow usage.

> And having an action signal would make it possible to define our own parameters
> and a return value.
> For example the user will have to connect them before starting the pipeline.
> Otherwise we will return false or something.

Or we just wait for the buffer to be consumed?  Whatever appsink does probably
makes sense.

> We could also check that the user triggers the signal from where the gl app
> context is current, just to prevent him doing something wrong.

Might be easy to do with the current API, or it might require tracking
GstGLContext's in a GPrivate.

> We could also call "gst_video_gl_texture_upload_meta_upload" internally in this
> action. So that it makes the user life easier. i.e. forward the
> "gst_video_gl_texture_upload_meta_upload" parameters directly to this action
> signal.

I'm actually working on making GstGLUpload output different buffers based on
the input/output caps.  So that one can select that you want GLmemory filled
buffers or EGLImages or GLUploadMeta or GL_TEXTURE_EXTERNAL or whatever we come
up with.

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