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 620217 - glimagesink crash
glimagesink crash
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-gl
0.10.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-01 05:54 UTC by David Hoyt
Modified: 2010-10-18 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Hoyt 2010-06-01 05:54:46 UTC
I'm using glimagesink w/ xoverlay in ubuntu 9.10 -- the first time I run it, it works fine. But if I set the xid for xoverlay in subsequent calls, it crashes with: 

The error was 'BadWindow (invalid Window parameter)'.  
(Details: serial 14 error_code 3 request_code 3 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

The same code works fine w/ ximagesink and xvimagesink. When I don't use xoverlay and let gstreamer create its own window, it doesn't crash.

If I set the "sync" property on glimagesink (not related to the "--sync" option in the error message) to false, I don't get a crash -- but when I have a pipeline transition from NULL -> PLAYING -> NULL -> PLAYING, instead of embedding it, it creates a new window as large as my monitor.
Comment 1 Filippo Argiolas 2010-06-01 19:29:35 UTC
Which program causes this crash? A gtk one? it seems a common issue with client-side-windows and gstxoverlay misuse.
Comment 2 David Hoyt 2010-06-01 21:35:32 UTC
A GTK one. Every other image sink has worked just fine with the same code.

I've tried it with and without the xoverlay and it's still crashing.

I'm using glimagesink as part of playbin2 and with a simple videotestsrc pipeline. The equivalent videotestsrc one is:

videotestsrc ! queue2 ! ffmpegcolorspace ! videorate ! video/x-raw-yuv,framerate=10/1,width=640,height=480;video/x-raw-rgb,framerate=10/1,width=640,height=480 ! videoscale ! glimagesink 

That will play the first time and from gst-launch, but if, from inside an application, you do PLAYING -> NULL -> PLAYING it will crash.
Comment 3 David Hoyt 2010-06-01 21:38:51 UTC
The other sinks that have worked with this same set of code, on Windows/Ubuntu (x86), are: ximagesink, xvimagesink, directdrawsink, dshowvideosink, fakesink, and appsink.

It seems likely that it's a glimagesink issue.
Comment 4 Tim-Philipp Müller 2010-06-01 22:09:43 UTC
It would be quite helpful if you could write a minimal C program that causes this issue.
Comment 5 Felipe Besoaín Pino 2010-10-18 12:26:27 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 6 David Hoyt 2010-10-18 16:09:28 UTC
No problem. I haven't had time to get back to examining the issue.