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
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: 1.5.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-22 15:08 UTC by Xavier Claessens
Modified: 2015-08-16 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
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

+ Trace 235082







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:





+
Trace
    235083






    

  • 
#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 <matthew@centricular.com>
Date:   Mon May 25 17:27:58 2015 +1000

    gltransformation: fix DrawElements call for element array buffers
    
    https://bugzilla.gnome.org/show_bug.cgi?id=749734






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 <matthew@centricular.com>
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.