Hello All.
 
We are having a following scenario with playbin3 in our TV target.
  
Audio and Video data are fed separately by elementary stream(ES) and so we are using 2 of appsrc elements.
  
But, one of them for our test cases has valid audio stream and non-valid video stream.
  
So, we are expecting playbin3 pipeline is destroyed after non-valid stream for video is detected and appsrc(basesre) changes from PAUSED to READY.
 
However, at that time, pipeline is hanging up.
Deadlock is happened while pipeline tries from PAUSED to READY.
  
Following is backtrace. (Our GST version is based on 1.8)

==============================================
[Switching to thread 8 (Thread 0x71434400 (LWP 24343))]

+ Trace 236761

  
From this backtrace, I confirmed that GST_PLAY_BIN3_LOCK (playbin) is called as twice and GST_PLAY_BIN3_UNLOCK (playbin) is not called as well.
 
Let me explain lock sequence.
1) GST_PLAY_BIN3_LOCK (playbin) is called in setup_next_source ().
2) gst_element_set_state (urisrcbin, target) is not returned in activate_group (). Thus, GST_PLAY_BIN3_UNLOCK (playbin) is not called in setup_next_source ().
3) GST_PLAY_BIN3_LOCK (playbin) is called again in gst_play_bin3_handle_message () to handle GST_MESSAGE_STREAM_COLLECTION.
(Actually, we are adding code to post collection msg in qtdemux)
 
So, dead lock is happened in plybin3 and gst_pad_stop_task of basesrc(audio) is also stucked as they could not return the chain function after posting collection msg.