[Bug 751684] Defaults to glimagesink even when GL is software rendered

[GStreamer (GNOME Bugzilla)]

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

Julien Isorce <julien.isorce at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at gmail.com

--- Comment #8 from Julien Isorce <julien.isorce at gmail.com> ---
Hi,

Have you compared ximagesink and glimagesink with the same sink video caps
format ? Because when using playbin I suspect glimagesink will get yuv directly
and imagesink rgb. Mesa's softpipe driver will be slow to convert yuv to rgb (+
scaling) I suspect.
You can try: playbin video-sink="video/x-raw, format=BGRx ! glimagesink". Same
with ximagesink.

In any case there are 2 versions of the software mesa driver swrast: softpipe
and llvmpipe. I guess the package you use does not provide this gallium
llvmpipe driver which is much faster.

You can verify the presence with es2_info (not sure if it is in mesa-utils or
another package) -> under GL_RENDERER field. Or with GST_DEBUG=*gl*:6
gst-launch-1.0 videotestsrc ! glimagesink.

Mesa's llvmpipe driver should work on arm. Also see:
http://lists.freedesktop.org/archives/mesa-dev/2015-April/081986.html

If an arm based distribution provides llvmpipe driver, glimagesink should not
be slower than ximagesink+orc.

The softpipe driver will definitely be slow on arm in most of the cases.

In GStreamer, at runtime we could check if glGetString (GL_RENDERER) contains
"softpipe".

You do not need a GstGLContext to call
gst_gl_context_default_get_proc_address(GST_GL_API_GLES2, "glGetString").

We could call that in gst-plugins-bad/ext/gl/gstopengl.c::plugin_init and
downgrade the rank only if GL_RENDERER string contains "softpipe".

Mesa provides the HW driver vc4 for raspberry pi but I think it has not been
released. So once available, glimagesink should be lower ranked than
ximagesink.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.