GStreamer linux issue

Using Cinder
1

Hi,

I ran into a strange issue with MovieGl playback in linux. My application is playing lots of videos and from time to time the movie player fails and after that it is not possible to play any more movies until restart. I haven’t been able to locate the problem so far. I’m not sure if it is a Cinder or GStreamer bug, maybe it is my fault.
The following message is displayed in the console when this happens:

** (App:20027): CRITICAL **: 14:18:44.785: gst_gl_display_get_gl_api: assertion 'GST_IS_GL_DISPLAY (display)' failed

** (App:20027): CRITICAL **: 14:18:44.785: gst_gl_context_new_wrapped: assertion '(display_api & available_apis) != GST_GL_API_NONE' failed

(App:20027): GLib-GObject-CRITICAL **: 14:18:44.785: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
|info   | bool gst::video::GstPlayer::setPipelineState(GstState)[1011] Pipeline state about to change from : NULL to : READY
|info   | bool gst::video::GstPlayer::checkStateChange(GstStateChangeReturn)[1029] Pipeline state changed SUCCESSFULLY from : NULL to : READY
|info   | gboolean gst::video::checkBusMessagesAsync(GstBus*, GstMessage*, gpointer)[261] Pipeline state changed from : NULL to : READY with pending : VOID_PENDING
|info   | GstBusSyncReply gst::video::checkBusMessagesSync(GstBus*, GstMessage*, gpointer)[146] Need context : gst.gl.GLDisplay from element : convert

(App:20027): GStreamer-CRITICAL **: 14:18:44.786: invalid unclassed object pointer for value type 'GstGLDisplay'
|info   | GstBusSyncReply gst::video::checkBusMessagesSync(GstBus*, GstMessage*, gpointer)[146] Need context : gst.x11.display.handle from element : convert
|info   | GstBusSyncReply gst::video::checkBusMessagesSync(GstBus*, GstMessage*, gpointer)[146] Need context : GstWaylandDisplayHandleContextType from element : convert
|info   | GstBusSyncReply gst::video::checkBusMessagesSync(GstBus*, GstMessage*, gpointer)[146] Need context : gst.gl.app_context from element : convert

** (App:20027): CRITICAL **: 14:18:44.787: gst_gl_context_get_display: assertion 'GST_IS_GL_CONTEXT (context)' failed
|info   | gboolean gst::video::checkBusMessagesAsync(GstBus*, GstMessage*, gpointer)[212] Have context : gst.gl.GLDisplay from element : convert

** (App:20027): CRITICAL **: 14:18:44.787: gst_gl_display_get_handle_type: assertion 'GST_IS_GL_DISPLAY (display)' failed

(App:20027): GStreamer-CRITICAL **: 14:18:44.787: gst_object_unref: assertion 'object != NULL' failed

(App:20027): GStreamer-CRITICAL **: 14:18:44.787: gst_object_unref: assertion 'object != NULL' failed
|info   | GstBusSyncReply gst::video::checkBusMessagesSync(GstBus*, GstMessage*, gpointer)[146] Need context : gst.gl.app_context from element : upload

** (App:20027): CRITICAL **: 14:18:44.787: gst_gl_context_get_display: assertion 'GST_IS_GL_CONTEXT (context)' failed

** (App:20027): CRITICAL **: 14:18:44.787: gst_gl_display_get_handle_type: assertion 'GST_IS_GL_DISPLAY (display)' failed

Has anyone run into something like this before, maybe @petros? I would be grateful for any pointers how to address this. Thanks.

-Gabor

2

Hey Gabor,

This looks like a problem with sharing the GL context with GStreamer. When you say playing a lot of videos you mean loading and unloading lots of videos during runtime or just loading once lots of videos and then just playing them back? I would expect you mean the former. Also have you enabled by any chance the async loading option ( i.e have you set this option to true ) ?

Would be definitely relevant and interesting to know what version of GStreamer you are using and also on what kind of hardware you are running this ( most importantly your graphics hw ).

Lately I have been considering that it might be a good idea to apply this patch that is open for Windows also on macOS and Linux. I haven’t seen this issue on Linux with the latest versions of GStreamer but nevertheless it might be safer ( albeit a bit slower ) to create the shared context on our own and then pass it to GStreamer as it happens with the patch that I linked.

If you are under the gun and you want a quick fix you can force the traditional path which should work under any condition by sacrificing some performance. In order to do that just force this line to false.

I m currently on holidays so I m not going to be able to properly debug or do any tests on this but will be available to offer any other advice I can on the matter and def look on this in more detail once I am back.

Let us know how it goes.

Cheers,
Petros

1 Like
3

Hi Petros,

Thank you very much for the quick reply. I’m much obliged.

I’m loading and unloading lots of videos during runtime. I didn’t enable async loading. I have GStreamer 1.14 with an NVidia GTX 1060 6Gb (driver 396.54).

Thanks for the quick workaround. I have a close deadline, so this saved me. I get back to it later and try to add the more proper context sharing.

Gabor

4

Hey Gabor,

Back to action. I have just opened a PR that should address the issues described here. If you have some time would be great to give it a try and see if that works for your particular use case.

Cheers,
Petros

5

Hi Petros,

Sorry for the late reply. I tested the latest master with your PR merged in, and it seems to be working great! Thank you!

-Gabor