GNOME Bugzilla – Bug 761519
gl: Activate "qos" in filters
Last modified: 2016-02-04 06:34:49 UTC
Since the glupload/convert split, I notice that streams performance don't degrade too well when slow path are used (e.g. glupload actually doing an upload). It also does not degrade well when we have a stream with a higher framerate then the compositor rate. One thing I notice, is that non of the glfilter/glupload/glcolorconvert activate qos by default (like videoconvert would do, as an example). With async pbo upload, and GPU operation, this should make no difference, but for synchronous upload, it will make a good deal of a difference.
Dis some quick test (to back this up), and indeed, there is cases where this makes a difference, on Intel / Gnome Wayland (I think that disables OpenGL 3 in practice): GST_GL_WINDOW=wayland gst-launch-1.0 videotestsrc is-live=1 ! video/x-raw,width=1280,height=720,framerate=300/1 ! glupload qos=1 ! glimagesink Disabling qos lead to choppy playback.
commit 4bbe16bb7fd6217391aa9d4cfa8307d1e871c809 Author: Matthew Waters <matthew@centricular.com> Date: Thu Feb 4 17:31:03 2016 +1100 glbasefilter: enable qos by default Improves the responsiveness of the pipeline when resources are close/above the limitations of the hardware. Any subclass that wishes not to enable qos can do so themselves. https://bugzilla.gnome.org/show_bug.cgi?id=761519