-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow constant connection to cameras #1444
Comments
Just constant connection won't help. Your camera probably has a very rare keyframe. This means it needs to hold some sort of buffer and send frames from it to every new connection. This task has been around for a long time and it's quite complex. Perhaps in the future such a thing will appear. But not anytime soon. |
If one consumer is connected to the camera stream with the specified problem in go2rtc, the second consumer receives the stream faster. It would be nice to be able to establish a connection at startup and maintain it until the application stops. The problem of the key frame itself simply disappears here |
This has been discuss before but ya it is obvious when there is already a stream from a camera running that additional streams connect/start faster. I previously propose that a dummy consumer that just sent the video to dev null might be a dumb way to implement it.
While this is true for some cameras I believe the primary issue we are experiencing is the VERY slow initial connection time of some cameras when the first stream triggers a connection to the camera. Not just the key frame issue. |
I've never seen a camera with a slow initial connection. I've only seen cameras that either start the stream from the keyframe and then you're fine. Or they don't start and then you will see a delayed picture. |
Connecting VLC to the go2rtc RTSP address. Reolink WiFi Doorbell, no active connections to the substream. Connection 1 2seconds Reolink E1 outdoor Pro sub stream Connection 1 2s I would have to reconfigure things substantially or setup another test instance but there is always a very measurable delay in the fist connection vs any additional connections that join an actively connected camera. Mind you most of my cameras are not that problematic or slow any more, it was a bigger deal on my older cameras. My reolinks are currently set to 1x for I frame so they do respond fairly fast as it is. I do suspect the less than 1 second variance for additional connections is due to the i frames. In all cases if I disconnect all streams and let it return to 0, the FIRST stream aways takes at least 2 seconds which I suspect is ether connection or stream setup overhead. |
So I shut down frigate and cleared all of my camera connections and set up a clean 1.9.6 and re ran the test. Initial connections where just as fast as additional connections.. Maybe it is a frigate thing adding extra latency to the initial connections? or maybe it is slower when there are already a lot of connections. At any rate I thought I would report that I could not replicate the delay on an independent instance of go2rtc. |
The beginning of your test is instantly wrong. VLC is not the best software for real time testing. With the default settings, it will have quite a bit of lag on all cameras. |
There are cameras that take a long time to establish a connection (5-10 seconds). If the stream is established and does not break, then the connection to them occurs quickly. Is it possible to make an on demand option as it is done in rtsp2web?
The text was updated successfully, but these errors were encountered: