I'm trying to understand what
fallbacksrc does and whether it can target my use case. I want to become tolerant to unreliable rtsp sources (multiple) that:
- might not be available on init
- might go down during processing
To that end, I compiled the
fallbacksrc element on gstreamer v1.45.
With an rtsp server up, I tried the following gst-launch:
gst-launch-1.0 fallbacksrc restart_on_eos=true uri=<input_uri> ! nvvideoconvert ! x264enc ! video/x-h264, mapping=/stream1 ! rtspclientsink protocols=tcp location=<output_uri>
I observed that:
- It plays well if everything is in order, i.e. the source is up
- It goes to 240p black if the source is disconnected from the server (I needed to supply
restart_on_eosso that the pipeline does not stop)
- It goes from black to source if the source was not available at init but becomes available afterwards.
- It does not recover when the source goes down and up again, keeping the black output and continuously trying to reconnect (a read connection is established on the rtsp server, which is dropped immediately).
So, the questions are:
- Does the described behavior fit the intended use of
- Do I actually need the
fallbacksrcif all I wanted to do is remove the failed source, while the others keep playing? I guess adding/removing elements dynamically is not the same, with the difference being an error being emitted on failure which makes the pipeline wait forever.
- I did not find any, but I may as well ask, whether there are any signals from
fallbacksrcthat notify the app of its state.