Yeah, I went with thingino today for two of my cameras as well. What ended up being the best solution for me was not relying on one source for everything.
When I had most cameras on the Wyze RTSP, it was a nightmare. When I had most on wyze docker bridge, it was a nightmare. Once I added thingino, they were sort of spread out - two on thingino, three on wyze RTSP firmware, 3 on wyze bridge. It’s been pretty stable now.
It doesn’t hurt that I spent two days completely optimizing the hell out of my entire setup and adding some custom failovers. What’s worse is I’m probably replacing my entire setup with local PoE cameras in around a week, decided I’m just going to take the time to finally do it the right way and be done with it forever, which means I didn’t even really need to dedicate so much time to this… alas, when I have a tech problem I can’t help but bash my head against a wall until I solve it.
Oh, and regarding the go2rtc stream failover - it’s really cool and is probably what helped the most when it came to stabilizing things: When a camera stream goes down and doesn’t immediately come back up, go2rtc stops sending video data which causes Frigate to error out with the default “black screen and error message” display. With this change, instead of that black screen/error when a camera stream fails Frigate shows a “fake” stream of your choice (a color, a picture, a video file you’ve saved locally on repeat - anything you want. I went with a solid blue background, that classic “tv error/no input found” color.) It’s a real go2rtc stream but doesn’t actually reference any video data; it consists of an exec call to ffmpeg that creates a new video stream of, in my case, just “full screen blue.”
Any time go2rtc sees that a video stream it’s watching has gone down, it no longer stops sending video data to frigate - instead, it immediately switches over to the “fake” video data we’re generating (my blue background) and continues on, sending that data instead, and Frigate never realizes anything went down; it never stopped receiving video data and happily keeps continues displaying the stream, now a solid blue background, not knowing the difference. When go2rtc sees the real camera stream come back online, it stops sending the “fake” video data and starts sending the real stream again and on Frigate’s side the filler blue background goes away and the camera feed pops up agian.
Because the stream has never stopped from Frigate’s perspective, there was no error. Normally, when there’s an error/stream failure, ffmpeg crashes and Frigate starts it up again. If the stream is still down, ffmpeg crashes again and this repeats over and over until the stream is back up. With our setup, it completely stops this loop of ffmpeg crashing and starting and crashing that would normally go on over and over again until a failed stream started working again. Ffmpeg constantly starting/crashing/starting like that uses a ton of resources - like, “you can hear your server fans spinning up from the other room” resources. It was also one of the main sources of instability for me, and now that’s fixed.
end post that is way too long
edit: dont do what I did there’s probably a right way to fix these problems that’s way easier, I just spent so long on it I needed the catharsis of explaining it to somebody
