I have been doing a little bit of research around this issue:
CocoaHelper::AttachCocoaViewFromMessage(GstMessage* message, const WindowHandle& handle)
// Extract the cocoa view from the message:
NSView* cocoaView = (NSView*)g_value_get_pointer(
if (cocoaView == 0)
MEDIA_LOG_ERROR("Message does not contain a value with name \"nsview\"");
// Create Cocoa wrapper view:
retVal = HICocoaViewCreate(cocoaView, 0, &cocoaWrapperView);
if (retVal != 0)
MEDIA_LOG_ERROR("Unable to create Cocoa wrapper view, return value: ", retVal);
// Attach view to incoming Carbon view:
// From Qt sources "qwidget_mac.cpp" confirms that a WId can be
// safely converted to a HIViewRef on the mac. (see qt_mac_hiview_for line 254)
HIViewRef renderView = (HIViewRef)handle.GetHandle();
if ((retVal = HIViewAddSubview(renderView, cocoaWrapperView)) != 0)
MEDIA_LOG_ERROR("Unable to attach Cocoa wrapper view to render view. "
" return value: ", retVal);
outputHandle = WindowHandle((HandleType)cocoaWrapperView);
MEDIA_LOG_INFO("Successfully attached Cocoa view ", static_cast<void*>(cocoaView),
" to Carbon view with handle ", handle,
". Handle of view wrapper view is ", outputHandle);
2008-06-27 11:05:38.106 com.neokast.stream.player.ui.view_TESTCASES[92020:a80b] invalid drawable
2008-06-27 11:05:38.147 com.neokast.stream.player.ui.view_TESTCASES[92020:a80b] *** _NSAutoreleaseNoPool(): Object 0x1af9cb10 of class NSSurface autoreleased with no pool in place - just leaking
Stack: (0x90c9e12f 0x90baaec2 0x92cdef8b 0x92daa15c 0x190b3bca 0x190b2af7 0x31791f2 0x317acf0 0x317b351 0x317b970 0x31f5d86 0x31f657a 0x31890e3 0x31f5d86 0x31f657a 0x18f13fff 0x3212309 0x32f97ec 0x32f76de 0x94ef3c55 0x94ef3b12)
2008-06-27 11:05:38.147 com.neokast.stream.player.ui.view_TESTCASES[92020:a80b] *** _NSAutoreleaseNoPool(): Object 0x1afc2dd0 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x90c9e12f 0x90baaec2 0x92ddbc92 0x92daa15c 0x190b3bca 0x190b2af7 0x31791f2 0x317acf0 0x317b351 0x317b970 0x31f5d86 0x31f657a 0x31890e3 0x31f5d86 0x31f657a 0x18f13fff 0x3212309 0x32f97ec 0x32f76de 0x94ef3c55 0x94ef3b12)
Thanks for your detailed response. I have taken a closer look at the source code for osxvideosink and found that it supports an "embed" property (which is FALSE by default).
I can tell that when TRUE it will emit a message called "have-ns-view", where it passes a GstGLView object to the callback. This object is an NSView (part of the Apple Cocoa framework). I have learned that I am supposed to attach that to a NSWindow.
Unfortunately I am pretty new to programming on the Mac. Thus far I have been using OS abstraction libraries such as Qt to avoid dealing with different windowing systems. Qt gives me back a window handle, which turns out to be integer but I have no idea how to retrieve a NSWindow object from that.
So if anyone has done this before on the Mac (with or without Qt) I would greatly appreciate your input.
AndreasOn Wed, Jun 25, 2008 at 5:26 PM, Michael Smith <firstname.lastname@example.org> wrote:
On Wed, Jun 25, 2008 at 3:16 PM, Andreas Schuler <email@example.com> wrote:That looks good for Win32 and linux. On linux the 'window handle' will
> Hi all,
> I am trying to get an application to run on a Max OSX 10.5.2. I have
> downloaded and built the latest tar balls and everything seems to be running
> fine when I use gst-launch.
> >From within my app, which also runs on Windows, I am doing the following to
> set the id of the window I want the video to be rendered on:
> - get_bus_set_sync_handler to setup my callback
> - The callback function looks as follows:
need to be the XID for the window, but that's just a matter of
different platform-specific types, not a big problem.
On OSX, you're presumably using osxvideosink (well, you say you're
using autovideosink, but that'll be selecting osxvideosink
osxvideosink doesn't implement GstXOverlay, so you can't do this with
it. Because of this it won't ever even emit the prepare-xwindow-id
signal, which is what you're seeing.
osxvideosink has some other interface to set this up, but I don't know
the details of how it works. You may find looking at the output of
"gst-inspect-0.10 osxvideosink" to be helpful - it'll tell you what
signals exist, etc.
If possible, it would be best to make osxvideosink implement the
GstXOverlay interface - that would let people use more common code
across different platforms. Looking into whether that's possible is on
my TODO list, but pretty far down right now - I probably won't get to
it for a month or two. If you manage to do that sooner, that'd be
great - patches would be very welcome.