rtspsrc - Deadlock after src creates 100s of streaming threads

logidelic bill at orbit.org
Sun Nov 3 15:28:52 UTC 2019


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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191103/df6d21c8/attachment.html>


More information about the gstreamer-devel mailing list