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.

diff --git a/gst/multifile/gstsplitmuxsink.c b/gst/multifile/gstsplitmuxsink.c
index 9a2692e..07ac307 100644 (file)
--- 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 ?