GNOME Bugzilla – Bug 744999
Crash in OpenGL ES draw_cb on iOS when going to background
Last modified: 2018-11-03 13:30:55 UTC
Hello, Found on GStreamer master (15.02.15), iOS 8.1.2. While testing our application on iOS, we’ve faced with a crash when going to background with a running pipeline. The crash happened inside draw_cb (OpenGL ES related code). I assume this is because Apple’s strict rules regarding background task: “ Do not make any OpenGL ES calls from your code. You must not create an EAGLContext object or issue any OpenGL ES drawing commands of any kind while running in the background. Using these calls causes your app to be killed immediately. Apps must also ensure that any previously submitted commands have completed before moving to the background. For information about how to handle OpenGL ES when moving to and from the background, see Implementing a Multitasking-aware OpenGL ES Application in OpenGL ES Programming Guide for iOS. “ Link to guide: https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ImplementingaMultitasking-awareOpenGLESApplication/ImplementingaMultitasking-awareOpenGLESApplication.html#//apple_ref/doc/uid/TP40008793-CH5 Could you please help me with some instructions how we could overcome this. We can’t stop the pipeline, because it is a Lifestream. Here’s a pipeline: avfvideosrc ! video/x-raw,format=NV12,width=960,height=540,framerate=30/1 ! tee name=tp tp. ! queue ! autovideosink tp. ! queue ! videoconvert ! vtenc_h264 bitrate=2500 max-keyframe-interval-duration=2000000000 max-keyframe-interval=60 allow-frame-reordering=false realtime=true quality=0.5 ! h264parse ! video/x-h264,framerate=30/1,width=960,height=540,stream-format=(string)avc,level=(string)3.1,profile=(string)main ! queue ! mux. autoaudiosrc ! audioconvert ! voaacenc bitrate=64000 ! aacparse ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 ! flvmux streamable=true name=mux ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 ! rtmpsink location=‘%url_was_here% live=1’ Stack trace: 0libGPUSupportMercury.dylib0x2c9e68a6 gpus_ReturnNotPermittedKillClient + 10 1IMGSGX543GLDriver0x246930e0 <redacted> + 140 2GLEngine0x286c3318 gliPresentViewES_Exec + 176 3GLEngine0x286c3248 gliPresentViewES + 64 4OpenGLES0x286ce068 -[EAGLContext presentRenderbuffer:] + 64 5Trace0x00ccc470 draw_cb + 172 6Trace0x00ccdbb8 _run_message_sync + 20 7Trace0x00ccc3a8 _run_message + 12 8Trace0x00b8b698 g_main_context_dispatch + 196 9Trace0x00b8b8c0 g_main_context_iterate + 300 10Trace0x00b8ba88 g_main_loop_run + 180 11Trace0x00ccc188 gst_gl_window_eagl_run + 48 12Trace0x00cc31e8 gst_gl_context_create_thread + 504 13Trace0x00b7cad0 g_thread_proxy + 76 14libsystem_pthread.dylib0x33c53e60 _pthread_body + 132
I don't see any GStreamer video sinks in the pipeline you've presented here, nor any GStreamer in the stack trace. Are you sure you've attached the correct information?
Oh, pardon, there *is* GStreamer in the stack trace. However, I don't see a glimagesink in the pipeline. Or perhaps this is due to the GPU-based colorspace conversion performed by avfvideosrc? Hm.
autovideosink equates to glimagesink on iOS so it is being used. No idea if this is easily solvable or not. To work around you will have to prevent buffers from reaching autovideosink/glimagesink while your app is in the background. Also, your app can be killed at any time while backgrounded so you will need to account for this. i.e. you will need to account for restarting a viewing of the stream at any point in time anyway. Also, video recording is not allowed in the background either so that will also fail.
I think glimagesink (in EAGL) should learn to listen to the appropriate power notifications and act accordingly. Same thing will need to happen in: https://bugzilla.gnome.org/show_bug.cgi?id=752883
See also bug 752883.
(In reply to Ilya Konstantinov from comment #4) > I think glimagesink (in EAGL) should learn to listen to the appropriate > power notifications and act accordingly. The question is what that 'act accordingly' is. Is that error/warning? block? I think only the app has all the information available as what it needs to do in this case however we can certainly throw an error when this occurs.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/212.