From a930a1364a045a11802054c258c4ddddf5f562b1 Mon Sep 17 00:00:00 2001 From: Thiago Santos Date: Mon, 3 Aug 2015 13:42:20 -0300 Subject: [PATCH] splitmuxsink: prevent deadlock when states change too fast If the GOP is completed, pads have to start gathering for the next one but it is possible that the the state might go to COLLECTING_GOP_START and back to WAITING_GOP_COMPLETE before the thread has a chance to wake up and proceed, leaving it trapped in the check_completed_gop loop and deadlocking the other threads waiting for it to advance. To solve it, this patch also checks that tha input running time hasn't changed to prevent this scenario. --- gst/multifile/gstsplitmuxsink.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gst/multifile/gstsplitmuxsink.c b/gst/multifile/gstsplitmuxsink.c index 9a2692e4f9..07ac30780b 100644 --- a/gst/multifile/gstsplitmuxsink.c +++ b/gst/multifile/gstsplitmuxsink.c @@ -832,6 +832,7 @@ check_completed_gop (GstSplitMuxSink * splitmux, MqStreamCtx * ctx) { GList *cur; gboolean ready = TRUE; + GstClockTime current_max_in_running_time; if (splitmux->state == SPLITMUX_STATE_WAITING_GOP_COMPLETE) { /* Iterate each pad, and check that the input running time is at least @@ -865,9 +866,11 @@ check_completed_gop (GstSplitMuxSink * splitmux, MqStreamCtx * ctx) /* Some pad is not yet ready, or GOP is being pushed * either way, sleep and wait to get woken */ + current_max_in_running_time = splitmux->max_in_running_time; while ((splitmux->state == SPLITMUX_STATE_WAITING_GOP_COMPLETE || splitmux->state == SPLITMUX_STATE_START_NEXT_FRAGMENT) && - !ctx->flushing) { + !ctx->flushing && + (current_max_in_running_time == splitmux->max_in_running_time)) { GST_LOG_OBJECT (splitmux, "Sleeping for %s (ctx %p)", splitmux->state == SPLITMUX_STATE_WAITING_GOP_COMPLETE ?