This is so awesome!! I see that I can get WebRTC via http://octopi.local:8080/webrtc but what's the best way to get it into the frontend? I've tried setting the stream URL to webrtc://octopi.local:8080/webrtc but that doesn't work. Perhaps there's something different about how the webrtc offer works with the new camera-streamer setup than what I had in my PR?
The webrtc protocol is different for different streamers, the PR is quite specific to the aiortc implementation. Since there is webcam plugin support in OctoPrint 1.9.0, support for different streaming formats can be added with plugins. I've made one for the new webcam stack which I intend to finish and publish in a month or so.
Ah i thought the WebRTC offer flow was pretty standard but I think you are right that it in fact isn't. I wonder if we should replace the default implementation with something that can work directly with camera-streamer since that's the future. Could make it easier to go fully into webrtc in the future
Edit: I tried to get @jneilliii's iframe webcam plug-in running with this but couldn't make it work for some reason.
use Charlie's beta plugin
Great I'm up and running with @Charlie_Powell's plugin! It just worked!
Now to figure out how to tell camera streamer to send the raw 1080p h264 stream without re-encoding it. Looks like right now it's consuming ~36.1% CPU at 720p so theres very likely transcoding happening (though probably openmax accelerated at least).
It does not re-encode. The WebRTC when running does require encrypting the stream in transit. This depending on device costs between 20-40% of a single CPU core.
All available configs can be found here: libcamera/control_ids.yaml at 06bbff9c23d5a85acd65595216c6b75094891f72 · raspberrypi/libcamera · GitHub.
The develop branch changes those value to human readable, it will at some point land in main, alongside some web interface to modify settings live.
- CSI/USB:
NBUFS: Number of buffers to use, defaults to 2 if unset.
I think we could fine tune this to 3.
USB: *
FORMAT: Image format to set on the camera, defaults to YUYV.
My advise would be to try JPEG. YUYV most of times will overrun USB bus and have quite choppy framerate. Only older cameras do not support JPEG, but the usage of YUYV could be provided as a fallback.
Hi @ayufan! Fantastic work on camera-streamer!!
So by default if my camera can output h264, then it will stream that out directly and it just works?
I've noticed I can run the mjpeg compatibility stream (eg from Cura) at the same time that the h264 WebRTC stream is running (which is really neat). So there must be at least one transcode happening right? Is the mjpeg stream re-encoded from the h264 stream, or is the h264 stream re-encoded from the mjpeg stream? Or are they both encoded from the YUYV stream?
The h264 stream from cameras is hit-miss, since you cannot force key frames. The only supported captures are: YUYV (and variants), JPEG, RGB, and various raw formats from CSI cameras.
Depending on input format the pipeline differs, at least there always have to be a single encoding block used to encode either JPEG or H264, or sometimes both:
- YUYV => JPEG | H264
- JPEG => YUYV => H264
- RB10 (bayer 01 bit) => via ISP => YUYV => JPEG | H264
- if downscaling is used it might also trigger: JPEG => YUYV to downscale => JPEG | H264
Go further down into the plugins section of settings and check the Classic Webcam settings for those fields.
@brentil - as mentioned above already in this topic. If you have issues with setting up the new camera stack, then you must open your own post. It is extremely confusing to have lots of issues all under one thread that is supposed to be a guide to help change the settings in camera streamer.
Congrats @foosel on this new feature. Where can I find instructions for a custom install of OctoPrint (without the RPi imager). I checked this thread and issue 2 for OctoPi-UpToDate but I was unable to find it.
It's the one that has camera-streamer mentioned.
Thanks but I think I wasn't clear. I have reasons why I have a custom installation of OctoPrint without OctoPi. I'm looking for instructions on how to add this new camera stack to a standalone OctoPrint installation (on raspbian) that doesn't use OctoPi.
Ah, gotcha. It's using this.
The new camera stack is built for OctoPi. If you want a similar thing for yourself, then you have to install camera-streamer yourself - you can't take advantage of the scripts here, they are OctoPi-only. The whole 'new stack' idea is specific to OctoPi as well.
hi i have octoprint installed on raspbian do i need to install the camera stack ?
it says im running Version 1.9.0.
thanks martin