[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 #21 from Sebastian Dröge <slomo at circular-chaos.org> 2013-06-06 07:09:34 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > > > that does not
> > > > pull in any of the complex and large code of gst-plugins-gl but properly
> > > > interoperates with that.
> > > 
> > > This point and the previous point seem to contradict each other.  If you're
> > > going to support all the GL implementations within one element, its gonna be
> > > hairy :).  The only files (in gst-libs) that do not get used with glimagesink
> > > are the gl baseclasses (filter and mixer) and I can't think of what you can
> > > remove.
> > 
> > Ok, fine then :) There's just all this threading complexity that is not really
> > needed for a simple sink.
> 
> The threading complexity is exactly the same as with eglglessink.  You have a
> single gl thread + all the gst element threads and all gl activity happens in
> the gl thread.  Without it, ... ! glfilter ! queue ! glimagesink would blow up
> (I know there are GL extensions to work around/facilitate that (and EGLImage)).
> 
> 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?


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.