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 749734 - gltransformation: black screen (or crash) on Windows
gltransformation: black screen (or crash) on Windows
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal normal
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-05-22 15:08 UTC by Xavier Claessens
Modified: 2015-08-16 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

gltransformation: fix black image (744 bytes, patch)
2015-05-23 01:43 UTC, Xavier Claessens
none Details | Review
gltransformation: Fix crash on win32 with intel driver (1.40 KB, patch)
2015-06-29 18:09 UTC, Xavier Claessens
none Details | Review

Description Xavier Claessens 2015-05-22 15:08:26 UTC
With today's gst master, using this pipeline:

gst-launch-1.0 playbin uri=<some h264 mp4> video_sink="glupload ! glcolorconvert ! gltransformation ! glimagesink"

On linux I get a black screen. On windows I get a crash. If I remove gltransformation from the pipeline then it works perfectly on both linux and windows.
Comment 1 Xavier Claessens 2015-05-22 15:12:38 UTC
Backtrance on windows:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1052.0x87c]
0x00000001800bca78 in ?? () from /cygdrive/c/Windows/system32/ig4icd64.dll
(gdb) bt

Comment 2 Xavier Claessens 2015-05-22 20:15:07 UTC
Using this pipeline has the same effect:
gst-launch-1.0 videotestsrc ! glupload ! glcolorconvert ! gltransformation ! glimagesink

The backtrance in previous comment was corrupted. I debugged it step by step in gdb on windows, and here is where it really crash:

  • #0 gst_gl_transformation_callback
    at gstgltransformation.c line 593
  • #1 gst_gl_framebuffer_use_v2
    at gstglframebuffer.c line 203
  • #2 _use_fbo_v2
    at gstglutils.c line 359
  • #3 _run_message_sync
    at gstglwindow.c line 537
  • #4 _run_message
    at gstglwindow_win32.c line 428
  • #5 g_main_dispatch
    at gmain.c line 3210
  • #6 g_main_context_dispatch
    at gmain.c line 3874
  • #7 g_main_context_iterate
    at gmain.c line 3945
  • #8 g_main_loop_run
    at gmain.c line 4139
  • #9 gst_gl_context_create_thread
    at gstglcontext.c line 1346
  • #10 g_thread_proxy
    at gthread.c line 764
  • #11 g_thread_win32_proxy
    at gthread-win32.c line 450
  • #12 srand
    from /cygdrive/c/Windows/system32/msvcrt.dll
  • #13 msvcrt!_ftime64_s
    from /cygdrive/c/Windows/system32/msvcrt.dll
  • #14 KERNEL32!BaseThreadInitThunk
    from /cygdrive/c/Windows/system32/kernel32.dll
  • #15 ntdll!RtlUserThreadStart
    from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  • #16 ??

Comment 3 Xavier Claessens 2015-05-22 20:53:55 UTC
This is a regression introduced by commit 7f7a9dd3ec5851cc52b719317573bc70d0e91fbf. I'm suspecting we are in a case where triangles doesn't get created and then gl->DrawElements is called with indices that doesn't reffer to anything.
Comment 4 Xavier Claessens 2015-05-23 01:43:51 UTC
Created attachment 303840 [details] [review]
gltransformation: fix black image
Comment 5 Xavier Claessens 2015-05-23 01:44:30 UTC
I'm not sure why, but this fix the problem :P
Comment 6 Matthew Waters (ystreet00) 2015-05-25 07:39:56 UTC
commit 9dcefacb3d30280ea25d74c30807d397ebac72a1
Author: Matthew Waters <>
Date:   Mon May 25 17:27:58 2015 +1000

    gltransformation: fix DrawElements call for element array buffers
Comment 7 Xavier Claessens 2015-06-29 16:00:12 UTC
Actually, with your patch it still crash. If I revert it and apply mine, it works fine.
Comment 8 Xavier Claessens 2015-06-29 18:09:42 UTC
Created attachment 306313 [details] [review]
gltransformation: Fix crash on win32 with intel driver
Comment 9 Xavier Claessens 2015-06-29 18:11:53 UTC
I'm not sure to understand how it works, but this patch fix my problem. I copied what's done in other modules like glfiltercube and gloverlay, so it's probably the right thing to do.
Comment 10 Matthew Waters (ystreet00) 2015-07-07 08:53:16 UTC
Oops, I believe I already fixed it before seeing your patch

commit 2b9dddbafe89e05e715b0dce74f2f5e130830968
Author: Matthew Waters <>
Date:   Tue Jul 7 15:30:17 2015 +1000

    gltransformation: correct vao usage
    keep the vao bound after uploading the new vertex data
    fixes a mesa GL error "no vertex array object bound" on caps changes
Comment 11 Xavier Claessens 2015-07-07 16:10:29 UTC
When I compare with code in gstglcubefilter.c, it makes sure to unbind everything before leaving if (!cube_filter->vertex_buffer) {} block, then re-bind them. 

With your patch in gstgltransformation it doesn't unbind stuff before re-binding them, is it fine? For example, it's fine to call gl->BindVertexArray (transformation->vao); twice without doing gl->BindVertexArray (0) between the 2 calls?
Comment 12 Matthew Waters (ystreet00) 2015-07-08 05:28:56 UTC
Yes, GL is a big state machine. As long as the correct state is in place then everything will work.