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 763365 - glfilterapp not correctly drawing the default scene
glfilterapp not correctly drawing the default scene
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.6.3
Other Linux
: Normal normal
: 1.7.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-09 09:03 UTC by Nicolas
Modified: 2016-03-11 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas 2016-03-09 09:03:46 UTC
using glfilterapp (no callback just in the pipe) let show a flickering of a first texture and some other black screen.
I try to patch it to only draw the texture, but it let display only black screen.
Modifying filtercube (the more approaching plugins) using gst_gl_filter_draw_texture give the same problems. It seems that as we do not provide a shader, render is not correct. 

pipe used : 

gst-launch-1.0 videotestsrc ! glupload ! glconvert ! glfilterapp ! glimagesink
Comment 1 Nicolas 2016-03-09 20:00:20 UTC
More precision : My board (dragonboard 410) support opengl 3.0 which is for gstreamer opengl only (opengl 3 begin with 3.2)
So rendering functions used are opengl (can be simulated by GST_GL_API=opengl before gst-launch) and in this case plugins that use opengl rendering doesn't work properly (glfilterapp, glcolorscale)
But the others filters that use shader withiut checking opengl version of the context work fine
Comment 2 Matthew Waters (ystreet00) 2016-03-10 12:11:46 UTC
These make the default drawing work for me now in all three GST_GL_API variants.

commit 8ceeca93b289a51e60c04b5102cd26bcb7262929
Author: Matthew Waters <matthew@centricular.com>
Date:   Thu Mar 10 00:29:41 2016 +1100

    glfilterapp: update for the use of shaders
    
    Fixes black output when placed in pipelines (using the default drawing).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=763365

commit 92b9b57d3ea0029358b1b76944a3afc7589043b4
Author: Matthew Waters <matthew@centricular.com>
Date:   Thu Mar 10 00:27:53 2016 +1100

    glfilter: retrieve the shader attributes from the GL thread
    
    Otherwise we will receive bogus values
    
    https://bugzilla.gnome.org/show_bug.cgi?id=763365
Comment 3 Nicolas 2016-03-10 14:15:18 UTC
So rendering with a passthrough shader is the solution even in opengl only api ?
(in this case perhaps the glcolorscale plugins should be modified too ?)

Last question, glfilterapp callback in user space should use a passthrough shader too thats it ? or the default one will be active ?
Comment 4 Matthew Waters (ystreet00) 2016-03-10 14:39:27 UTC
It's not the only solution however it's the simplest and the rest of libgstgl essentially requires some kind of shader support so there's no real point special casing the default handler.

glcolorscale already uses a shader: https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/gstglcolorscale.c#n147

Your own glfilterapp callback can do whatever it likes given the GstGLContext provided at the 'context' property.  If you have GL < 3.2 then you can do the legacy glVertex/glTexCoord calls in your callback and things will work fine (if they don't, that's a bug ;)).

If you don't connect to the 'client-draw' signal, then the default handler will run.
Comment 5 Nicolas 2016-03-10 15:11:15 UTC
Ok for this explanation, I though it was the solution seeing other plugins but I hesitate putting a default passthrough shader directly in the glfilter class ? rather in each filter (app, scale)
Ok for colorscale it was modified since the 1.6.3, my mistake

I will try the client-draw as soon a I backport your modifiaction in the 1.6.3, at the moment it works only if I deactivate the depth buffer.
And just a thing not correlated, but when I recompile exactley the same tag than on my debian, .so are not of the same size by far (seems like code flew from ligstgl to libgstopengl (not a litlle something like 1Mo), or other way don't remember exactly, I don't compile with Orc, can it be the difference ? )