[Bug 779145] dmabuf export from vaapi encoders fails

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Scott D Phillips <scott.d.phillips at intel.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #9)
> Problem would be:
> 
>   VAAPI produce a dmabuf
>   glupload create a ELGImage and cache it (qdata on the GstMemory)
>   glimagesink renders (all fine so far)
>   The GstBuffer goes back to VAAPI
>   VAAPI replace the FD
>   glupload pick the cached EGLImage
>   glimagesink renders from the wrong FD
> 
> My take, if you need to change FD, just grab another GstMemory object.

Right, the way the VA-API is defined right now, this is exactly what you need
to do. The API doesn't make any promises about the stability of the underlying
storage of a VASurface. I think we're going to need to make some changes to the
promised behavior around dmabufs in the VA-API to get it to be a good citizen
where the importer doesn't need to re-import the dmabuf per-frame.

This is all based on the "letter of the law" in va.h, intel-vaapi-driver for
example isn't currently swapping around the underlying bo, so the dmabuf fd
happens to continue referring to the same VASurface. We just need to make this
explicit in the API. That will totally remove the need for swapping around the
fd in an FdMemory which turns out to be quite a bad idea.

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