After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744698 - VDPAU interoperability with GstGL
VDPAU interoperability with GstGL
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 561225
Blocks:
 
 
Reported: 2015-02-18 10:43 UTC by Julien Isorce
Modified: 2018-05-05 14:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vdpau: clean Makefile.am (1.95 KB, patch)
2015-08-10 14:22 UTC, Víctor Manuel Jáquez Leal
none Details | Review
vpdmpegdec: force GST_CAPS_FEATURE_MEMORY_VDPAU (1.24 KB, patch)
2015-08-10 14:22 UTC, Víctor Manuel Jáquez Leal
none Details | Review
Add gstvdpinterop element (19.60 KB, patch)
2015-08-10 14:22 UTC, Víctor Manuel Jáquez Leal
none Details | Review

Description Julien Isorce 2015-02-18 10:43:38 UTC
Use "GL_NV_vdpau_interop", i.e. vdpausurface to gltexture, to have   vdpauvideodec  ! glimagesink that avoids downloading/uploading the frame in between.

Mesa's Gallium3D drivers has VDPAU state trackers.
On ubuntu 14, you need to install libvdpau-dev and mesa-vdpau-drivers packages.

https://www.opengl.org/registry/specs/NV/vdpau_interop.txt
http://nouveau.freedesktop.org/wiki/VideoAcceleration/
Comment 1 Julien Isorce 2015-02-18 10:54:34 UTC
On ubuntu you may also need to install nouveau-firmware package as mentioned in link above.
Comment 2 Nicolas Dufresne (ndufresne) 2015-02-18 13:56:33 UTC
Note, I had this working in 0.10 (in some lost branch, probably on git.collabora.co.uk). Though I had some issue which prevented me from merging.

The display sink at the time was cluttersink, and there was no way to convince COGL that the external texture has been updated. My patches to workaround have never been reviewed. I think this is no longer an issue as we most likely target glimagesink which does not have this kind of optimization.

The second issue with VDPAU intereop, was that there is a race (at least on proprietary driver). Our scheme to track when a buffer/texture can be freed used to be (and is still I think) that we release the previous buffer when the next comes in. This didn't work with proprietary driver. Keeping 2 buffers would workaround, obviously a fence object is the right approach, no doubt. Fence for tracking texture life time is still a todo in libgstgl.

Let me know if you need these branch, the extension is very simple to use.
Comment 3 Nicolas Dufresne (ndufresne) 2015-02-18 14:20:55 UTC
This is the mentionned change to convince COGL to update the texture:

http://cgit.collabora.com/git/user/nicolas/clutter-gst.git/commit/?h=hw-accel&id=6f41850e442c5faf6140858f1da7f925f2b1af4c

This one is the implementation of the converter (in the ancient form of gl upload support:

http://cgit.collabora.com/git/user/nicolas/gst-plugins-bad.git/commit/?h=hw-accel&id=c81594423194375c45c3ce8125b3533d82c3fed6

And this was from a larger VPDAU branch (which is most likely 100% outdated now):

http://cgit.collabora.com/git/user/nicolas/gst-plugins-bad.git/log/?h=hw-accel
Comment 4 Víctor Manuel Jáquez Leal 2015-08-10 14:22:05 UTC
Created attachment 309011 [details] [review]
vdpau: clean Makefile.am
Comment 5 Víctor Manuel Jáquez Leal 2015-08-10 14:22:10 UTC
Created attachment 309012 [details] [review]
vpdmpegdec: force GST_CAPS_FEATURE_MEMORY_VDPAU

In order to test vdpinterop the output buffers have
GST_CAPS_FEATURE_MEMORY_VDPAU feature
Comment 6 Víctor Manuel Jáquez Leal 2015-08-10 14:22:16 UTC
Created attachment 309013 [details] [review]
Add gstvdpinterop element
Comment 7 Víctor Manuel Jáquez Leal 2015-08-10 14:33:29 UTC
WARNING: these patches are not for pushing, just a request for comments.

This weekend, moved by curiosity , I poke on this. It is a work-in-progress, and actually it does not work. Do not fail either:) ... and leaks as hell.

So far, my conclusions are:

* Since we need to keep tracking the output surface id and registered surface id, the GstGLMemory doesn't look enough, so the GLTextureUpload meta might be more natural.
* Perhaps a GstVdpContext might be a good idea.
* Perhaps a buffer pool of OutputSurface has more sense than VideoSurface
Comment 8 Julien Isorce 2015-09-11 04:35:00 UTC
Nicolas thx for the links and feedbacks I am sure this will help. Victor that's cool that you are looking at this.

You are right I think you should define a GstVideoGLTextureUpload callback.

Here is what I suggest:

You need first to port gstvdpoutputbuffer.c (renaming to gstvdpoutputmemory.c) and gstvdpoutputbufferpool.c to gst1.x

Define this GstVideoGLTextureUpload cb in gstvdpoutputbufferpool.c
And attach it to all allocated buffers.

Then gstvdpvideopostprocess.c needs to be ported. Maybe for now just to convert from memory:vdpau to meta:GstVideoGLTextureUploadMeta.

Also I think the vtable construction in your patch can be done in gstgl directly. Indeed GL_NV_vdpau_interop is defined in glext.h and part of the khronos specs/regitry.
Also vdpdevice is void* in this header so no need to include vdpau.h in gstgl.
Comment 9 Matthew Waters (ystreet00) 2018-05-05 14:13:21 UTC
vdpau is not really that interesting anymore with nvdec support.