I'm working on restarting the rtspsrc element when there is a disconnection
from the rtsp server. I power cycle my IP camera that the rtspsrc is
pulling from, then the rtspsrc is paused->null->ready->playing. I then
relink the rtspsrc pad to the next element's sink (rtph264depay- link is
gone after power cycling and bringing rtspsrc through the state changes).
This is where i expect the video streams to restart but they remain frozen.
I then went through step by step and added blocking probes to each element
in the pipeline. The streaming data passes through each element fine until
it reaches the tee element (named "rtsp_Home" below)...when I add the probe
to the tee's sink (and drop all buffers), I can see the data is flowing to
it perfectly fine. When I move on to adding it to the tee's two src pads (I
add the probe to both and attempt to drop all buffers as I had done in
previous steps), however, the pipeline's stream stops abruptly. From these
little experiments it seems like there is an issue between the data flow of
the tee's sink pad to it's source pads.
This is peculiar to me because I was expecting to find one of the tee's
branches to be the issue which was causing the queues to back up. Does
anyone have any clue as to what the issue could be between the tee's sink
pad and it's source pads?
Here is my pipeline:
rtspsrc debug=true retry=200 timeout=0 latency=1000 ntp-sync=false
drop-on-latency=false max-size-buffers=2000 max-size-bytes=6144000
max-size-time=1000000000 probation=200 do-retransmission=true
max-rtcp-rtp-time-diff=-1 name=rtsp_Home udp-buffer-size=6144000
rtph264depay name=branch_rtsp_Home ! h264parse ! decodebin ! videoconvert !
cairooverlay name=overlay ! videoconvert ! tee name=t allow-not-linked=1 t.
! queue2 ! autovideosink name=prim