I am planning to use 2 cameras in my ROV setup :
First camera is HD low light USB camera wich is plugged on RPI4 USB port
Second camera is go pro H3 black wich is plugged to HDMI/CSI-2 converter (auvidea B101) , converter is linked to CSI-2 camera port of RPI4B
I 've installed latest raspberry pi OS lite and followed this link to setup companion : update installation scripts by jaxxzer · Pull Request #284 · bluerobotics/companion · GitHub
Also installed gstreamer 1.18.4 following this link :Show home:den_erpel - openSUSE Build Service
With little modification , i can stream both cameras (1080P30fps on low light camera and 1280/720P 60 fps on go pro) to two different UDP ports on my laptop with almost no latency and decoding both streams with gstreamer.
My problem is that go pro video stream is blocked when webui is starting up
The only way to make it work is preventing webui to start in .companion.rc file
Not very familiar with java script, is there any way to make go pro stream work without braking webui startup
Thanks for your help
Would you be able to share the gstreamer command you’re using to stream the go-pro stream over UDP? I’m unsure if this is likely to be a port conflict or whether there’s an issue with the webui trying to see if your gopro provides a valid h264 stream for the companion software to stream.
I’ve previously used a non-h264 compatible camera at the same time as the BR HD low light USB one and not had any issues with running that at the same time as the web interface, so I’m leaning towards a port conflict, but it’s also possible it’s something else.
Gstreamer sender command is :
gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! “video/x-raw,framerate=60/1,format=UYVY” ! v4l2h264enc extra-controls=“controls,video_bitrate=4000000;” ! ‘video/x-h264,profile=high,level=(string)4.1’ ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5601
/dev/video4 is auvidea converter
I am sending to UDP port 5601 on laptop
Thanks for your help Eliot
port 5601 is used by companion for audio streaming, try a different port
or remove/comment this line companion/.companion.rc at master · bluerobotics/companion · GitHub
Not sure if it helps at all, but the new Hero 9 can be used as a USB webcam using some software. I think the software is only available on Windows and Mac (so not sure whats involved to get it working on the Pi), but maybe this is an alternative solution to look at?
Jacob, I tried that but result is the same, the only thing , even with trying port 5602.
When I remove the line : sudo -H -u pi screen -dm -S webui $COMPANION_DIR/scripts/start_webui.sh
then i can watch the stream
Marcus, i havent got go pro 9 by now, but i think it s almost ok with go pro H3 , just a software problem
I found that starting webui screen session when logged to RPI4 in ssh is working, so i added some delay in script file start_webui.sh like shown below
#!/bin/bash export COMPANION_DIR=$home/companion cd $COMPANION_DIR/br-webui/ # STARTUP DELAY (required for dual camera with GoPro, reason unknown) sleep 5 # limit logfile size to 10k lines tail -n 10000 $HOME/.webui.log > /tmp/.webui.log cp /tmp/.webui.log $HOME/.webui.log rm -f /tmp/.webui.log # start webserver node index.js 2>&1 | tee -a $HOME/.webui.log
Now everything is working like expected for the video streaming part
Thanks for your help
Glad you managed to get this working.
Out of interest, how are you starting your second camera stream? If it’s with a script that you’re calling from
.companion.rc it might work to just start it before
start_webui.sh? Could be worth a try
When I set up my second camera I modified the existing scripts to start both my video streams (as discussed/covered here), but I’m not sure how you’ve approached it.
From .companion.rc , i m calling streamer_gopro.py , just before calling webui.sh
streamer_gopro.py is calling video.sh in wich go pro video is started :
#!/bin/bash v4l2-ctl -d /dev/video4 --set-edid=file=/home/pi/companion/scripts/1080P50EDID.txt --fix-edid-checksums sleep 1 v4l2-ctl -d /dev/video4 --query-dv-timings sleep 1 v4l2-ctl -d /dev/video4 --set-dv-bt-timings query sleep 1 v4l2-ctl -d /dev/video4 -v pixelformat=UYVY gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! "video/x-raw,framerate=60/1,format=UYVY" ! v4l2h264enc extra-controls="controls,video_bitrate=8000000;" ! 'video/x-h264,profile=high,level=(string)4.2' ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5602
As you can see i have added some delays between V4L2 initialisation steps because it cannot work well without that (cannot get or set dv-timings properly)
If i call streamer_gopro.py after webui.sh it doesnt work, why I don’t know, but it appears that the delay in webui.sh is a way to make sure webui starts after go pro streaming.
Eliot , do you know how is it possible to access go pro settings in the camera settings page ?
I’ve edited your comment to put your
streamer_gopro.py code in a code block.
I haven’t played much with v4l2 settings or gopros before, so I’m not sure why this is necessary or what it does, and accordingly can’t really comment much on this. It seems odd that you would need to sleep between command-line calls, especially since I’d expect a ‘query’ to return something, but maybe the camera or HDMI/CSI-2 converter don’t like requests that are too close together.
If the gopro streaming doesn’t work when called after the webui is started then it makes sense that you’d need a sleep to make sure the gopro streaming has started before your webui initialises, since the detached screen sessions that are started in
.companion.rc each run in their own thread, which means just after the gopro script starts running the webui one also starts running.
I’m not certain whether it’s possible to do this for non-h264 cameras, and more so since you’re doing the streaming side of things outside of the normal companion computer streamer functionality. The webui source seems to be set up to handle settings for generic v4l2 camera inputs, but I may be misunderstanding that as I don’t have a heap of experience with it.
For now I’d suggest clicking the ‘Active Camera’ dropdown and seeing if there’s an option for
/dev/video4 where you can change the settings. I’ve sent a question to our software team internally, who can hopefully advise more on this, and will update you when I’ve got a response from them.
There is no /dev/video4 option in dropdown . Configuration options for this kind of cameras could be a nice option to be added in companion computer
Fair enough. I’d guess that’s because it’s not a h264 stream, or because you’re already using it separately.
I’m sure such a feature could be useful, although presumably we would need to actually support multiple video streams and camera types first. More generally, I’m not sure if it’s actually possible to control a camera’s settings through something like a HDMI/CSI-2 converter - maybe you can try directly though v4l2-ctl and see what’s available?
By the way, I had a look into the raspberry pi forum thread on HDMI to CSI-2 stuff and from this comment and this one I think it should be possible to do something like the following, which has less sleeping involved. If that does work then you can likely change your 5s startup delay in
start_webui.sh down to 1-2s instead.
#!/bin/bash device=/dev/video4 # tell HDMI/CSI-2 converter desired output format v4l2-ctl -d $device --set-edid=file=/home/pi/companion/scripts/1080P50EDID.txt --fix-edid-checksums # wait long enough for resolution changed update to occur sleep 0.5 # query the converter for available timings and set the query result v4l2-ctl -d $device --set-dv-bt-timings query # set the desired pixel format v4l2-ctl -d $device -v pixelformat=UYVY # possibly need another sleep here? # sleep 0.5 # start the stream (encode to h264, stream to topside via udp:5602) gst-launch-1.0 -vvv v4l2src device=$device ! "video/x-raw,framerate=60/1,format=UYVY" ! v4l2h264enc extra-controls="controls,video_bitrate=8000000;" ! 'video/x-h264,profile=high,level=(string)4.2' ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5602
Ok, i will give a try when back from holidays.
Thank you very much for your support