Reolink E1Zoom go2rtc using webrtc increasing latency over time

Configuration
1

I am new to home assistant and frigate, just started to work with it over the last month or so.
I exprience an increase in latency the longer frigate runs. after a restart of frigate, I have subsecond latency on the video of my webrtc live-stream (both in the frigate ui, as well as in the hass frigate card). A few hours later, when I start the live streaam again, latency increases to multiple seconds (5 to 10 seconds).
audio stays fine though - no increase in latency here.
I run frigate and home assistant in docker on a dell optiplex i3.
live stream is 4 fps - 640x480
go2rtc / rtsp streaming is used
object and motion detection are both OFF.
cpu usage on the optiplex is around 5 - 10%, memory usage is about 25% (of 8 GB).

Where do I need to look to get to the root cause? I am very thankfull for suggestions!
thank you very much.

2

What version of go2rtc are you running? The default in frigate or have you upgraded it?

If you are running the default version then go2rtc can’t have latency as it is using UDP, the only explanation for latency would be latency from the cameras.

3

thanks for your input.
I use the frigate version.
I use a reolink E1Zoom camera. there is no latency in the reolink camera app itself, initially after restart of frigate there is no latency in the frigate UI and in the HASS frigate card either, but only after running the frigate container for some time (hours) the latency is building up.

4

The reolink app uses entirely different protocol for communication so that is mostly irrelevant. UDP can have dropped frames but it can’t have delay so it will be coming from the network or the camera.

You can try to upgrade go2rtc to see if it makes a difference Advanced Options | Frigate

5

ok. Just to help me understand some of the technicalities… why is latency perfectly fine after a restart of frigate and then after letting the container run for some time, it starts to degrade? what is actually being “reset” with a frigate restart, so that latency is completely fine after such a restart?
thanks for being patient with me :blush:

6

I don’t know that answer otherwise the answer / solution would be more clear. All I am saying is that the latency can’t come from WebRTC itself.

It depends how you have it setup but it could be some issue with the fact that frigate has been connected to the camera for hours which has bogged it down / increased its memory usage and restarting frigate resets that.

Or if you are using the restream as frigate’s camera source then maybe the connection is experiencing latency (does frigate detect process see any latency during this?)

all in all, I’d suggest updating go2rtc as that should help with other things if not this

7

thanks for being so responsive.
As I am not really an advanced Linux user, I am hesitent to tinker with the system too much, the frigate docu for upgrading go2rtc does not tell me exactly what to do. Are there plans to upgrade go2rtc within the standard frigate container some time soon?

8

in the meantime I tested some additional things out.

  • upgraded the firmware of the reolink camera to latest version - no difference
  • installed WEBRTC Camera, confirmed that this is using go2rtc version 1.5.0 - tested webrtc with the go2rtc GUI (port 1984) - no difference

situation is:

  • immediately after restarting frigate (go2rtc) the latency is subsecond
  • after about 10 hours, the latency moved up to about 12 seconds, irrespective of the go2rtc version or type of frontend GUI I use.

Does anyone have the reolink E1Zoom running with webrtc and stable / constant latency? If so, I would really like to compare configurations.

thanks.

9

There would be no way to do that, each user will have different instructions based on their install

It has been updated for 0.13

10

@raven14

Did you find a solution yet? I have a Outdoor E1 camera and I have the exact same issue. I’ve tried everything, but the only thing that resets the delay is to restart frigate. I’ve spend hours on this, compared all settings to a friend of mine who also has a Reolink cam but doesn’t experience the same issue. Even after matching all settings in frigate.yaml the issue seems to persist.

Both of us are using Raspberry pi 4.

This is my frigate.yaml:

mqtt:
  host: 192.168.1.X
  user: foo
  password: bar

detectors:
  coral:
    type: edgetpu
    device: usb

go2rtc:
  streams:
    front_door:
      - rtsp://foo:[email protected]:554/h264Preview_01_main
      - "ffmpeg:front_door#audio=opus"
    front_door_sub:
      - rtsp://foo:[email protected]:554/h264Preview_01_sub
      - "ffmpeg:front_door_sub#audio=opus"

cameras:
  front_door:
    ffmpeg:
      input_args: -rtsp_transport tcp
      output_args:
        record: preset-record-generic-audio-aac
      inputs:
        - path: rtsp://127.0.0.1:8554/front_door
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/front_door_sub
          roles:
            - detect
    objects:
      track:
        - person
    detect:
      enabled: True
      width: 640
      height: 480

record:
  enabled: True
  events:
    retain:
      default: 5

birdseye:
  enabled: False
11

@raven14 I might have found a solution that removed all latency from my E1 Outdoor.
Instead of using the h264 streams I changed my config to this:

1 Like
12

This beta firmware solved my latency problems:

https://support-d.reolink.com/attachments/token/qeiDu1OiQ7seikb5cUvzRWVew/?name=IPC_523SD8.2109_23082407.E1-Outdoor.OV05A10.5MP.WIFI1021.PTZ.REOLINK.pak

13

Also experiencing the same video drift over time with a RLC-833A on firmware
v3.1.0.1648_22122727. Restreaming to frigate from go2rtc. Audio remains on target always, within half a second. Just the video feed is the issue.

Seems to drift as much as 1 full second every hour. I left it running overnight and it was up to 13 seconds over RTSP, and appears to drift the same with ONVIF.

Trying to reduce the interframe space to 1x from 2x [clear] / 4x [fluent] as mentioned in what @NeoID posted. Would like to avoid RTMP [port 1935] as that incurs a ~2-4 second delay of its own.

I am also now testing a VLC session streaming directly from the camera feed to see if it also begins to drift as well. This should narrow down if it’s something to do with go2rtc/frigate or Reolink’s firmware/settings.

14

An update on this for anyone who stumbles across the thread… the http/flv stream appears to have no video drift and with subsecond delay. This is the same stream that the Reolink Client application uses. I’m currently testing an updated firmware for Reolink support that they’re asking if it fixes the RTSP/ONVIF drift. But here are the working streams to use in go2rtc for a RLC-833A, operating at a reduced 1440p/2K resolution so that it outputs as h264 instead of h265 (other Reolink cameras likely similar):

Clear/High:
- "ffmpeg:http://<ip_address_of_camera>/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=<username>&password=<password>#video=copy#audio=copy#audio=opus"
Mid:
- "ffmpeg:http://<ip_address_of_camera>/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user=<username>&password=<password>#video=copy#audio=copy#audio=opus"
Low/Fluent:
- "ffmpeg:http://<ip_address_of_camera>/flv?port=1935&app=bcs&stream=channel0_sub.bcs&user=<username>&password=<password>#video=copy#audio=copy#audio=opus"

1 Like
15

If it helps, I encountered this problem on some of my reolink cameras.
Increasing video latency problems in webRTC were due to the frame rate parameter which was not set to “constant” in the camera’s video stream settings.