[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 #28 from Sebastian Dröge <slomo at circular-chaos.org> 2013-06-07 09:37:36 UTC ---
(In reply to comment #27)
> (In reply to comment #25)
> > (In reply to comment #24)
> > 
> > > > So how exactly is data-flow between two GL elements happening? How is the
> > > > upstream GL element passing it's stuff to downstream?
> > > 
> > > GstGLMemory + GstGLBufferpool.
> > > 
> > > GstGLMemory holds one rgba texture id.  It also allows non-GL elements to read
> > > and write to a data pointer that is up/downloaded as needed.  Where the element
> > > wants the image data and whether it needs up/downloading is based on the map
> > > flags _READ, _WRITE and _GL.
> > 
> > That sounds like a good solution, yes. Do you also have support for other color
> > formats, especially YUV? Or only for uploading/downloading maybe?
> 
> At the moment the YUV formats supported are I420, YV12, YUY2, UYVY and AYUV
> which is implemented using glsl shaders (in GstGLUpload).

Also in the downloader and the sink? Are the uploader/downloader required as
elements are transparently used inside the filter/etc elements?

> > How would this integrate with EGLImage or things like vaapi (which implements
> > the GstVideoGLTextureUploadMeta)?
> 
> Well, I haven't really had too much of a look at those but my first thoughts
> are that GstGLMemory would be a fallback and elements should look for other
> things first (like EGLImage and TextureUploadMeta) using caps features.

Makes sense, yes.

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