GNOME Bugzilla – Bug 763365
glfilterapp not correctly drawing the default scene
Last modified: 2016-03-11 15:56:48 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
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
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
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 ?
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.
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 ? )