I’m facing significant amount of latency (1-2sec) with my Sonoptix sonar (v2.0.0) only when using the RTSP stream. I am using the RTSP stream to get the raw data from the sonar (rtsp://192.168.2.42:8554/raw), however it has 1-2 second latency when played with the VLC Player.
Meanwhile the “video” stream on the Browser (http://192.168.2.42/) shows near-zero latency (at least to the human eye).
I’m not sure we’ve specifically tested the RTSP latency, but I can ask internally whether it’s something we’ve run into and have any insight on.
That said, your question is likely be better posed to Sonoptix, as it is their device and firmware you’re communicating with / streaming from, so they hopefully have additional insights as to whether higher latency is expected and/or can be adjusted or compensated for.
Following up, the raw data stream was added via a firmware update after we did our primary testing of the Sonoptix Echo, and we haven’t meaningfully tested the feature.
I have similar setup although I’m using ros2 rqt image view to quickly visualize the stream (also converting to pointclouds). Unfortunately I’m seeing 3-4sec delay / lag. Have you heard from Sonoptix, or found a solution?
Hi Folks, I’ve found that RTSP generally adds lag to cameras also, vs using something like gstreamer.
I’ve especially noticed it with VLC, if you can try to use FFPLAY, it halved the latency for me before with an offshore ROV camera, but that was going from 1sec to 0.5sec, still too much latency to be useful
Thanks for the input XYZEng,
Unfortunately, this sonar only has two output options live video(no visible latency) on a web API or RTSP. So I believe I am stuck with RTSP.
However, I greatly improved the latency by specifying UDP transport instead of the default TCP, explicitly setting FFmpeg with a buffer limit, and frame flushing. Now the latency is about 1 second. Hopefully I can find a better solution.
As an aside, I also have a Sonoptix echo, while great for navigation in turbid water, I find the webapp very frustrating. It doesn’t give the option to save the video until after the video has been stopped.
I momentarily lost power to my ethernet devices because I was pushing the thrusters too hard, and lost 40mins of video, which worked out to be about half of a full deliverable. I didn’t have time to go back over it as weather was picking up.
I might switch to RTSP also. But it’s a pity there’s no lower latency video stream than RTSP that I could record on my GCS.
It’s possible the latency increase is from the H264-encoding process.
That said, if you’re ok with the standard video output (rather than the raw output provided by the RTSP stream) then it’s likely possible to determine how that video is being fetched by the provided web interface, and make your own program that replicates that and records it. Given the original UI is a web interface, it might even be possible for functionality like that to be included in Cockpit…
