We want to propagate BlueROV main camera video to multiple locations (piloting laptop and educational displays), but we want to do so in a tether-bandwidth-smart manner.
As an experiment, we
configured the camera feed as RTSP
started a mediamtx instance on the piloting laptop with the appropriate configuration (below) to forward the RTSP
Added a “redirect” video source in BlueOS pointing to the mediamtx endpoint on the laptop (rtsp://192.168.2.1:8554/rovcam1)
With this configuration, Cockpit successfully detects the two streams, and we are able to display either stream in the video view (or both simultaneously by adding a second video view)
However, this configuration feels brittle, there is no clear indication whether Cockpit is connected to the “original” stream on the vehicle, or the mediamtx-proxied stream. As the failure mode is two redundant streams on the tether (and as we look to adding more cameras, potentially filling the tether), I’d like a more “bulletproof” method.
As QGC retrieved its video config from Mavlink, I believe the “disable mavlink” option would allow you to hide a video stream from the ROV side and effectively steer QGC towards your preferred video source. But this doesn’t seem to work with Cockpit. Is it acquiring video stream config a different way (through REST or WebRTC)?
My main goal is a system which gives a positive indication when Cockpit is trying to access the ROV video directly (not through the proxy) … even if that means not working.
Thanks!
Here’s the relevant config in the mediamtx.yml on the laptop:
Today Cockpit consumes video with the Video Player widget through WebRTC, and with an specific signalling protocol that was created by mavlink-camera-manager, so it’s definitely consuming the video from BlueOS itself, not from the MediaMTX server on your topside.
We are considering adding direct RTSP support on Cockpit, but not on the plans for this quarter.
If you needed today to pass more video links through the tether, to the point of having a single link for each video going to your topside, what I would recommend is that you disable the streams on the Video Streams page of your vehicle, run mavlink-camera-manager on your topside, create the Redirect links on this top side MCM and link MediaMTX to this topside MCM.
Interesting, so in my case above where I had the RTSP stream from the mediamtx proxy on the topside registered as an external source, the data was actually making two round trips:
mavlink-camera-manager on ROV → RTSP up tether to →
mediamtx on laptop → RTSP down tether to →
mavlink-camera-manageras WebRTC “server” → WebRTC up tether to →
cockpit on laptop
I am more familiar with RTSP than WebRTC, I know it is more of a negotiation protocol. I’m curious if any of those trips get “optimized out” in the negotiation to become, for example, a direct RTP connection from the ROV to cockpit.
You can keep running MCM in the ROV, as a V4L/RTSP to RTSP streamer, no problem. In that case, I would run another MCM instance on the topside and create Redirect streams in this topside MCM, with the URLs of the RTSP streams coming from the ROV MCM.
On Cockpit, to be sure you’re consuming from the WebRTC of the topside MCM (not from the ROV), you need to enable the option in the image below and put ws://127.0.0.1:6021 in the text input. This way the main “Vehicle network connection” (on the top) is still done with the ROV, but the video itself comes from the topside MCM.
[USB cameras] → MCM on the ROV exposing those V4L cameras through RTSP URLs → MediaMTX on the topside consuming from those RTSP URLs and exposing new RTSP URLs → MCM on the topside consuming from those new RTSP URLs (using redirect), exposing them through WebRTC → Cockpit
[IP cameras] → MediaMTX on the topside consuming from the cameras RTSP URLs and exposing new RTSP URLs → MCM on the topside consuming from those new RTSP URLs (using redirect), exposing them through WebRTC → Cockpit
As of now, your Cockpit instance is definitely consuming from MCM on the ROV, as you’re not running MCM on the topside nor have the dedicated WebRTC URL configured on Cockpit.
Unless you have both the original stream and a Redirect stream on MCM, the video is not going back and fourth. Can you send a screenshot of both your Video Streams page on BlueOS and your Video Configuration page in Cockpit (under the settings menu)?
I’m mostly sure this does not get optimized automatically at all.
Unfortunately I am accessing the ROV remotely, I can’t move anything in front of the camera, however in testing yesterday I didn’t observe any latency between the two, which is very suspicious.
Indeed, unless WebRTC is doing some optimization magic behind the scenes, Cockpit is consuming from those separately, and there should be some latency between them, as you’re doing:
Stream 1: USB Camera → MCM exposes through WebRTC → Tether → Cockpit (1 tether pass)
Stream 2: USB Camera → MCM exposes as RTSP URL → Tether → MediaMTX → Tether → MCM exposes through WebRTC (Redirect) → Tether → Cockpit (3 tether passes)
Here’s the block diagram. As I do not have the external camera configured right now, I introduced a quick gstreamer pipeline which flips the MCM video (RTSP in → decode → flip → encode → RTSP publish to Mediamtx RTSP server)
