rtspsrc - Deadlock after src creates 100s of streaming threads

[logidelic]

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
*gst_element_set_state* to set the pipeline to NULL. In a few, rare cases,
this call *blocks indefinitely*. Of course I am /not/ 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.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/