I am using a Blueboat as an unmanned survey vessel. The boat operates outside the range of the base station and is equipped with a Teltonika router. Because of CGNAT, I don’t have a public IP address, so I’ve set up remote access via WireGuard through a VPS. The connection is very stable, and telemetry data is transmitted reliably. However, the video stream (H.264 / UDP / port 5600) in QGroundControl becomes blurry or pixelated whenever the boat moves faster or there is more visual motion in the scene. My first suspicion was IP fragmentation along the path.
I initially tried ZeroTier, but I see a significant advantage with WireGuard because the latency is much lower and, after a connection loss, it reconnects almost instantly — without needing NAT hole punching. The link is usually re-established within about one second.
I have installed the DWE extension for my exploreHD 3.0 IP camera and reduced the bitrate, resolution, and frame rate. This already improved the result significantly. However, when the boat moves rapidly, I still notice pixel artifacts in the video.
I would like to reduce the RTP MTU on the boat to 1200 bytes to avoid packet fragmentation.
Is there a way to configure the RTP MTU in BlueOS or within the DWE / Camera Manager?
Do you have any alternative approaches or recommended solutions?
Hi @Arne1 -
It sounds like you’ve taken all the steps I would recommend. Sh you could try improving your modems antenna height with a mast, but cellular connectivity is never going to provide the video performance you get with Wi-Fi or a tethered ROV…
I’m interested in how you setup wire guard- do you have any steps to recommend, lessons learned? It may be worth turning your setup into a BlueOS extension to share with others?
Hello Tony, sorry for my late reply. I have been trying to solve the problem in Wireguard for quite some time. I defined the VPS server as the Wireguard server in Wireguard and the Teltonika router or Windows laptop as the client. I also routed the Blueboat network (192.168.2.0/24) via the Teltonika router. Unfortunately, I couldn’t find a solution for the poor video signal. The 5G connection couldn’t have been the problem. At times, I had a connection speed of about 300 Mbit/s. Reducing the video resolution didn’t have a significant effect either. What helped a little was to reduce the bitrate and set the Group of Pictures to max. After a while, I gave up in frustration. It was possible to sail the boat like that, but the image wasn’t good in the end. I have now found an alternative in Tailscale. Tailscale is based on Wireguard, but greatly simplifies network configuration. If the connection is briefly interrupted, it is immediately reestablished (much better than with ZeroTier). The only minor issue that still isn’t working is the video signal in Cockpit. I suspect that this is less due to Tailscale and more to my lack of knowledge about how to configure Cockpit correctly. But in the end it works with QGroundControl without any issues.
Hi @Arne1 -
Glad you’re finding some success! You may have more luck with Cockpit and video over your 4G connection if you configure the video stream to be RTSP instead of UDP? It looks like you’re properly putting the tailscale IP address in the Allowed WebRTC remote IP Addresses under video configuration. That should be all it takes to get the video going…
I’m shocked you are getting 300Mbit (down? ) on your cellular solution - I’d guess the upload, the critical value for sending video from the vehicle, is vastly lower - it’s rare to see it more than 5-10Mbit? Keeping your bitrate of the exploreHD video adjusted to 2-5 Mbit is typically required…from testing with the same camera on a BlueBoat, the best performance is typically from the direct WiFi link the BaseStation provides!
You’re right, of course. I have a download speed of 300 Mbit (sometimes even up to 750 Mbit). My download speed, on the other hand, is only about 100 Mbit. It’s an industrial 5G router with 4x4 MIMO technology. So it has 4 antennas (two inside the boat and two outside). My bandwidth is not the limiting factor. In addition, the video runs very smoothly and without problems in QGroundControl.
Hi @Arne1 -
It’s unusual to have better video performance in QGC than Cockpit. Maybe @rafael.lehmkuhl has some thoughts on why this may occur? I’m guessing something with the allowed IP address may not be set correctly - have you tried an rtsp stream instead of UDP?
@Arne1 can you take a look at the Video widget configuration? Just right click anywhere on it (blue space), click Options and get us a screenshot of the dialog. I believe your widget may be configured to an old stream (since your Video config page show the stream info is being fetched correctly). In the widget config dialog you can try switching to another stream in the drop-down.
If that doesn’t work, can you try disabling the WebRTC link in the General config page? Since you’re using a BlueOS vehicle the Global Address is enough (the others are automatically parsed from it).
I changed the stream name in BlueOS to stream2 and cockpit offered me to adjust the stream to stream2. After that doesn’t change anything I changed everything back to stream1. Therefore I think the widget is configured the right way.
After that I disabled the WebRTC link, but that doesn’t help ether.
If I use the dwe app in BlueOS for streaming everything works perfectly fine in QGroundControl.
I guess the problem comes with Tailscale. But than its strange, that it works with QGroundControl, using the DWE app for streaming.
But beside of that I am really happy with tailscale. You should maybe think about an BlueOS app for Tailscale. I guess there are many people who would like this.
@Arne1 it indeed looks like its a problem around using WebRTC on Tailscale. Looking at their repository there are some complaints about usage of WebRTC with it, although its not clear anywhere if they do support it or not.
It works with QGC because QGC consumes directly from the announced UDP/RTSP endpoint, not from the WebRTC link.
We have plans to support direct RTSP connections in the feature, but its not in our priorities yet.
But in the end it works with QGroundControl without any issues.
