[Bug 776927] gl: gldownload: convert GstGLMemory to GstDmaBuf

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=776927

--- Comment #24 from Matt Fischer <mattfischer84 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #23)
> Please use GST_CAPS_FEATURE_MEMORY_DMABUF, this way we are sure there is no
> typo.
> 
Will do.

> You need to check if downstream supports GstVideoMeta. If not, you may check
> (option) that the list os strides and offsets matches the default set to
> GstVideoInfo when doing gst_video_info_set_format(). If that does not match,
> dmabuf exportation is not possible, return NULL.
> 
How does one check if downstream supports a given meta?  I was under the
impression that you just attached whatever meta you wanted, and hoped that
downstream paid attention to it.  Since I am already relying on there being a
GstVideoMeta on the incoming buffer, I had thought that it would be safe to
assume that I could just create one on the outgoing buffer as well.

> I think it's a good case were using a goto would be more readable.
> 
Will do.

> We have function tables already, so you don't endup doing get_proc_address()
> every image plane.
> 
I'm not sure I understand what you're asking me to do here.  Can you clarify?

> Why ? What's the problem ? and why checking this so late ? We already
> support multiple FD when importing. I don't think this is very useful if you
> limit this to packed formats.
>
This is just a comment about multiple planes within the dmabuf export.  A
planar image will have multiple GstMemory objects, each of which will get its
own EGLImage and its own dmabuf.  See the loop in _try_export_dmabuf() to see
how it will loop for multiple planes.

As far as I understand, that will correctly handle the planar cases.  If we try
to handle the case where each of those individual EGLImages also exports
multiple dmabufs, I wasn't clear how we would handle the N * M dmabuf handles
that would result.  Can you comment on what we ought to do in that case?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.