Stream Transport stops after roughly a day

Having sucessfully connected 4 Dahua Cameras to the UDM Pro I am facing an issue where the video stream to the UDM PRO stops after roughly 20-24 hours while the unifi-cam-proxy tool still is running without any noticeable error message. htop shows the correct amount of ffmpeg sessions but no image is being delivered to the UDM PRO. The cameras are marked as “online” in the unifi protect app but no live feed can be shown and no recording is available.

Restarting the unifi-cam-proxy process resumes operation immediately. sometimes i have days of uninterrupted service, then one cam fails, sometimes all cams fail.

Right now one of four cams has failed about 8 hours ago. htop lists the following processes for this cams ip:

/bin/sh -c ffmpeg -nostdin -y -rtsp_transport tcp -i "rtsp://XXX:xxx@192.168.0.25:554" -c:v copy -c:a copy -metadata streamname=GNkzuUYLpPGrxEcJ -f flv - | /usr/bin/python3.8 -m unifi.clock_sync | nc 192.168.0.254 7550
/bin/sh -c ffmpeg -nostdin -y -rtsp_transport tcp -i "rtsp://XXX:xxx@192.168.0.25:554" -c:v copy -c:a copy -metadata streamname=HccAamgW2TSarR7U -f flv - | /usr/bin/python3.8 -m unifi.clock_sync | nc 192.168.0.254 7550
/bin/sh -c ffmpeg -nostdin -y -rtsp_transport tcp -i "rtsp://XXX:xxx@192.168.0.25:554" -c:v copy -c:a copy -metadata streamname=XqqOr6vKvFzmMYRn -f flv - | /usr/bin/python3.8 -m unifi.clock_sync | nc 192.168.0.254 7550
ffmpeg -nostdin -y -rtsp_transport tcp -i rtsp://XXX:xxx@192.168.0.25:554 -c:v copy -c:a copy -metadata streamname=GNkzuUYLpPGrxEcJ -f flv -
ffmpeg -nostdin -y -rtsp_transport tcp -i rtsp://XXX:xxx@192.168.0.25:554 -c:v copy -c:a copy -metadata streamname=XqqOr6vKvFzmMYRn -f flv -
ffmpeg -nostdin -y -re -rtsp_transport tcp -i rtsp://XXX:xxx@192.168.0.25:554 -vf fps=1 -update 1 /tmp/tmplmr1z60e/screen.jpg
ffmpeg -nostdin -y -rtsp_transport tcp -i rtsp://XXX:xxx@192.168.0.25:554 -c:v copy -c:a copy -metadata streamname=HccAamgW2TSarR7U -f flv -

In the “timelapse” view in unifi protect the camera area shows “Camera settings updated” with a red excalmation mark.

Noticeably the ffmpeg screenshot process hangs with zero CPU usage. Killing off the ffpmeg processes with the kill command resumes camera operation in unifi protect without the need to restart unifi-cam-proxy.

Can anyone please help to troubleshoot this? Is this a memory problem?

Also: can we provide a screenshot to unifiprotect with a dedicated jpeg url instead of the ffmpeg thingy? 😃

Thanks!! 👍

[keshavdv]

I’ve seen this happen when there’s a network hiccup and ffmpeg loses the source RTSP stream and never recovers. I’ll play around with some timeout flags to see if we can have ffmpeg kill itself if this happens which as you’ve found will force a new one to get recreated on the fly by the proxy. The dedicated snapshot endpoint was requested in #15 and is available in the ‘frigate’ branch immediately for testing and should be landing into main soon.

[keshavdv]

Adding --help after the implementation type should show all options:

$ ❯ unifi-cam-proxy rtsp --help
usage: unifi-cam-proxy rtsp [-h] [--ffmpeg-args FFMPEG_ARGS] [--rtsp-transport {tcp,udp,http,udp_multicast}] --source SOURCE [--http-api HTTP_API] [--snapshot-url SNAPSHOT_URL]

optional arguments:
  -h, --help            show this help message and exit
  --ffmpeg-args FFMPEG_ARGS, -f FFMPEG_ARGS
                        Transcoding args for `ffmpeg -i <src> <args> <dst>`
  --rtsp-transport {tcp,udp,http,udp_multicast}
                        RTSP transport protocol used by stream
  --source SOURCE, -s SOURCE
                        Stream source
  --http-api HTTP_API   Specify a port number to enable the HTTP API (default: disabled)
  --snapshot-url SNAPSHOT_URL, -i SNAPSHOT_URL
                        HTTP endpoint to fetch snapshot image from
$ ❯

The URL should be something that returns a jpeg encoded image and nothing else (e.g. http://admin:admin@<ip>/cgi-bin/snapshot.cgi for some camera models)