[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
For the other way aruund:

  ... ! vaapidecode ! glupload

This seems to be a case where you would maybe need to make a decision about
what is best. And the answer is probably quite arbitrary, why would
GLUploadMeta be slower or faster then DMABuf ? This is an example of case where
I would not know. Correct me if I'm wrong, here's what I believe the
negotiation should be (I'm ignoring the VideoMeta aspect):

  Query downstream pool (allocation query)
  If downstream buffers from that pool can be zero-copy imported ?
    Use this method,
    (downstream pool could be giving DMABuf, or pool could be of a known type)
  Else, you have two choices
    a) Push VASurface
    b) Push DMABuf

If I remember, VASurface are already negotiated using caps. So choice a) can be
decided already. Normally the choice shall be evident, unless you have
non-mappable DMABuf, which is a very unfortunate type of DMABuf imho. That
being said, maybe memory:DMABuf is only needed when downstream can import
DMABuf and upstream produce non-mappable DMABuf ? Is that an actual use cases
introduced by VAAPI ? DMABuf in V4L2 are always mappable (at least for now,
there is discussion to introduce a security mechanism, so permission to map
could be controlled in a way one process (like your compositor) could be
allowed to map the data, while another would not (for DRM purpose apparently).

Does that seems like a plausible solution and a good description of what
memory:DMABuf would be used for ? (announce that downstream can import DMABuf)

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