[Bug 765435] plugins: rework dmabuf import

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #4)
> (In reply to sreerenj from comment #3)
> > BTW, so no plan to implement dmabuf-capsfeature ??
> 
> The agreement is try to avoid it if we can unless we find a use-case were it
> is unavoidable.
> 
> Just as memory:VASurface capsfeature, I feel it is "avoidable" (removable)
> too ... hehehe...

Yes In theory :), we could have avoid "memory:VASurface" negotiation too and do
like dmabuf strategy. Like dmabuf, VASurface is mapable unless the Surface is
encrypted. Currently vaapidecode already checking whether the surface is
mapable or not by doing vaDeriveImage. If we didn't get the surface
format then it is encrypted so we are setting(are supposed to set)
"memory:VASurface, format=GST_VIDEO_FORMAT_ENCODED".

In future we can may be change like:
-- always use raw format , SystemMemory caps features
-- set "memory:VASurface" as capsfeatreus only if unmapable/underiveable
(encrypted)

But IIRC, the decodebin logic to autoplug the hw accelearated elements were
based on the number of capsfeature count supported by the element,
non-systmemroy-capsfeature etc.

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