Bug 64809

glimagesink is unsupported, can you get a backtrace of the crash with osxvideosink?

Created attachment 79611 [details]
osxvideo crash on mac os 10.7.4

test QtGStreamer sample player with an osxvideo crash on mac os 10.7.4

 Thanks for your reply. Please see the crash dump info which is saved as a attached file with this message. And I've other questions,
1) I did these test the player sample on a VMWare virtual machine, for I don't have any real Mac at hand. Is it concerning with the VMWare?
2) why is the glimagesink not supported,  has it other problem?  I've alse test the ximagesink and it works in gst-launch but the same result to glimagesink in Qt player. So, I doubt the problem may exist in Qt's "window" did not connect the gst video sink properly.

(In reply to comment #2)
> Created attachment 79611 [details]
> osxvideo crash on mac os 10.7.4
> 
> test QtGStreamer sample player with an osxvideo crash on mac os 10.7.4

(In reply to comment #3)
>  Thanks for your reply. Please see the crash dump info which is saved as a
> attached file with this message. And I've other questions,
> 1) I did these test the player sample on a VMWare virtual machine, for I
> don't have any real Mac at hand. Is it concerning with the VMWare?

Note that running OSX on non-Apple hardware is not legal ;)

It shouldn't be a problem with VMWare though. Does it happen for every file? Can you attach a file where this happens if it doesn't happen with all files?

Does it work if you do the same with gst-launch-0.10 and osxvideosink?

It looks like a problem in osxvideosink indeed.


How did you get Qt (which version?) and QtGstreamer built for the GStreamer SDK?

> 2) why is the glimagesink not supported,  has it other problem?  I've alse
> test the ximagesink and it works in gst-launch but the same result to
> glimagesink in Qt player. So, I doubt the problem may exist in Qt's "window"
> did not connect the gst video sink properly.

gst-plugins-gl is not maintained any longer since some time, and need some work in different places to be possible to support. The videosink itself should be fine though, just all the effects and other things around it are a bit problematic :)

(In reply to comment #4)
> (In reply to comment #3)
> >  Thanks for your reply. Please see the crash dump info which is saved as a
> > attached file with this message. And I've other questions,
> > 1) I did these test the player sample on a VMWare virtual machine, for I
> > don't have any real Mac at hand. Is it concerning with the VMWare?
> 
> Note that running OSX on non-Apple hardware is not legal ;)


Yes, I just want to test if the program works on mac os, so I did it in VMWare and will not really use it. :)



> 
> It shouldn't be a problem with VMWare though. Does it happen for every file?
> Can you attach a file where this happens if it doesn't happen with all files?
> 
Yes, it happed for every file.I've test avi and mp4 file.

> Does it work if you do the same with gst-launch-0.10 and osxvideosink?
> 

osxvideosink crash also in gst-launch-0.10, that is why I tried to set glimagesink to playbin2. It seems osxvideosink totally doesn't work on my machine.

> It looks like a problem in osxvideosink indeed.
> 
> 
> How did you get Qt (which version?) and QtGstreamer built for the GStreamer
> SDK?

I download the QtCreator 2.7 from ,http://download.qt-project.org/official_releases/qtcreator/2.7/2.7.1/qt-creator-mac-opensource-2.7.1.dmg
and Qt 4.8.4 from, http://download.qt-project.org/official_releases/qt/4.8/4.8.4/qt-mac-opensource-4.8.4.dmg
All the needed dependent libaries include GStreamer are download and built by mac port.

> 
> > 2) why is the glimagesink not supported,  has it other problem?  I've alse
> > test the ximagesink and it works in gst-launch but the same result to
> > glimagesink in Qt player. So, I doubt the problem may exist in Qt's "window"
> > did not connect the gst video sink properly.
> 
> gst-plugins-gl is not maintained any longer since some time, and need some
> work in different places to be possible to support. The videosink itself
> should be fine though, just all the effects and other things around it are a
> bit problematic :)

> It looks like a problem in osxvideosink indeed.
> 
> 
> How did you get Qt (which version?) and QtGstreamer built for the GStreamer
> SDK?

I built the QtGstreamer by blow steps,
1) cd /path_of_QtGStreamer/
2) mkdir build
3) cmake ..
4) make && make install

before the cmake, I downloaded all the needed libraries by mac port, like gstreamer, boost, pkg-config etc..

And I find this post,
http://comments.gmane.org/gmane.comp.video.gstreamer.bugs/102540
[Bug 691484] New: Crash in osxvideosink when displaying on Qt widget

