GNOME Bugzilla – Bug 745473
gl: Warning in opengl3 when using glcolorscale and gltransformation
Last modified: 2015-07-07 07:56:52 UTC
With this pipeline: gst-launch-1.0 uridecodebin uri=file:///something.jpg ! glcolorscale ! imagefreeze ! gltransformation ! glimagesink It prints tones of error like this: 0:00:01.103329371 5979 0x7f129c0546d0 ERROR glcontext gstglcontext.c:1068:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:4, GL_INVALID_VALUE in glDeleteSync (not a valid sync object) With gst-launch-1.0 it still work though. But with similar pipeline on my real app it crash with this assert: ** (lt-scout-client:788): CRITICAL **: gst_video_frame_map_id: assertion 'info->finfo->format == meta->format' failed Not sure that's related, but the error with gst-launch does not fill me with confidence.
I wanted to note that the pipeline works with removing either imagefreeze or glcolorscale. Replacing gltransformation with glfiltercube produces the same sync errors though. glfilterblur works strangely.
A backtrace please ? (with G_DEBUG=fatal_criticals)
** (lt-scout-client:5179): CRITICAL **: gst_video_frame_map_id: assertion 'info->finfo->format == meta->format' failed Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0x7fff82bff700 (LWP 5231)] g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff82bfdf68) at gmessages.c:1046 1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth)); (gdb) t apply all bt
+ Trace 234769
Thread 25 (Thread 0x7fff82bff700 (LWP 5231))
Thread 18 (Thread 0x7fffaaffd700 (LWP 5223))
Thread 17 (Thread 0x7fffab7fe700 (LWP 5222))
Thread 16 (Thread 0x7fffabfff700 (LWP 5221))
Thread 15 (Thread 0x7fffd0ff8700 (LWP 5220))
Thread 14 (Thread 0x7fffd17f9700 (LWP 5219))
Thread 13 (Thread 0x7fffd1ffa700 (LWP 5218))
Thread 12 (Thread 0x7fffd27fb700 (LWP 5217))
Thread 11 (Thread 0x7fffd2ffc700 (LWP 5216))
Thread 8 (Thread 0x7fffdcaf2700 (LWP 5211))
Thread 7 (Thread 0x7fffdd2f3700 (LWP 5210))
Thread 6 (Thread 0x7fffde15d700 (LWP 5188))
But note that with the gst-launch-1.0 command I pasted above, I get only the gstreamer error, no critical, so no crash. glcontext gstglcontext.c:1068:_gst_gl_debug_callback:<glcontextglx0> high: GL error from API id:3, GL_INVALID_VALUE in glDeleteSync (not a valid sync object)
Warnings goes away when running with GST_GL_API=opengl. So it's only with opengl3 API ;-P.
With GST_GL_API=opengl the gl error goes away, but not the critical, so please ignore the backtrace I attached it's not related, probably a bug in my app. But the gl error is still valid and can be reproduced with the gst-launch-1.0 command I posted in fist comment.
Doesn't this mean that the sync API does not support OpenGL3 currently? Or is it just the glfilercube and gltransformation elements? gltransformation not ported to GL3 yet though. For a proper core initialization the vertex buffer would need to be added to a VertexArray buffer, also the shader would need to be ported to GLSL3. As seen in my port of gltestsrc to GL3 (not upstream yet): https://github.com/lubosz/gst-plugins-bad/commit/900a3c966c9d3e985e280ec67068a3d984e4da1e Looking forward to Vulkan ;)
I reported the criticial and backtrace seperately in bug #745549
commit 840f63896f5c2ca9cefbf6d26c75c6096cdc5155 Author: Jan Schmidt <jan@centricular.com> Date: Wed Jun 3 00:31:42 2015 +1000 glsyncmeta: Set new sync point when copying Set a new sync point when copying instead of transferring the (non-refcounted) GL sync object from the source meta. https://bugzilla.gnome.org/show_bug.cgi?id=750279