GNOME Bugzilla – Bug 774584
Playback crashes after ~15 seconds of playback in GSTGL lib
Last modified: 2016-11-17 16:55:03 UTC
Created attachment 340047 [details] Zipped gstreamer log, 'gl*' catergor heavily I have setup the following playback pipeline: "playbin video-sink="glupload ! glcolorconvert ! appsink name=appSink0 caps=video/x-raw(memory:GLMemory),format=RGBA,texture-target=2D"" ... in order to catch video frames in openGL format and pass them along to be rendered by a third parts (ultimately a Unity app) I was seeing slow down after ~7 seconds, then a crash after maybe 15 seconds. Here is the trace that Unity spits out: 0x000000005D56748D (atio6axx) DrvPresentBuffers 0x000000005D51BFE3 (atio6axx) DrvPresentBuffers 0x000000005D53DC90 (atio6axx) DrvPresentBuffers 0x000000005CBE5F93 (atio6axx) DrvPresentBuffers 0x000000005D393BFD (atio6axx) DrvPresentBuffers 0x000000006208705F (libgstgl-1.0-0) gst_gl_base_memory_alloc 0x0000000062085DA3 (libgstgl-1.0-0) gst_gl_allocation_params_free 0x0000000062083D69 (libgstgl-1.0-0) gst_gl_context_thread_add 0x0000000062085B91 (libgstgl-1.0-0) gst_gl_allocation_params_free 0x000000006147FC88 (libgstreamer-1.0-0) gst_memory_map 0x000000006208B490 (libgstgl-1.0-0) gst_gl_memory_allocator_get_default 0x0000000062085DA3 (libgstgl-1.0-0) gst_gl_allocation_params_free 0x0000000062083D69 (libgstgl-1.0-0) gst_gl_context_thread_add 0x0000000062085B91 (libgstgl-1.0-0) gst_gl_allocation_params_free 0x000000006147FC88 (libgstreamer-1.0-0) gst_memory_map 0x0000000062095E78 (libgstgl-1.0-0) gst_glsl_stage_compile 0x00000000620987C4 (libgstgl-1.0-0) gst_gl_color_convert_decide_allocation 0x000000006209C247 (libgstgl-1.0-0) gst_gl_upload_perform_with_buffer 0x000000006209BF96 (libgstgl-1.0-0) gst_gl_upload_perform_with_buffer 0x00000000685F0FB4 (libglib-2.0-0) g_main_context_dispatch 0x00000000685F12B8 (libglib-2.0-0) g_main_context_dispatch 0x00000000685F16F8 (libglib-2.0-0) g_main_loop_run 0x0000000062084C9A (libgstgl-1.0-0) gst_gl_context_fill_info 0x0000000068614329 (libglib-2.0-0) g_test_get_filename 0x00000000686307EA (libglib-2.0-0) g_private_replace 0x00007FF8561AB2BA (msvcrt) beginthreadex 0x00007FF8561AB38C (msvcrt) endthreadex 0x00007FF855AD8364 (KERNEL32) BaseThreadInitThunk 0x00007FF8581B5E91 (ntdll) RtlUserThreadStart Thinking it might be my code, I tested playback with the pipeline using the following gst-launch command: gst-launch-1.0 playbin uri=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-separate_init.mpd video-sink="glupload ! glcolorconvert ! appsink name=appSink0 caps=video/x-raw(memory:GLMemory),format=RGBA,texture-target=2D" After approximately 15 seconds gst-launch crashes. In addition, I ran the same gst-launch command with the debug option '--gst-debug=3,gl*:9'. The log for this is attached - gst.txt within gst.zip. Last bit of additional info. Thinking it might be linked to playing an adaptive (DASH) stream, I tried a 'local' h.264 (big buck bunny) mp4 video file...with the same resulting crash.
Does it still crash with 'appsink max-buffers=1 drop=true' ? I suspect the problem is that appsink is queueing all those textures for you and you're running out of video memory. Note the crash is inside your video driver.
Ah, yes...you might be right. I added 'max-buffers=1 drop=true' to the appsink and gst-launch doesn't seem to crash anymore, yay! However, in app I am catching 'new-sample' to grab the frame. An empty function (returning GST_FLOW_OK) here means the app behaves without error. Bu, adding the following call to the function: gst_app_sink_pull_sample( (GstAppSink*)( appsink ) ); ...and I get app slowdown and then crash (just as originally seen). I even tried: gst_app_sink_try_pull_sample( (GstAppSink*)( appsink ), GstClockTime( 1 ) ); ...thinking the slowdown might be some blocking waiting for the sample. This is probably something stupid I am doing/not doing...so huge apologies if this isn't a genuine issue.
Dug a bit more, wasn't aware that samples needed to be unreferenced. Calling 'gst_sample_unref' on the crabbed sample appears to fix that. Not a bug!? Carry on!
Unfortunate side effect, but not sure if there's much we can do here. Thanks for letting us know!