[Bug 795325] New: gstreamer-vaapi stutters heavily when rendering (some videos) to GLX

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 795325
Summary: gstreamer-vaapi stutters heavily when rendering (some
videos) to GLX
Classification: Platform
Product: GStreamer
Version: unspecified
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@canonical.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---

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

["GStreamer" (GNOME Bugzilla)]

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

Daniel van Vugt <***@canonical.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://launchpad.net/bugs/
| |1698270

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #1 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
(In reply to Daniel van Vugt from comment #0)

Post by "GStreamer" (GNOME Bugzilla)
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX.
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

Post by "GStreamer" (GNOME Bugzilla)
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

Post by "GStreamer" (GNOME Bugzilla)
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

Post by "GStreamer" (GNOME Bugzilla)
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

["GStreamer" (GNOME Bugzilla)]

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

David Regev <***@gmail.com> changed:

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

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #2 from Daniel van Vugt <***@canonical.com> ---
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(!).

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #3 from Daniel van Vugt <***@canonical.com> ---
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.

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #4 from Daniel van Vugt <***@canonical.com> ---
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...

["GStreamer" (GNOME Bugzilla)]

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

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

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

["GStreamer" (GNOME Bugzilla)]

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

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

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

--- Comment #5 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/92.