Expected Delay/Lag in video

[Sciamano72]

Expected Delay/Lag in video

[QuantumEntangledAndy]

Some delay is expected. Since we add an extra few steps into the process. If you do try a more powerful machine do let us know the results. I'm not sure what your setup is like but you might want to consider using Ethernet over Wi-Fi where you can.

We do try to keep that time down as best we can. I'm working on a rework of the gstreamer part of the code that I hope will improve things but won't know until it's complete.

[Sciamano72]

Unfortunately my cameras are wi-fi only. Three of them even are battery operated (Argus Pro).
Actually I'm already surprised that neolink worked with these cameras, so don't get me wrong: my question was not intended as a criticism!

I don't have any better equipment to dedicate to neolink at the moment but I could try installing it on my desktop PC and see if this reduces the delay. I will report back as soon as I find the time to experiment.

Keep up the great work!

[QuantumEntangledAndy]

I meant the connection between the Wi-Fi router and your neolink. Try to get that part wired at least.

[Sciamano72]

Oh, sorry for the misunderstanding.
Actually neolink is already onnected to the router via Ethernet cable.

[Checksum]

Did some more testing with my Argus PT and Neolink 0.5.8. To me, it feels like the number of dropped frames have increased and the video is now very choppy when compared to 0.5.6. I initially thought it was probably my underpowered raspberry pi 4 causing issues, but have the same issue when running on my laptop as well. I've attached neolink and VLC logs if it can help. I'm happy to do some Wireshark diving as well, but haven't set it up yet.

neolink-argus-pt-0.5.8.log

VLC Debug Log (3.0.18 Vetinari).txt

[QuantumEntangledAndy]

Most likely you will be network io bound rather than the power of the board.

On my network I stuggle to view the 1080p stream at 25 fps. I've had a look into this a few times and most of the time neolink is just waiting for the camera to send another frame.

Things we can try though are increasing the vlc buffer size. The latest version now uses the time stamps from the camera so in theory if we can buffer a bit more we can present them using the stamped PTS at the right times.

Mind you I haven't tested how if gstreamer or the client are actually listening to the PTS I set. The gstreamer docs seem a bit vague on the correct way to do this.

I'll see if I can test a few more things once the mqtt is sorted out.

[QuantumEntangledAndy]

@Checksum see work in #68 about VLC hopefully that can help, would be nice if you could test with the setting suggested in #68 as well as the build

[QuantumEntangledAndy]

Ok so in my recent VLC experiments, I managed to tweaks things to only about 1s delay, however it was quite flakey when the buffer was that small so I have opted for a larger buffer of about 3-5s (depends on your fps). VLC will usually add about 1s on to that on top too.

Do try the latest build with its improvements to the buffer it seems to help keep the video steady.

I don't think there is much else I can do to address latency. If you can you might want to try ffmpeg (it is more forgiving than VLC) and you can also try in ffmpeg using options like genpts to drop the time stamps and just play the frames as soon as they arrive.

[QuantumEntangledAndy]

Going to close this as it is not really a bug, I will of course keep trying to improve what I can with delay and smoothness of the streams.

Will also be adding an option soon to just pass frames on as is asap with worrying about time stamps in the event you just want minimal latency