Octoprint + RPi5 + Pi Camera v3

Get Help Webcams
1

Camera model

Pi Camera v3

What is the problem?

Trying to get Octoprint (1.10.0) to work with RPi5 (latest Bookworm, not Octopi) and a Pi Camera v3

What did you already try to solve it?

I tried running camera-server but it appears like it doesn't support the Pi Camera v3 on an RPi5 since the RPi5 dropped h264 hardware encoding.

I was able to make it work in a kludgy fashion by hacking libacamera streaming code in Obico to work with libcamera2. However, support for internal streaming within Obico seems to be going away and my hack is not very stable (the stream crashes after several hours to days).

So, has anybody else succeeded in getting a Pi Camera v3 to work with a RPi5 on Octoprint?
If so, what streaming software are they using?

I did see someone mention raspi-cam-srv as a potential streaming app that works but before I try it, I wanted to see what others are recommending.

Have you tried running in safe mode?

Not relevant

Systeminfo Bundle

Not relevant

2

you should see if go2rtc gives you any better support. I've used that on a couple of my setups for transcoding rtsp streams, and using locally connected devices. Pretty sure the v3 camera and go2rtc work using an exec stream that points to libcamera.

Edit: the nice thing about go2rtc is that there is lots of support from the Home Assistant community.

3

go2rtc looks very promising.
I was able to get it to stream to my browser using either of the below streams:

streams:
  picam_h264:
    - exec:libcamera-vid -t 0 --libav-format h264 -o -

  picam_mjpeg:
    - exec:libcamera-vid -t 0 --codec mjpeg -o -

However when I plugged in the respective urls (see below) to the 'url' in "Classic Webcam", and pressed test. I got nothing

http://octopi:1984/stream.html?src=picam_mjpeg
http://octopi:1984/stream.html?src=picam_h264

  • So, what do I need to do to get the stream to show up in Octoprint?

  • Also, is it possible to use a webrtc stream?

  • If so, what stanzas do I add to go2rtc.yaml to configure the stream and what do I do on the Octoprint side to receive the stream?

I did a fair bit of googling and couldn't find any good examples of using go2rtc with Octoprint which is surprising since this streamer seems to be very powerful and more widely supported than camera-streamer as used by octopi.

4

Ustreamer running with libcamerify also works, apparently.

5

OK. I got both my picam and a usb (nozzle) cam working in go2rtc as mjpeg
(BTW go2rtc seems to be amazingly simple and powerful)

Here is: go2rtc.yaml

picam_mjpeg:
 - exec:libcamera-vid -t 0 --codec mjpeg -o -

usbcam_mjpeg:
 - ffmpeg:device?video=/dev/video8&input_format=mjpeg&video_size=1280x720

The corresponding urls for Octoprint are:

http://octopi:1984/api/stream.mjpeg?src=picam_mjpeg
http://octopi:1984/api/stream.mjpeg?src=usbcam_mjpeg

To stream, just run: go2rtc_linux_arm64

It couldn't be simpler to configure and use!

I still need to figure out:

  1. how to stream webrtc from go2rtc and display in Octoprint
  2. How to display multiple cameras in Octoprint
6

I have reconfigured my octopi haproxy setup to redirect /webcam/ to port 1984 instead of 8080 and use the HLS stream url like: /webcam/api/stream.m3u8?src=bambu_camera&mp4=flac.

Pseudo possible with my webcam iframe plugin and the stream url like you mentioned above, but other apps like octoapp won't be able to pick it up. HLS is able to be picked up by OctoApp I've heard.

7

looks like we were cross posting...haha.

use the HLS url, that is more performant than mjpeg, and will embed in OctoPrint and be supported by other apps.

multicam plugin.

8

Displaying multiple cameras was dead simple using the 'Multicam'

9

OK. There seem to be many ways to do this with go2rtc but perhaps this is the most efficient:

streams:
  picam_h264:
    - exec:libcamera-vid -t 0 --libav-format h264 -o -
  usbcam_h264:
   - ffmpeg:device?video=/dev/video8&input_format=yuyv422&video_size=1280x720#video=h264#hardware

With the corresponding steaming urls:

http://octopi:1984/api/stream.m3u8?src=picam_h264&mp4=flac
http://octopi:1984/api/stream.m3u8?src=usbcam_h264&mp4=flac

Note that I still use the jpeg snapshot url as follows (the 'frame.mp4' snapshots seem not to work with Octoprint)

http://octopi:1984/api/frame.jpeg?src=picam_h264
http://octopi:1984/api/frame.jpeg?src=usbcam_h264

IT IS RIDICULOUS HOW CRAZY POWERFUL YET SIMPLE IT IS TO USE GO2RTC.

10

This is a simple service file I created a little while ago.

11

I just run it and octoprint from my user crontab using '@reboot' that way I don't need to mess with services. Though your service method is simple enough.

12

Question:
I get that for Pi Camera v3 on an RPi it makes sense to use libavformat h264 since there is no native hardware encoding on the RPi5 (output is RAW10) so might as well encode into h264 which uses less network bandwidth to stream.

But my USB nozzle cam (an endoscope) appears to support MJPG and YUYV (at least those are the two formats listed by v4l2-ctl --device=/dev/video8 --list-formats-ext).
Are those native streams? If so, does it make sense to keep them as mjpg rather than transcoding to h264 (which presumably is not native). So while the network bandwidth will be higher, the software transcoding overhead on my RPi will be less.

Am I understanding this correctly?

13

you seem competent enough to figure that out with standard linux commands. the streams are only active when you're looking at them so make sure they are active when checking something like htop. the big savings between HLS vs MJPG when viewing is network bandwidth, it's very possible transcoding from native MJPG to HLS is going to consume CPU.

14

I agree.
But the output of PiCamera 3 per the specs seems to be RAW10 -- not MJPG -- i.e.there is no native MJPG (at least if I am reading the datasheet correctly)
So, it would seem a transcoding would be necessary regardless - whether to MJPG or to HLS.

My thinking is that even if transcoding to HLS is a bit more computationally intensive than to MJPG, since you need to transcode anyway, it would seem that HLS is an overall winner given the lower bandwidth.

It seems like you are confirming that :slight_smile:

15

I solved using this: GitHub - signag/raspi-cam-srv: Web Server for Raspi Camera Access