NickM-27
commented
9 months ago What are the go2rtc logs
Closed aaronneid closed 9 months ago
NickM-27
commented
9 months ago What are the go2rtc logs
aaronneid
commented
9 months ago 2024-02-05 23:34:53.385675887 [INFO] Preparing new go2rtc config... 2024-02-05 23:34:53.430232058 [INFO] Got IP address from supervisor: 192.168.1.87 2024-02-05 23:34:53.471222590 [INFO] Got WebRTC port from supervisor: 8555 2024-02-05 23:34:53.737124715 [INFO] Starting go2rtc... 2024-02-05 23:34:53.828294510 17:34:53.828 INF go2rtc version 1.8.4 linux/amd64 2024-02-05 23:34:53.828769235 17:34:53.828 INF [rtsp] listen addr=:8554 2024-02-05 23:34:53.828837195 17:34:53.828 INF [api] listen addr=:1984 2024-02-05 23:34:53.829154882 17:34:53.828 INF [webrtc] listen addr=:8555 2024-02-05 23:35:03.387124299 [INFO] Starting go2rtc healthcheck service...
andregoncalvespires
commented
9 months ago I also have this problem with the doorbell, but after a while it starts to work.
raven-2014
commented
9 months ago I have the same issue .... after moving to frigate 13. Everything worked fine with version 12. The issue does not exist, when using RTSP for the substream instead of http. But with RTSP, the lag of the webrtc live stream does grow to completely unacceptable levels, the longer frigate is up. With restarting frigate, lags are acceptable ... but then start to creep up again.
Eloston
commented
9 months ago Contrary to the documentation, I'm also finding that RTSP is more stable than HTTP-FLV over WiFi (with go2rtc streaming).
I have a E1 Zoom (IPC_515BSD6) and Video Doorbell WiFi both running latest firmware over 5GHz WiFi. I'm finding that with HTTP-FLV, the stream crashes quite often (around once every 10 mins), even for the E1 Zoom which has direct line-of-sight to the WiFi router. So I switched to RTSP for about a day thus far, and FFMPEG has only crashed once. In addition, I haven't experienced any visual glitches or lag with RTSP, compared to my experience with older firmware on the E1 Zoom.
I should add that Frigate 0.13.x forced me to investigate RTSP. On Frigate 0.12.x, HTTP-FLV is more stable than it is on 0.13.x (possibly due to go2rtc update), similar to what @raven-2014 experienced.
I believe we should add RTSP as a viable option to the Frigate docs for Reolink cameras, especially those with more recent firmware (released 2023).
raven-2014
commented
9 months ago @Eloston I find it interesting, that you do not experience any lag with the RTSP stream. As I mentioned, after restarting Frigate, the lag for me is ok annd similar to the HTTP-FLV stream. But it steadily grows and after one day, it is at about 10 seconds. Could you share your config for the RTSP stream of an E1 Zoom? I like to understand what drives my lag up over time. thanks.
NickM-27
commented
9 months ago I believe we should add RTSP as a viable option to the Frigate docs for Reolink cameras, especially those with more recent firmware (released 2023).
I have a reolink doorbell on the august 2023 firmware and the rtsp stream has a skip that occurs on every iframe. I still see many users that have issues with the doorbell where http-flv fixes it.
It sounds like you may have not had http-flv setup correctly in go2rtc based on your description of the issue. The docs recommend using ffmpeg in the go2rtc config and that has not chnaged since 0.12 but if you weren't using the ffmpeg: prefix then there are known issues with that in go2rtc
raven-2014
commented
9 months ago @NickM-27 thank you very much! The "ffmpeg:" prefix in front of the http stream definition did the trick for me. It has worked over the last 24 hours flawlessly, without crashes or lag-buildup.
Now, I am just struggling with 2-way audio on my reolink cams (doorbell and E1zoom). I have the mic button on the frigate card and it turns red ... there is a respective conumer entry in the go2rtc stream info ... but still no sound coming out of the camera. But I guess this is a different topic.
aaronneid
commented
9 months ago @NickM-27 Just wanted to update you on this. The issue was intermittent when I was setting up the system. Sometime I would restart frigate without making any changes to the config and it would work and sometimes it would error out. Power cycling the camera itself seemed to be the most reliable way of getting the stream to work without errors until the next frigate restart. For reference my camera is wifi but is about two feet away from the router and in direct line of sight. After getting everything setup and power cycling the camera, I haven't noticed any crashes in frigate and everything seems to be running smoothly.
Eloston
commented
9 months ago The docs recommend using ffmpeg in the go2rtc config and that has not chnaged since 0.12 but if you weren't using the ffmpeg: prefix then there are known issues with that in go2rtc
@NickM-27 Ah thanks for clarifying. I focused more on the description above the config sample, and thought the ffmpeg: prefix was unnecessary. In that case I think that's worth emphasizing in the docs, since both me and @raven-2014 missed it.
I have a reolink doorbell on the august 2023 firmware and the rtsp stream has a skip that occurs on every iframe. I still see many users that have issues with the doorbell where http-flv fixes it.
Interesting. I've had my setup running continuously since my last message. There have been no issues; no errors have occurred, and no jumps in the live nor recorded clips. Both cameras have a consistent 1-2 second delay.
For the doorbell I also set a fixed frame rate and set the interframe space to 1x. Not sure if they're helping with the stability.
As for the config, it's quite standard. The relevant bits (with redactions):
go2rtc:
rtsp:
[...]
streams:
e1zoom:
- rtsp://[...]@e1zoom:554/h264Preview_01_main # H264 with AAC
- "ffmpeg:e1zoom#audio=opus"
doorbell:
- rtsp://[...]@doorbell.lan:554/h264Preview_01_main # H264 with AAC
- "ffmpeg:doorbell#audio=opus"
webrtc:
candidates:
- [...]:8555
cameras:
e1zoom:
ffmpeg:
inputs:
- path: rtsp://127.0.0.1:8554/e1zoom
input_args: preset-rtsp-restream
roles:
- detect
- record
hwaccel_args: preset-vaapi
onvif:
[...]
motion:
mask:
- 450,36,827,36,827,0,450,0
doorbell:
ffmpeg:
inputs:
- path: rtsp://127.0.0.1:8554/doorbell
input_args: preset-rtsp-restream
roles:
- detect
- record
hwaccel_args: preset-vaapi
motion:
threshold: 40
mask:
- 450,36,827,36,827,0,450,0
# Switching to CPU re-scaling is actually more efficient for me than using a re-scaled go2rtc stream with VA-API (somehow I got ~80% GPU usage on my Intel iGPU)
# But I have not re-tested with HTTP-FLV with the ffmpeg: prefix nor with RTSP since CPU scaling is efficient enough for me
detect:
enabled: true
fps: 5
width: 1280
height: 960
Describe the problem you are having
I'm using the example config from the Camera Specific Configuration page for reolink cameras. When setting the sub stream to the detect role, ffmpeg crashes with the error message "Invalid data found when processing input" and the stream fails to load. I don't get the error message if I only use the main stream or if I set the main stream to detect and the sub stream to record.
Version
0.13.1-34fb1c2
Frigate config file
Relevant log output
Frigate stats
No response
Operating system
HassOS
Install method
HassOS Addon
Coral version
CPU (no coral)
Any other information that may be helpful
No response