Created attachment 307744 [details]
Test program showing the freeze

I stumbled upon a curious problem the other day. I set up a pipeline with a concat element, a sink (can be a fakesink, but sync is set to TRUE), two uridecodebins, two identity elements. The link order goes like this:

uridecodebin1 *-> identity1 -> concat  uridecodebin2 *-> identity2 -> concat  concat -> sink

The uridecodebin-identity connections are marked with a * , since these are not linked immediately. Instead, they are linked in the decodebin's pad-added callback. Only audio is linked.

This is a simple pipeline. Once uridecodebin1 is done playing, uridecodebin2 would take over. Works fine.

However, if I set the pipeline state to NULL immediately after having set it to PLAYING, it sometimes hangs in the gst_element_set_state(pipeline, GST_STATE_NULL); call. It might take quite a while for this deadlock to appear, but it eventually does. A quick check with gdb shows this:

+ Trace 235289

I am using the most recent git master (I checked the repositories out yesterday). I also managed to replicate the problem with a small test case, which I attached. It requires one argument, a URI to an audio file. (It has to be an URI, so use file:// ). Most of the time, the deadlock occurs within 30 seconds. I was most successful at replicating it by playing Ogg Vorbis files.

Now, perhaps I am using the uridecodebins incorrectly. I noticed in the playbin code that when shutting down, the playbin is applying all sorts of state locks to the uridecodebin elements and flags to early-exit pad-added callbacks, so maybe I need some of that logic here too.

Also, in uridecodebin, I set async-handling to TRUE, since I need that in my main application to avoid PAUSED states "leaking" into the main pipeline and disrupting gapless playback. I noticed that playbin does that differently; it checks for ASYNC_START and ASYNC_DONE messages, and if these came from uridecodebins, the messages are discarded. Not sure if this is the better approach, or if async-handling=TRUE is at least partially responsible for the problems. I tried running it with async-handling=FALSE, and it didn't change much - the deadlocks still happened.