Hi @Itaru
I have also tested with BlueOS and Cockpit. First of all, congratulations to the Bluerobotics team for Cockpit and their excellent work, I know it is a Beta version, but it will be a great option for everyone. The web interface is great.
I have installed BlueOS on Rasberry Pi 3B, I know it is much worse than Pi4, but I wanted to see how video streaming behaved through the less powerful option. Unfortunately the result has not been good, let me explain:
- On the one hand, through Cockpit the transmission has had quite poor quality, a lot of delay, constant image freezing and loss of frames. Another thing I didn’t like is that you can’t use h265+/h265 through Cockpit either due to WebRTC, and it’s a shame because the quality increases and the bandwidth is reduced. (I think it is for rights reasons of the h265 HVEC codec, but the reality is that all the IP cameras I know today use h265)
To test, I have configured the RTSP channel in “Camera Redirect” through Mavlink Camera Manager as recommended by @joao in this post, and I have made sure to be connected by network and not by Wi-Fi:
I assume that the problem stems from the lack of power of the RasberryPi 3, and Mavlink Camera Manager is not capable of processing the video with this hardware. But maybe there is something I am doing wrong, the question I have is if I am correctly forcing Cockpit to use ethernet and not wifi, what I did was disconnect wifi in blueOS. Is it the correct way to do it?
@joaoantoniocardoso , please can you tell me something about it. I know it’s not a problem with my PC, because it is relatively powerful and has good graphics. I can view this camera without problems in Qgroundcontrol, Web Browser, VLC, etc. , and without going through Mavlink Camera Manager it works very well.
I also know that the pipeline is fine, because I have also used “Camera Redirect” through Mavlink Camera Manager or BlueOS Pirate Mode, to redirect it to Qgroundcontrol and in this case I receive the signal well.
Note that I have been able to record video with an .ass file through Cockpit with this channel, in fact the recorded video is much better than the live image, something that I do not understand very well either.
Therefore I am inclined to think that it is a Rasberry Pi 3B problem or that I have incorrectly overridden the Cockpit Wi-Fi connection. In any case, I will try to try with Rasberry Pi 4, since I have seen posts that comment on good results.
- Finally, I would like to point out that although I receive the video image in Qgroundcontrol using the redirection of Mavlink Camera Manager or BlueOS, the image quality and fluidity is much worse than if I directly enter the RTSP in Qgroundcontrol without using Mavlink Camera Manager . Perhaps also a problem with the lack of power of the RasberryPi 3B.
A priori conclusion, I see no reason to use Mavlink Camera Manager to stream RTSP to Qgroundcontrol. In my opinion it is better to do it directly, at least with Rasberry Pi3B and I am not entirely sure but I think it will not be better if I use RasberryPi 4.
Let me explain, if I have not misunderstood, by going through Mavlink Camera Manager and then to Qgroundcontrol, we are processing the image twice, or forwarding the video through one software to another software that is responsible for processing it. On the other hand, Mavlink Camera Manager, which is responsible for processing/redirect, is installed on a Rasberry Pi 4, however when you directly connect an RTSP URL to Qgroundcontrol without going through Mavlink Camera Manager, which is in charge of processing the image It is the surface PC, much more powerful than a RasberryPi. Therefore, I have serious doubts that it will work better.
The only reason I can think of for transmitting RTSP through Mavlink Camera Manager is to use Cockpit, but my tests with Rasberry Pi3B have not been satisfactory, so I hoped that with RasberryPi 4 it will be worth it.
My question is, is it really necessary to process an RTSP stream, through Mavlink Camera Manager on a small RasberryPi computer, which is viewed in a web browser (Chrome, Edge, etc.) through Cockpit, when the RTSP signal is actually available networked on the surface computer thanks to the ROV’s Ethernet switch without any processing?
I appreciate any feedback from the Cockpit software development team.
Best regards