Same result with gtkxoverlay test.

the latest changes to gst-plugins-gl are probably responsible for this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=578939

Created attachment 134292 [details]
register objc thread

Hi,

On Mac OSX there is no GSRegisterCurrentThread (which is GNUstep specific).
The crash you got comes shows that we finally cannot avoid it as it's currently done.
For now in gst-plugins-gl/gst-libs/gst/gl/gstglwindow_cocoa.m we have:

#ifndef GNUSTEP
static BOOL GSRegisterCurrentThread(void) { return TRUE; };
static void GSUnregisterCurrentThread(void) {};
#endif

I attached a possible implementation that comes from GNUstep code (gnustep-base-1.18.0/Source/NSThread.m) with some modifications I made to adapt it to our case. 
(it's not a patch, you have to put the attachment code into gstglwindow_cocoa.m)

I have no Mac machine so I let you try it.

Julien

G.P. : 

"
Neither objc_mutex_t nor objc/thr.h exists on Mac OS X.

There are two Objective-C runtime implementations: the one originally written by NeXT, and the one originally written for GNU. They both implement the same language (more or less), but their internal structure, file formats, and introspection API are incompatible. Mac OS X uses the NeXT runtime, and gcc includes the GNU runtime to be used on platforms other than Mac OS X.

GSRegisterCurrentThread() tells the GNU runtime about a non-NSThread. There's no need to do that on Mac OS X unless you're using the garbage collector.

As far as I know there is no way to reassign the main thread. The main thread must always be the one started by the kernel at process launch.
"


My approach was to reassign the main thread and so make the gl thread the main thread. Then I could run the nsapp loop in the gk thread. But it's only possible with GNUstep. Moreover it causes problems when using several glimagesink, because it was attempting to have several main threads and this is not possible.

So I changed my approach a little bit.
We have two cases : non-embedded (gst-launch), and embedded (cocoa application)

The nsapp is initialized at gstglwindow class initialization to make sure the nsapp is initialized only one time (for multiple sink).
In non-embedded mode the nsapp is initialized in the main thread through the g_main_loop (which is runnning in the main thread when using gst-launch).
In embedded mode the nsapp is initialized by the user in his client code (see gst-plugins-gl/tests/exampples/cocoa/videoxoverlay/main.m)


In the gl thread I am now running a NSRunLoop associated with the NSThread (which is associated to the gl thread)
This loop performs all OpenGL calls and hanldes the events of the non-embedded window.
In embedded mode, this loop only handles OpenGL calls.(the gl context is made current only one time).
Also in embedded mode, the user can run the nsapp as normal. (see gst-plugins-gl/tests/exampples/cocoa/videoxoverlay/main.m)

commit 6f80b865d5fb7e7cf70541324abb985ce48ba0ef    
Author: Julien Isorce <julien.isorce@gmail.com>    
Date:   Mon Jul 27 09:58:20 2009 +0200             

    Cocoa backend: make sure that nsapp is initialized
                                                      
    gst-launch-0.10 videotestsrc ! tee name=t ! queue ! glimagesink t. ! queue ! glimagesink
    now works properly on MacOSX                                                              

commit db69e930c5ef485f6ba16dd79af8e2da71a617ce
Author: Julien Isorce <julien.isorce@gmail.com>
Date:   Fri Jul 24 10:12:07 2009 +0200         

    Cocoa backend: fix crash when closing
                                         
    - All gstglwindow members are now modified only in the gl thread
    to avoid thread concurrency
    - OpenGL context is now properly clean
    - fix a couple of things in implementation of xoverlay interface

commit f13d38b8e76974792905b2beb9aa01cf0a6af261
Author: Julien Isorce <julien.isorce@gmail.com>
Date:   Fri Jul 17 16:47:41 2009 +0200

    make cocoa backend work on MacOSX

    It works with both gst-launch and a cocoa app (non-embedded and embedded)
    But there is still some problems:
      - sometimes crash when closing
      - flickering when resizing
      - embedded mode not perfect

    I will first make the CMake build work with cocoa backend
    in order to generate a XCode project.
    Then it should be easier to fix those issues.