search

QuantumEntangledAndy / neolink

An RTSP bridge to Reolink IP cameras
GNU Affero General Public License v3.0
257 stars 41 forks source link

Latency vs original version #132

Closed skylord123 closed 11 months ago

skylord123 commented 11 months ago

Describe the bug I have found that this fork actually adds 2-4 seconds onto the stream latency. Is there any reason for this and could it possibly be fixed? If I switch back to thirtythreeforty/neolink docker container the issue goes away and the stream is about 0.5-1 second of a delay.

I've done a few things to try and make this better such as switching to UDP but the issue is still there. This is really annoying if you have a camera that supports PTZ as you have to wait about 3 seconds until the camera moves. If I switch to the original container the latency is less and updates under a second.

To Reproduce Testing this with PTZ is much easier as you can just press the move button and count the time that passes until the image updates. If you do not have PTZ you can test this by updating the time on the camera to match your system and compare the timestamp that shows on the image to your system's clock. I have a Node-RED automation to set/get the time off the camera so I use that to make sure the time is as close to correct as possible.

You need to test this on both this fork and the original to really see the added latency.

Expected behavior I would expect latency that is similar to the original repo this one is forked from and be about a second or less.

Versions NVR software: Xeoma 23.1.25 (Using UDP and made sure to have any buffering disabled) Neolink software: latest (as of posting) Reolink camera model and firmware: RLC-423ws with the last released firmware version

jadzdotcom commented 11 months ago

I've been following along with this project and noticed comments about a buffer used to smooth out the video.

According to https://github.com/QuantumEntangledAndy/neolink/pull/101#issue-1743001438 you can set the buffer_size to 0 in the config and it will just stream the frames as they arrive.

skylord123 commented 11 months ago

According to #101 (comment) you can set the buffer_size to 0 in the config and it will just stream the frames as they arrive.

Ohhh nice! This fixed my issue. I set this to zero for every camera and now the stream is about as live as I can get it. It is only about ~1 second behind now like the original. Since my cameras are wired I don't really need to buffer.

Thanks for answering this for me. Appreciate it.

kyle170 commented 6 months ago

Just chiming in here, I've tried to set the buffer_size = 0 to each camera but I still get huge latency issues (+10 seconds, with it sometimes getting a couple of minutes behind) with the new version. The original version does not have these issues. Verified with Blueiris, HomeAssistant, Direct RTSP stream (VLC)

Example config below: image

Camera: Reolink Lumus HW CPU: AMD Ryzen 5 3550H HW LAN: 2.5Gbps Running via Docker image on target machine (thirtythreeforty/neolink:latest && QuantumEntangledAndy/neolink:latest)

Is there something I'm doing wrong here?