I have a pipeline that uses an rtspsrc. Our program has been deployed in 1000s of different setups and seems to work perfectly in 99% of them. However in just a few deployments we have run into an issue that has stumped us.

Sometimes, due to network conditions, the rtspsrc stops processing new frames. This is, of course, normal. In this situation, we finally call <b>gst_element_set_state</b> to set the pipeline to NULL. In a few, rare cases, this call <b>blocks indefinitely</b>. Of course I am <i>not</i> making the gst_element_set_state call from a streaming thread.

Pouring through the bus logs for a clue, I noticed that, in the problematic case,100s of streaming threads were created (stream-status: create) before I attempted to shutdown the pipeline. In my non-deadlock case, I see only ~12 streaming threads created for the pipeline.  Could such a difference possibly be normal?

In any case, in the deadlock scenario I see that, of the 100s of streaming threads that were created for the pipeline, not quite all of them were destroyed (stream-status: leave). I guess this is a clue, but I'm unsure of how to debug it or narrow down what's going on...

Any help would be appreciated.


        
        
        
<br/><hr align="left" width="300" />
Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.<br/>