[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Maybe we need to step back a bit. What do we need to negotiate ?

As of now, only glupload implements DMABuf in a usable way. What happens is
that glupload instrospect the incoming buffer and select method to "upload". If
a active method fails, it fallback to another one. Nothing in this scenario is
"negotiated", glupload simply react to the type of buffer that comes in. Often
the importation of dmabuf will fail for various reason, but in GL, there is no
way to check (hence negotiate) those before trying. This means, for the
glupload path to work, an upstream element need to produce dmabuf (a bit like
vaapi) and if thise dmabuf are not compatible, it will use a slow path. That's
also why, memory:DMABuf was of no use there.

I would like to know if VAAPI can achieve the very same thing. For upstream
element, like v4l2src, my opinion is that it should always produce DMABuf when
supported, end of the story. There was a bug with report, with patches, but the
patches were broken, and was later not updated. I'll see if I can make this
happen soon.

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