[Bug 797152] vaapidec: leak of dmabuf fds when transitioning from PLAYING to NULL state

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to Sakari Kapanen from comment #8)
> (In reply to Víctor Manuel Jáquez Leal from comment #7) 
> > Could you post a patch, removing that data release and run tests with it?
> Removing the data release broke the actual application I'm working on - no
> decoded frames could be received and displayed. So that doesn't seem to be
> the way to go at least.

Ok. That confirms the issue.

> 
> I'm not quite confident with writing a patch for this issue since the
> solution is not likely going to be as simple as removing the data release.
> Despite, it seems to me that the solution would be something along the lines
> of gstreamer-vaapi taking ownership of that dmabuf fd (since the VAAPI
> driver won't know about that handle or buffer anymore since the buffer is
> destroyed on VAAPI side by the data release call) and taking care of closing
> it later.

As far as I understand, the solution goes in a different directions. The usage
of vaAcquireBufferHandle() and vaReleaseBufferHandle() is being deprecated
because they hide details of the dmabuf required for negotiation, specially
with other devices (other GPU or so).

Check https://bugzilla.gnome.org/show_bug.cgi?id=779146#c55 for the replacement
of it.

Nowadays, only vaExportSurfaceHandle() works for... exporting... there's still
a need for importing handles onto surfaces API.

Anyway, the fix for this issue is to replace all the machinery for dmabufs for
pipeline downstream with this new libva API. This API is supported by Intel and
AMD backends.

Or more nicely, we should keep this logic only for old implementations of
libva.

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