Skip to content
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

Open
Biss81 opened this issue Nov 8, 2024 · 7 comments
Open

Allow constant connection to cameras #1444

Biss81 opened this issue Nov 8, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@Biss81
Copy link

Biss81 commented Nov 8, 2024

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?

@AlexxIT AlexxIT changed the title Allow On Demand rtps cameras stream Allow constant connection to cameras Nov 8, 2024
@AlexxIT AlexxIT added the enhancement New feature or request label Nov 8, 2024
@AlexxIT
Copy link
Owner

AlexxIT commented Nov 8, 2024

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.

@Biss81
Copy link
Author

Biss81 commented Nov 8, 2024

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

@bagobones
Copy link

If one consumer is connected to the camera stream with the specified problem in go2rtc, the second consumer receives the stream faster.

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.

Your camera probably has a very rare keyframe.

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.

@AlexxIT
Copy link
Owner

AlexxIT commented Nov 11, 2024

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.

@bagobones
Copy link

Connecting VLC to the go2rtc RTSP address.

Reolink WiFi Doorbell, no active connections to the substream.

Connection 1 2seconds
Connection 2 near instant. (faster than I can do with my finger on the stop watch.
Connection 3 1 second.

Reolink E1 outdoor Pro sub stream

Connection 1 2s
Connection 2 less than a second
Connection 3 1s

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.

@bagobones
Copy link

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.

@AlexxIT
Copy link
Owner

AlexxIT commented Nov 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants