GNOME Bugzilla – Bug 769514
splitmuxsink: Deadlock
Last modified: 2016-08-07 15:27:03 UTC
gdb --args bash gst-launch-1.0 videotestsrc num-buffers=25000 ! video/x-raw,width=1280,height=720 ! timeoverlay time-mode=2 ! x264enc ! h264parse ! splitmuxsink muxer=qtmux location=/home/vivia/video%05d.mov max-size-time=60000000000 [...] (gdb) thread apply all bt
+ Trace 236506
Thread 3 (Thread 0x7fffef2cb700 (LWP 5103))
Thread 2 (Thread 0x7fffefacc700 (LWP 5102))
From the backtrace, gstsplitmuxsink.c around line 1241: case SPLITMUX_STATE_START_NEXT_FRAGMENT: /* A fragment is ending, wait until that's done before continuing */ GST_DEBUG_OBJECT (pad, "Sleeping for fragment restart"); GST_SPLITMUX_WAIT (splitmux); GST_DEBUG_OBJECT (pad, "Done sleeping for fragment restart state now %d", splitmux->state); break; However, the freeze happens at random points, not when a fragment is ending. Also, it doesn't seem to happen with *:6 debug log enabled.
Created attachment 332887 [details] *:3,splitmuxsink:6 log
Fixed by: commit 89af379ff040923cfcbaf05354ed2b01a620b1b9 Author: Jan Schmidt <jan@centricular.com> Date: Mon Aug 8 00:56:38 2016 +1000 splitmux: Recheck state after unlocking mutex. After dropping the splitmux lock, re-check the state, don't just fall through and sleep unconditionally, as we may have already missed the wakeup. https://bugzilla.gnome.org/show_bug.cgi?id=769514