How to detect if rtsp source(camera) is active or not before the RTSP pipeline is started

General Discussion
1

Is there a quick way to check if the URL is active or not before the pipeline runs? Some cameras might be unplugged or stop working.

2

any ideas? Currently, my app waits for bus errors to come and then stops the pipeline. Kind of slow. Cameras are switched often and therefore better to have some quick handling of this scenario.

3

Which element(s) are you trying to use?

4

gst-launch-1.0 rtspsrc + vah264dec on Ubuntu 22.04

5

The quick answer is “no” I suppose, that there isn’t really a quick way to verify that the camera is going to respond. However, the way we utilize this element is:

  1. Create a simple state machine for managing if the rtspsrc is disconnected, connecting, failed to connect, or connected. When disconnected, it creates the element, attaches to signals, and sets it to the PLAYING state while the state machine goes to the “connecting” state. The “connecting” state waits to be notified that the connection either happened or it can timeout/fail, which would destroy the rtspsrc element and go back to the disconnected state to make a new one. If the connection happens (pad-added, below), the state machine goes to “connected” and waits to see if a timeout or intentional disconnect happens. If it’s an intentional disconnect, you remove the element from the pipeline. If it’s a timeout, you need a way to consume/handle the EOS that may be emitted out of the GstBaseSrc class, and then head back to the “connection failed” state (to delete the element and try the connection again).
  2. Attach to rtspsrc signal pad-added. The source pad will be added once the connection is made, so from that handler, you would get the caps for the stream and connect the pad to the appropriate part of your application. This signifies the connection having succeeded. You will probably want to attach a block event probe on that source pad to return HANDLED when an EOS comes through that you were not expecting. This will allow for reconnecting/resuming streaming if/when there is a connection loss.
  3. Attach to rtspsrc signal new-manager. This fires when a new manager, like rtpbin, is created (per the docs). The handler attaches to the manager’s on-sender-timeout signal. You would use this handler to determine if once connected it has disconnected unintentionally.

That’s the rough idea.

1 Like
6

Thanks a lot for your detailed reply. I will think about your ideas.

7

You’re welcome! My team uses this general design in production worldwide; it works pretty well. If you come up with a cleaner way to integrate this into an application, please do post it! I am always curious to see other solutions, especially when what we’re doing involves having to dig into the element to adequately handle error states like timing out, which has been the main challenge when dealing with certain client network configuration needs.

8

One option would be to run onvif on the server side which is able to detect which cameras are active or not. As you know, all cameras are onvif compatible nowadays.

9

One other question: do you guys create a new pipeline or simply replace rtspsrc in camera switch?

10

Yes, last year I did briefly look at incorporating lumeohq/onvif-rs into a new Rust-based plugin so that we could use wsdisovery to locate active cameras, perhaps read properties, and then present that to the GStreamer application through the GstDeviceMonitor. I ran out of bandwidth pretty quickly to keep working on that project however, though I do plan to pick it back up once I can find the time. We already maintain connections to some other source devices (USB ones, typically) using that functionality, and it works well, so migrating all of our sources into the more generic GstDevice interface feels like a good move.

As far as how our application works right now with respect this source type though, we rip and replace the rtspsrc every time it disconnects because taking it to the NULL state and then back to PLAYING wasn’t as reliable in that regard. The pipeline it was in remains, however, as do all the consuming branches within it.

Design wise, we’ve been gravitating towards using the rsinter plugin elements (source and sink) for switching our single monolithic pipeline into a more modular design of source, filter, and sink pipelines. In testing, it was significantly more stable and resilient to ad hoc changes (adding and removing branches that “consume” from the source producer(s)).

11

Onvif can be very helpful at start-up of the server since some cameras might not be available. Cameras take longer time to start than other devices.

We do not clear the pipeline when cameras are disconnected. Deletion of the rtsp pipeline still has some memory leak in gstreamer(1.22.5). About 250 switches of 4 cameras will use up memory and cause freezing of the app.