[Bug 797010] New: vaapipostproc: implement the negotiation of

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 797010
Summary: vaapipostproc: implement the negotiation of
memory:DMABuf in sink pad
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@igalia.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---

In order to import tiled buffers vaapipostproc should negotiate memory:DMABUf
in its sink pad

For more information see:

https://lists.freedesktop.org/archives/gstreamer-devel/2018-August/068973.html

["GStreamer" (GNOME Bugzilla)]

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

Julien Isorce <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

["GStreamer" (GNOME Bugzilla)]

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

Ivan Fedotov <***@yandex.ru> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@yandex.ru

--- Comment #1 from Ivan Fedotov <***@yandex.ru> ---
Created attachment 373508
--> https://bugzilla.gnome.org/attachment.cgi?id=373508&action=edit
Patch. Adds DMA buffer input pad type to gstvaapipostproc.

Hello. We wrote a patch that allows the vaapipostproc plugin to accept input
data in the DMABuf format. Is it possible to add it to the repository in the
future?

["GStreamer" (GNOME Bugzilla)]

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

Nicolas Dufresne (ndufresne) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ndufresne.ca

--- Comment #2 from Nicolas Dufresne (ndufresne) <***@ndufresne.ca> ---
I'd like to hold on this effort until we get a clearer view on Intel on how to
address the issues cause by the implicit usage of modifiers. As it is now,
these DMABuf cannot be imported anywhere else then into another VAAPI component
using the same GPU. This unfortunate design decision breaks random use cases.

["GStreamer" (GNOME Bugzilla)]

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

Eugen Klim <***@yandex.ru> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@yandex.ru

--- Comment #3 from Eugen Klim <***@yandex.ru> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #2)

Post by "GStreamer" (GNOME Bugzilla)
I'd like to hold on this effort until we get a clearer view on Intel on how
to address the issues cause by the implicit usage of modifiers. As it is
now, these DMABuf cannot be imported anywhere else then into another VAAPI
component using the same GPU. This unfortunate design decision breaks random
use cases.

Isn't it better then nothing? Personally I need this not to send dmabuf
anywhere, but to transform DMABuf into VASurface without unnecessary copying.
Again, GL already *does* export DMABuf, this fix only adds the possibility of
accepting DMABuf to vaapipostproc. This is unfortunate that gstreamer could not
ensure that vaapi and GL are using the same device, but I do use them on the
same device and I don't want to copy memory twice from and to GPU.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #4 from Nicolas Dufresne (ndufresne) <***@ndufresne.ca> ---
Feel free to manage your own copy for you own needs. I'm just trying to do my
job of making sure we have an answers for the general use cases. I can show you
screenshot of what sad users will see when they hit that issue, it's not
viewable.

These is problems in the DMABuf support design inside VAAPI, and we need to
find a way to prevent these from breaking video playback on random people
machine, or to get that fixed by the VAAPI folks. If it's not you carrying
this, it will need to be someone else.

A typical user is a PC owner with NVIDIA + Intel Accelerator. It is quite
possible this user will want to use Intel VAAPI, because NVDEC isn't shipped by
distro, combined with their fast NVIDIA GPU. With Intel implementation of
DMABuf, this does not fail, but does not render anything viewable.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #5 from Nicolas Dufresne (ndufresne) <***@ndufresne.ca> ---
So, I had a bit of time to look around, Vaapi gained support for this by
introducing VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_2. We should port all DMABuf
exportation usage to that. There is a new export method, which will provide the
modififers. Then we can in a first place fail the export if there is a
modififers and eventually expose the exported buffers with the modifiers. On
the VPP side, I bet we can influence the modifiers that will be used somehow, I
haven't search yet.

["GStreamer" (GNOME Bugzilla)]

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

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement

["GStreamer" (GNOME Bugzilla)]

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

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #6 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/105.