I’m using Ubuntu 20.04 and stuck with using GStreamer 1.16.3 so guessing this patch doesn’t exist (rtspsrc: deadlock on set_state(NULL) (#900) · Issues · GStreamer / gst-plugins-good · GitLab).
Is there any sort of workaround for setting the rtspsrc element to the null state without deadlocking? I have a pipeline that runs some hardware decoding on rtsp streams and I want to dynamically remove the rtspsrc when a failure/error occurs.
In this case I am just trying to catch the “on-sender-timeout” signal from the rtpbin manager, then add an IDLE probe and perform the dynamic reconnect. Inside of the dynamic reconnect method:
# Remove the old rtspsrc
print('Unlinking and removal process...')
pad.unlink(pad_peer)
pad.unref()
source_bin.remove(rtspsrc)
children = manager.children
for child in children[0:-1]:
print(child, type(child))
child.set_state(Gst.State.NULL)
print('child set to null...')
print('nulling old rtspsrc')
rtspsrc.set_state(Gst.State.NULL)
rtspsrc.unref()
print('unlinking and removal done...')
The code hangs indefinitely at rtspsrc.set_state(Gst.State.NULL)
. I was looking at the linked issue and that is why I added the child iteration step, but that did not help. Also, when trying to set all child elements to NULL I recieve this error when attempting to set the RtpSession to NULL:
<__gi__.GstRtpSession object at 0x7f336ee24480 (GstRtpSession at 0x7f3368066140)> <class '__gi__.GstRtpSession'>
(python:73122): GLib-ERROR **: 15:41:15.402: file ../../../glib/gthread-posix.c: line 1353 (g_system_thread_wait): error 'Resource deadlock avoided' during 'pthread_join (pt->system_thread, NULL)'
Any options to get around this, or do things a different way? If I simply try to ignore the step for setting the state and unref() then I get the following error after the probe completes:
(python:74821): GStreamer-CRITICAL **: 16:10:57.198:
Trying to dispose element rtspsrc_0, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.
g_mutex_clear() called on uninitialised or locked mutex
Sorry for all the edits…
Could switching to uridecodebin/uridecodebin3 based pipeline work, assuming they are able to be set to Null when performing the dynamic changes?
Would additional elements be needed to mimic the function of rtspsrc (jitterbuffer, or other)?
Update: Using uridecodebin I notice that internally an rtspsrc element is created still. I also still seem to hit a deadlock when trying to null the uridecodebin.