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 795325 - gstreamer-vaapi stutters heavily when rendering (some videos) to GLX
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-04-17 09:50 UTC by Daniel van Vugt
Modified: 2018-11-03 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel van Vugt 2018-04-17 09:50:15 UTC
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX.

STUTTERY:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink

SMOOTH:
env GST_GL_PLATFORM=egl gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink

Interestingly, GLX is even slower than software rendering (ximagesink):

STUTTERY:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink

SMOOTH:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! ximagesink
Comment 1 Víctor Manuel Jáquez Leal 2018-04-17 10:25:13 UTC
(In reply to Daniel van Vugt from comment #0)
> gstreamer-vaapi stutters heavily when rendering (some videos) to GLX.
> 
> STUTTERY:
> env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc
> location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin !
> glimagesink

this is negotiated to GLUploadTexture by default

> SMOOTH:
> env GST_GL_PLATFORM=egl gst-launch-1.0 filesrc
> location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin !
> glimagesink

this is negotiated with dmabuf by default


> SMOOTH:
> env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc
> location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin !
> ximagesink

this is negotiated with normal memcopy
 
> Interestingly, GLX is even slower than software rendering (ximagesink):
> 
> STUTTERY:
> env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc
> location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin !
> glimagesink

Another exercise: compare with clutterautovideosink, which also uses GLUploadMeta (either in GLX or EGL)

env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! clutterautovideosink

In my setup it goes smooth.

Also compare with glimagesink forcing the memcopy:

env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location= ~/Downloads/bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! video/x-raw ! glimagesink

In my setup a lot of frames are dropped too.

IIUC, we should optimize when linking vaapi decoder and glimagesink
Comment 2 Daniel van Vugt 2018-04-18 05:22:45 UTC
clutterautovideosink is not smooth either (about half frame rate), but also not as bad as glimagesink. clutterautovideosink doesn't trigger warnings like glimagesink does:

WARNING: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2902): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING: from element
...

xvimagesink appears to stutter too. The only one that works smoothly is ximagesink(!).
Comment 3 Daniel van Vugt 2018-04-19 10:06:42 UTC
I'm starting to suspect this isn't a bug and may be just the fill rate limit being exceeded. It's only a problem with GLX+4K+60Hz. If I play the same video in FHD or 30Hz then it is smooth.

Interestingly, confirmed the same behaviour on a
 * Kaby Lake desktop
 * Kaby Lake laptop
 * Broadwell laptop

They all start to fail with GLX+4K+60Hz, but cope just fine if using EGL, or FHD, or 30Hz. I guess GLX is just that bit heavier in rendering.
Comment 4 Daniel van Vugt 2018-04-19 10:20:43 UTC
Almost forgot to mention: You CAN fix this bug if you get vaPutSurface to do the downscaling for you (my screen in FHD), and don't carry through massive 4K textures in GLX. However I don't know if it's feasible to communicate the desired application rendering resolution to the vaPutSurface in gstreamer-vaapi...
Comment 5 GStreamer system administrator 2018-11-03 15:54:04 UTC
-- 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/92.