ffmpeg crashing intermittently with go2rtc restream and multiple RTSP cameras (Coral PCIe + HAOS + Frigate Add-on) #17311
Replies: 2 comments 1 reply
-
Sorry, I just found this. I should have searched more before asking. ![]() |
Beta Was this translation helpful? Give feedback.
-
Hi everyone, I tried solving the ffmpeg instability issues following the suggestions in the Frigate FAQ. I tested the following: ffmpeg: ffmpeg: Unfortunately, none of them worked properly. The camera feeds keep disappearing and reappearing, and the logs are full of errors. The instability seems to affect all streams, and the ffmpeg processes are constantly crashing and restarting. What's interesting is that I have other Home Assistant setups running on the same hardware (Beelink EQ13, Coral PCIe, Intelbras IP cameras – OEM Dahua, HAOS), and everything works perfectly there. Logs show a lot of RTP: PT=60: bad cseq errors and timeouts from go2rtc. I've attached the full logs for reference. nginx-logs (4).txt Any ideas on what could be causing this difference in behavior across identical systems? Thanks in advance! |
Beta Was this translation helpful? Give feedback.
-
Hi team,
I'm running the Frigate Add-on (Full Access) on Home Assistant OS and experiencing intermittent ffmpeg crashes after a short period of normal operation.
Setup:
HAOS on Beelink EQ13
Frigate Add-on Full Access (0.15-1), tested on both Beta and Stable
Coral Edge TPU via PCIe (pci:0)
9 Intelbras IP cameras (possibly Dahua OEM)
Using go2rtc with preset-rtsp-restream (main = record, sub = detect)
Issue:
Frigate starts normally, all streams load and detection works
After some time, ffmpeg processes crash with:
RTP: PT=60: bad cseq ...
hwdownload @ ... Failed to download frame: -5
ffmpeg process is not running. exiting capture thread...
Cameras show no frames received
go2rtc logs show repeated i/o timeout errors
The issue is intermittent — sometimes I stop Frigate, restart it, and everything works fine again for a while. But the problem eventually comes back.
Meanwhile, the same cameras remain fully accessible via their mobile/cloud app, and RTSP works fine when tested in VLC
What I’ve tried:
Verified RTSP streams manually in VLC — all work fine
Disabled external access — issue still occurs
Tested with both beta and stable versions of the addon
Using substreams (704x480 @ 5 FPS) for detection
Questions:
Is this a known issue related to ffmpeg or go2rtc restreaming?
Any suggestions to improve stream stability in this setup?
Configuration (partial):
detectors:
coral:
type: edgetpu
device: pci:0
mqtt:
host: 192.168.1.2
port: 1883
topic_prefix: frigate
client_id: frigate
user: XXXX
password: XXXX
ffmpeg:
hwaccel_args: preset-vaapi
detect:
width: 704
height: 480
fps: 5
enabled: true
go2rtc:
streams:
Km253_cam1_principal:
- rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=0
Km253_cam1_sub:
- rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=1
# ... (similar for Km253_cam2 to Km253_cam9)
cameras:
Km253_cam1:
ffmpeg:
inputs:
- path: rtsp://127.0.0.1:8554/Km253_cam1_principal
input_args: preset-rtsp-restream
roles:
- record
- path: rtsp://127.0.0.1:8554/Km253_cam1_sub
input_args: preset-rtsp-restream
roles:
- detect
motion:
improve_contrast: true
objects:
track:
- person
filters:
person:
min_score: 0.55
threshold: 0.7
min_ratio: 0.3
max_ratio: 1.0
# ... (similar blocks for Km253_cam2 to Km253_cam9)
Let me know if you need full logs — I have them ready.
Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions