splitmuxsink: deadlocks when inserted into running pipeline
Submitted by Jesper Larsen
Created attachment 311839
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",
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.
Attachment 311839, "test case":