[Bug 755400] New: splitmuxsink: deadlocks when inserted into running pipeline

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755400

            Bug ID: 755400
           Summary: splitmuxsink: deadlocks when inserted into running
                    pipeline
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: knorr.jesper at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 311839
  --> https://bugzilla.gnome.org/attachment.cgi?id=311839&action=edit
test case

Inserting splitmuxsink into a running pipeline causes a deadlock for the
configuration described here.
The use case is to have a live source of video+audio running continuously, with
the possibility of starting a recording using splitmuxsink. 

A test case is provided as an attachment.

The initial pipeline is as follows:

audiotestsrc is-live=true ! faac ! aacparse ! audio/mpeg,stream-format=raw !
queue ! fakesink
videotestsrc is-live=true ! x264enc key-int-max=10 ! h264parse !
video/x-h264,alignment=au,stream-format=avc ! queue ! fakesink

After 10s blocking pad probes are installed on the src pads of the two queues.
The fakesinks are removed from the pipeline, and a new splitmuxsink is created
and inserted.
The state of the splitmuxsink is set to PLAYING, and the block probes are
removed.

A few buffers are received on the sinkpad of the multiqueue inside the
splitmuxsink, but then dataflow stops.

Using GDB, I can see that the streaming thread of the audio queue srcpad is
waiting in gstsplitmuxsink.c:1071

          GST_LOG_OBJECT (pad, "Sleeping for GOP start");
------>   GST_SPLITMUX_WAIT (splitmux);
          GST_LOG_OBJECT (pad, "Done sleeping for GOP start state now %d",
              splitmux->state);

The thread for the video src pad is waiting in gstmultiqueue.c:1938 with an
allocation type query.

1925           GST_DEBUG_OBJECT (mq,
1926               "SingleQueue %d : Enqueuing query %p of type %s with id %d",
1927               sq->id, query, GST_QUERY_TYPE_NAME (query), curid);
1928           GST_MULTI_QUEUE_MUTEX_UNLOCK (mq);
1929           res = gst_data_queue_push (sq->queue, (GstDataQueueItem *)
item);
1930           GST_MULTI_QUEUE_MUTEX_LOCK (mq);
1931           /* it might be that the query has been taken out of the queue
1932            * while we were unlocked. So, we need to check if the last
1933            * handled query is the same one than the one we just
1934            * pushed. If it is, we don't need to wait for the condition
1935            * variable, otherwise we wait for the condition variable to
1936            * be signaled. */
1937           if (sq->last_handled_query != query)
1938             g_cond_wait (&sq->query_handled, &mq->qlock);

For debugging purposes, I tried dropping any allocation queries on the srcpads
of the queues. This changes the behaviour a bit. A few more buffers reaches the
multiqueue, but dataflow still stalls.

The audio streaming thread still stalls waiting for GOP complete. The video
thread is waiting in gstdataqueue.c:520, which seems to indicate that the queue
is full. Several GOPs are queued, but the output file is still empty.

The tests have been done using 1.5.91. Pipeline works just fine if the
splitmuxsink is used from the beginning instead of the fakesinks.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.