I found the latest source of gst-plugins-good of branch 0.10 has patched already, I download and build the plugins, but still get the osxvideosink crash. :(


(In reply to comment #7)
> And I find this post,
> http://comments.gmane.org/gmane.comp.video.gstreamer.bugs/102540
> [Bug 691484] New: Crash in osxvideosink when displaying on Qt widget

I think I have found the reason, because osxvideosink at creation time, the need for hardware acceleration, so when it is running in a virtual machine, it will lead to the creation fails. In showFrame, gets the display memory is empty, causing memory access crash. I will be in a real mac machine test results.

//---cocowindow.m----//
- (id) initWithFrame:(NSRect) frame {
  NSOpenGLPixelFormat *fmt;   
  NSOpenGLPixelFormatAttribute attribs[] = {
    NSOpenGLPFAAccelerated,  <--this flag cause initWithFrame failed on a virtual machine.
    NSOpenGLPFANoRecovery,
   ,...

//---osxvideosink.m----//

- (void) showFrame: (GstBufferObject *) object
{
  guint8 *viewdata;
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  GstBuffer *buf = object->buf;

  if (!destroyed)
  {
    viewdata = (guint8 *) [osxvideosink->osxwindow->gstview getTextureBuffer];
    <---------------viwdata will return NULL if initWithFrame failed before.
    memcpy (viewdata, GST_BUFFER_DATA(buf), GST_BUFFER_SIZE(buf));
    <--------------- crashed here when NULL memory access.
    [osxvideosink->osxwindow->gstview displayTexture];
  }

Ah, thanks for debugging that. It should however not crash in any case, that needs to be fixed. It should at least error out properly or fall back to a slower mode.

Yes, maybe a memory valid check shoud be added.
 if(viewdata != NULL)
 {
    memcpy(viewdata,...);
 }

This should be properly checked in the initialization to fallback to a different sink if it's available.

Or just not use NSOpenGLPFAAccelerated if it is not available, there is no other useable sink for osx right now

I think we should probably just remove the NSOpenGLPFANoRecovery flag to allow a fallback to a software renderer when there are not enough resources.

David, can you test it on your VM removing this flag instead of the NSOpenGLPFAAccelerated one?

Hi Andoni,
  I did the test on my VMware. If only remove the NSOpenGLPFANoRecovery flag in initWithFrame function, it will still failed.

 0:00:00.059703000  1681 0x7fd730c19200 WARN            osxvideosink cocoawindow.m:396:-[GstGLView initWithFrame:]: Cannot create NSOpenGLPixelFormat
0:00:00.059755000  1681 0x7fd730c19200 INFO            osxvideosink osxvideosink.m:256:gst_osx_video_sink_osxwindow_create:<osxvideosink0> 'have-ns-view' message sent
0:00:00.166581000  1681 0x7fd730c19200 INFO            osxvideosink osxvideosink.m:269:gst_osx_video_sink_osxwindow_create:<osxvideosink0> emitting prepare-xwindow-id
0:00:00.183214000  1681 0x7fd730c8c520 WARN            osxvideosink cocoawindow.m:396:-[GstGLView initWithFrame:]: Cannot create NSOpenGLPixelFormat
0:00:00.218978000  1681 0x7fd730c19200 INFO            osxvideosink osxvideosink.m:293:gst_osx_video_sink_osxwindow_create:<osxvideosink0> No superview, creating an internal window.

(In reply to comment #14)
> I think we should probably just remove the NSOpenGLPFANoRecovery flag to
> allow a fallback to a software renderer when there are not enough resources.
> 
> David, can you test it on your VM removing this flag instead of the
> NSOpenGLPFAAccelerated one?

Thanks for the test. It looks like we will have to remove both for software rendering. From the docs [1] we have:


NSOpenGLPFANoRecovery
A Boolean attribute. If present, this attribute indicates that OpenGL’s failure recovery mechanisms are disabled. Normally, if an accelerated renderer fails due to lack of resources, OpenGL automatically switches to another renderer. This attribute disables these features so that rendering is always performed by the chosen renderer. This attribute is not generally useful.

NSOpenGLPFAAccelerated
A Boolean attribute. If present, this attribute indicates that only hardware-accelerated renderers are considered. If not present, accelerated renderers are still preferred.

So I think we should first test with both, and in case it fails, emit a warning and remove both of them to enable software renderers.


[1] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSOpenGLPixelFormat_Class/Reference/Reference.html