[Bug 793707] msdk: Add dmabuf support in msdk plugins

[GStreamer (GNOME Bugzilla)]

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

--- Comment #17 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Hyunjun Ko from comment #14)
> (In reply to sreerenj from comment #11)
> > This one adding only "dmabuf-export" right? Please change the bug report
> > title then.
> > We need the "dmabuf-import"(in msdk plugin) for v4l2 use case, better file a
> > separate bug for that.
> 
> I'm not sure how to implement dmabuf-import in msdk elements.
> Because it should create a VA surface when it gets dmabuf handle from
> upstream but, by design, allocation should be done at initialization time in
> msdk.
> 
> Any idea to handle this?

Currently, the decoder is doing in Init() in decide_allocation(), we should do
the same in encoder. Delay the Initialization until propose_allocation() so
that you will get a handle of v4l2src proposed pool. 
Then we may be able to do pre-allocation of buffers within msdk element, grab
the dmabuf ids from the memory and use it for mfx/vaSurface allocation.

But I'm not sure whether v2l4src has other constraints on buffer allocation
like it "has to be done at a specific point after downstream pool negotiation"

> 
> I think we should achieve the dmabuf-import in v4l2 case fist. As you know,
> there've been discuss in bug #792034.

V4l2 always prefer "dmabuf-export" (Nicolas well explained the reasons in the
other bug reports) .
BTW, v4l2 "dmabuf-import" has been set to userptr unless I am mistaken. 
Which means MSDK-"dmabuf-export" is a mandatory feature for zero copy camera
encode.

> 
> By the way, I don't have permission to edit this bug :)

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