[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 #22 from Matthew Waters <ystreet00 at gmail.com> 2013-06-06 11:57:07 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > The way I see it, you have a simple sink that is slow across queue's because it
> > has to upload/download the image data or you add a little bit of complexity to
> > avoid hitting a very slow path (that could be avoided).
> 
> Yeah you need a thread in any case in the sink to separate all the GL work from
> anything else (and also for another reason, that later). But what you don't
> always need is magic to dispatch processing into that GL thread (as you only
> can do GL stuff in that thread), e.g. when using EGLImage or just upload normal
> memory as a texture. But yeah, overall I agree.
> 
> What exactly is it that you pass between elements, e.g. between a GL filter and
> sink? Texture IDs plus a way to dispatch work into the actual GL thread? Who
> owns this thread, who starts/stops it?

Well, essentially everything is passed at the moment using GstGLDisplay.  The
essential stuff is the gl api we're using (GL, GLES, and the version (can be
parsed from glGetString)), the marshalling stuff and some way that elements can
call GL. At the moment, there is a function table that elements use for calling
GL that is filled at context creation time.  The reason that exists is because
it is essentially impossible to link to both libGL and libGLESv2 (some of the
exported symbols are the same) and technically on windows the function pointers
are context specific so we grab the function pointers at runtime.

The thread is created within GstGLDisplay at the moment which is created by the
most downstream element that supports creating the context/thread. So that
means glimagesink unconditionally creates the thread.  In this pipeline:

... ! glfilter_a ! glfilter_b ! ximagesink

glfilter_b would create the context and glfilter_a would query it from _b.

No-one really owns the context, it is created and destroyed with pad
(de)activation.  When an element is done with the context, it explicitly loses
its ref.  Each element keeps track of the GL objects so there is no need for
GstGLDisplay to.

> The other reason for having another thread is that you ideally want this thread
> to only display something every vsync. So you would just loop there forever in
> vsync intervals and always just render the frame that is to be rendered at this
> very moment (and of course do all other work asap, like uploading memory to
> GL). Which could mean that for a 120fps stream you skip approximately every
> second frame, or for a 20fps stream you render every frame multiple times.
> Currently this is not implemented anywhere public, but that's how video sinks
> should really work.
> 
> 
> Oh and also see gst-plugins-base/gst-libs/gst/video/gstvideometa.h for the
> GstVideoGLTextureUploadMeta.

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