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.
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.
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:
@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.
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.
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.
Is there any camera option for FOV? I have a Logitech Brio that can run at 65°, 78°, and 90° as configured in Logitech software. Looks like its running 65 as default and would love to get the wider view for timelapse if possible.
Gave up, doesn't look like a configurable option and since it's not manual can't open camera up to change it either. Remounted to make it work for now, will probably replace with different model.
If I add an USB camera with add-usb-camera and I choose the right camera and I can see it set port 8082.
is the URL to the stream as it was before http://octopi.local:8082/?action=stream ?
I can't see the video.
I cannot get this to work at all. I did a fresh install of OctoPi 1.0.0 and Octoprint 1.9.2. I have one USB camera attached, and camera-streamer is running:
However, when I go to 192.168.1.5:8080 or 192.168.1.5:8081, I just get "Unable to connect". What am I missing? lsusb shows the camera just fine. journctl shows: