search

QuantumEntangledAndy / neolink

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

High delay on Reolink E1 #233

Closed FusselTV closed 2 months ago

FusselTV commented 2 months ago

I am using a Reolink E1. First of all, thanks for this project, absolutely genius. My problem is an unusual delay of about 20 seconds at the start and then increasing. My workaround was using this fork for MQTT and PT control and the unmaintained version for the RTSP stream since it didn't have the delay issue (about 1 sec for the RTSP stream). The reason why I can't use this setup anymore is that after a firmware upgrade of my E1, I get this issue https://github.com/thirtythreeforty/neolink/issues/353 on the unmaintained version. But I also don't want to downgrade my firmware because of the calibration feature for PT.

My setup is the Docker container and Frigate, but the delay issue also persists when I open the stream via VLC.

Can I provide any logs? Because the container log is clean without any errors.

image image image

FusselTV commented 2 months ago

and it's also memory leaking 😢 image

QuantumEntangledAndy commented 2 months ago

There are 2 other open issues on the memory. Long story short I cannot replicate it. We are trying to setup a test on someone else's machine.

QuantumEntangledAndy commented 2 months ago

Here https://github.com/QuantumEntangledAndy/neolink/issues/202#issuecomment-2042148886

FusselTV commented 2 months ago

I saw that issue too. Hopefully, it's linked to the high-delay bug. While I was running the container only for MQTT, there were no issues.

FusselTV commented 2 months ago

My workaround is a Windows VM using 0.6.2, and it's always fun setting up a service in Windows. Installing gstreamer and OpenSSL took 20 minutes of trying around. The delay is now down to 5 seconds, not as good as before, but usable.

QuantumEntangledAndy commented 2 months ago

So I think this has now been fixed. The history buffer was growing infinitly if the camera wasn't sending correctly time stamped video. Any chance you could test this?

rfam13 commented 2 months ago

This has made it a lot better from my testing. The memory leak seems not existent and looks like memory is being cleaned correctly now. I have a 3-4second delay, this being run through go2rtc restream as well. This is much better than the 30sec delay that would grow to 2min delay I have been facing.

The only thing I notice now is that sometimes frames are skipped it looks like, it will go from 1:02:04PM to 1:02:07PM in a few frames, almost as though it is trying play catch up and disgards the time in between, lowering the camera bitrate seemed to help with this for me.

Thanks!

QuantumEntangledAndy commented 2 months ago

That's good to hear. I'm getting other users who still report memory gains over a longer time. If you notice anything like that please let me know.

QuantumEntangledAndy commented 2 months ago

I've added a new option buffer_duration for the [[cameras]] section of the config which is the length of the buffer is milli seconds it defaults to about 3000ms so 3s. You can play around with the number and see how low you can get the delay if you want. If you are not using the pause feature you can probably get it quite low.

Anyways will close this as I think it is resolved