[Bug 779145] dmabuf export from vaapi encoders fails

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Scott D Phillips <scott.d.phillips at intel.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #5)
> Review of attachment 346591 [details] [review]:
> 
> I have just tested the patch with this pipeline 
> 
> gst-launch-1.0 v4l2src io-mode=dmabuf-import ! vaapipostproc ! vaapisink
> 
> And surprisingly it works (it's an integrated camera in my laptop).
> Honestly, I didn't expect it.
> 
> I said this, because sometime ago, Julien wrote another approach to this on
> commit 1dbcc8a0e199f2da6a0ab8e949f13341916128a3 and I had to revert it
> (commit 7472826a3633d803d55def32dee58eb8d318e3ae) because it leaked file
> descriptors. But with your patch there is no leakage.
> 
> Said this, in my opinion, the correct patch should be aligned the Julien
> approach because we could avoid this gst_vaapi_buffer_proxy_release_data()
> call.

I think, boiling it down, what we need to do right now in all cases is:

DeriveImage
AcquireBufferHandle
dup(fd)
ReleaseBufferHandle
DestroyImage

There's no need to have an object tracking the lifetime of the buffer or the
image because we know we always want to nuke them right away when getting a
dmabuf fd. So maybe it would be better to add a method to VASurface:

gint gst_vaapi_surface_get_dmabuf_fd (GstVaapiSurface * surface);

that does those steps. Then the only thing missing is what I mentioned above,
the promise in VA-API that the dambuf fd will refer to the VASurface's storage
as long as the surface lives.

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