[Bug 743242] New: gl: texture targets in GstGLMemory

[GStreamer (bugzilla.gnome.org)]

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

           Summary: gl: texture targets in GstGLMemory
    Classification: Platform
           Product: GStreamer
           Version: git master
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: ystreet00 at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


So currently there's a problem of various zerocopy paths (avf, android amc,
dmabuf, etc) requiring different texture targets to the nominal GL_TEXTURE_2D.

Pretty much every texture target is used by at least one zerocopy path and so
we require support in at least gstglupload/gstglcolorconvert to convert from
these targets to GL_TEXTURE_2D (or allow passthrough so the element/application
can handle it).

For signalling this information between elements, I was thinking of three
options.
1. add the required field to GstGLMemory and have everyone deal with it.
(requires changing the world at once and is not backwards compatible at all)
2. add a new extra field in the memory:GstGLMemory caps say gl-texture-target
(requires extra code to parse the extra field out of the caps that is not
handled by gst_video_info_{to,from}_caps().  if the field doesn't exist,
default to _2D)
3. A new meta solely to hold the texture target/s (simple, if it doesn't exist,
default to _2D). (Open question should the target in the meta refer to entire
buffer or be per memory according to gst_buffer_peek_memory (buf, i))

Ideally I would eventually like 1, then 3, then 2.

Any other ideas?

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