GNOME Bugzilla – Bug 795325
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX
Last modified: 2018-11-03 15:54:04 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
(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
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(!).
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.
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...
-- 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.