[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #38 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
Finally I came back to this issue. Sorry for the delay.

I started to look at the fd (file descriptor) leaking when pushing to
downstream dmabuf-based buffers. It is because they are not released because of
commit 1dbcc8a0 (gstvaapisurface_drm: release image when done) destroys the
created derived image, thus, its fd is not marked as "allocated" by
va-intel-driver, thus vaReleaseBufferHandler() returns error and the fd is
never really released. This means currently there is fd leakage when the
vaapipostproc or vaapisink connects to a v4l2src with io-mode dmabuf-import.
IMO, we should revert that patch ASAP.

What I realize now is current vaapi dmabuf allocator is designed for upstream
use case, because it:

1\ creates a surface 
2\ creates a derived image from the surface
3\ gets the fd of the image with vaAcquireBufferHandler
6\ The dmabuf-base buffer is used upstream by v4l2src
7\ As the buffer is associated with a vaapi buffer meta, the surface can be
read (and read only, since no operation is allowed when Acquired)
8\ The vaReleaseBufferHandler is called with the buffer pool unrefs the
allocated buffers

But in the case of pushing dmabuf-based buffers to downstream, the logic is
different: we cannot acquire the buffer before writing on its surface, only
when all the processing is done and it is going to be pushed downstream.

1\ Process the normal VA Surface until is done (using vaapi surface allocator)
2\ call vaAcquireBufferHandler() on that Surface and get the fd
3\ Create a dmabuf-base gstbuffer and assing the fd
4\ Add a GstParentBufferMeta relation between the vasurface-based buffer with
dmabuf-based buffer and push the dmabuf-based buffer

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