GNOME Bugzilla – Bug 797005
vaapi decode + glimagesink with DMABuf results in scrambled output
Last modified: 2018-08-22 10:29:51 UTC
Created attachment 373420 [details] glsinkimage output screenshot Now the following pipeline runs without pipeline errors, but the glimagesink output is scrambled (see attached screenshot): gst-launch-1.0 -v souphttpsrc location=https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm ! matroskademux ! vaapidecodebin ! "video/x-raw(memory:DMABuf)" ! glimagesink It looks like wrong image frame metadata is passed, perhaps incorrect stride. The following pipeline runs correctly (not buggy), but since I'm not using a capsfilter, it's going through video/x-raw(meta:GstVideoGLTextureUploadMeta) at the glimagesink. gst-launch-1.0 -v souphttpsrc location=https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm ! matroskademux ! vaapidecodebin ! video/x-raw(meta:GstVideoGLTextureUploadMeta) ! glimagesink
Until recently, glupload would accept dmabuf caps feature even without EGL support. As a side effect, raw uploader was used, and the image was badly rendered (the image is tiled). Are you runner on X11 with a recent enough Mesa that supports tiling and compression ?
This is on a stock Ubuntu 18.04 Beaver system, with stock distro drivers. I can find out details once I’m back in the office tomorrow.
I've asked if you have selected an X11 gnome-shell session (might be Ubuntu default, I have no idea, I'm not using it). This will let me confirm if it's the same bug. For the fix in Ubuntu, you'll have to report to the as we have no influence on that.
With confirmation, this will be a duplicate of: https://bugzilla.gnome.org/show_bug.cgi?id=796822 I've tried backporting it to 1.14, but it didn't work, so someone would have to take a look.
Confirmed, this problem goes away when switching to Wayland session.
Thanks for the quick response.
*** This bug has been marked as a duplicate of bug 796822 ***