hmm. well that's something. what does v4l2-ctl -d /dev/video0 --list-formats-ext look like? and for -d /dev/video1 too?
For /dev/video0:
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'pBAA' (10-bit Bayer BGBG/GRGR Packed)
Size: Discrete 3280x2464
Size: Discrete 1920x1080
Size: Discrete 1640x1232
Size: Discrete 640x480
[1]: 'BG10' (10-bit Bayer BGBG/GRGR)
Size: Discrete 3280x2464
Size: Discrete 1920x1080
Size: Discrete 1640x1232
Size: Discrete 640x480
[2]: 'BA81' (8-bit Bayer BGBG/GRGR)
Size: Discrete 3280x2464
Size: Discrete 1920x1080
Size: Discrete 1640x1232
Size: Discrete 640x480
For /dev/video1:
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
That is strange. So, I guess the new stack doesn't support mjpg or even h264 through the vl42 interface.
It sounds like you can run libcamera-vid and have it serve the stream up similar to what mjpg-streamer would be doing, but it makes me wonder if it's doing the hardware encoding that the 'legacy' stack was or not.
edit: doing some googling and much of the info I'm seeing is that the new libcamera based stack isn't complete yet. At this point your options seem to be using libcamera-vid as the streamer program instead of mjpg-streamer or using the legacy stack until mjpg-streamer or ustreamer are updated to support libcamera.
I did a bit more googling this morning around the libcamera-vid vs raspistill thing and it sounds like it's related to operating system version or something (I must admit that I don't entirely understand what I'm reading a lot of the time!)
I'd gone with the nightly as the latest stable build didn't work on the raspberry pi 4 and the download page said to try a nightly if that was the case. As a last ditch attempt this morning, I went with an earlier nightly: the last one that said "buster" instead of "bullseye":
2021-11-08_2021-05-07-octopi-buster-armhf-lite-1.0.0.zip
I'm very happy to say that it worked straight away with no special configuration required. I think I need to make a mental note not to upgrade debian...
It's important information as we were looking to release a new version of OctoPi based on Bullseye.
When did you try the 'stable' build? A couple of days ago an update to that was pushed, available through the RPi imager or octoprint.org, that should have fixed the incompatibilities with the newer RPi boards to get them booting.
Yes, it's definitely related to Bullseye. I had thought that you were using that on purpose, sorry.
I knew the old mmal interface had been deprecated with Bullseye, but I'm surprised to see that the 'new' v4l interface doesn't support the same formats. I did some more research and it sounds like the move to libcamera is intended to move away from any closed source/proprietary usage where possible and that includes the GPU processing.
One article I read stated that the new stack simply 'pushes raw pixels through the GPU' where libcamera can process them once they come out. To me that sounds like encoding to MJPG/x264/etc. would all then be on the CPU. It's great to get the camera moved to an open source solution, but it sounds like it's coming at the sacrifice of CPU performance, possibly a large one.
Hi Charlie,
According to my browser log I downloaded raspberry pi imager on 18/1/2022. I can't be absolutely certain, but I imagine I downloaded the stable build the same day.
Al
That does make sense why it didn't work - the update was released on the 19/20th, after you tried it.
My Pi cam with Pi-4 stopped working after an octoprint update last week.
1.7.3 i think?
1 Like
Hi Charlie,
The problem with the one that didn't work was that it wouldn't boot at all: nothing to do with the camera: something about start4x.elf not being compatible if memory serves me correctly.
Al
OctoPrint doesn't even know that your webcam exists (it only knows about two URLs, one to embed in the UI, one to fetch stills from, that's all it has to do with cameras), an update of OctoPrint cannot influence the webcam server. So this is very likely unrelated and coincidence.
So, am I reading this thread right so far that picams won't work with mjpg-streamer on bullseye? If so, that is a major show stopper for a new OctoPi release for now.
i created another thread and posted the log.
not sure what happened, since it was working fine for over a year.
Hi there, I installed Octoprint on a Pi4 with Pi camera Rev 1.3 about four weeks ago and it runs with 1.7.2 without any problems. That's just for info.
browser.user_agent: Mozilla/5.0 (iPad; CPU OS 15_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Mobile/15E148 Safari/604.1
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 1500
env.hardware.ram: 1903988736
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.4
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.7.2
systeminfo.generator: systemapi
You are using OctoPi 0.18, which is the stable release, rather than the nightly builds being tested here. They are based on different OS versions, the camera stack has changed.
1 Like
This is unrelated to the discussion in this thread.
That's development work for the next version of OctoPi, based on Debian Bullseye.
OctoPrint and OctoPi are two different things. You have a completely separate problem to this thread if you don't know what that fix is for or what bullseye means.
anyways. went back to 1.7.2 with Sudo command to rollback and camera stays white now in the test screen, and not a thumbnail, but still not working.
Which confirms what I said, this had nothing to do with 1.7.3 (and it technically also can't, two separate things, OctoPrint not having a clue what a webcam even is let alone controlling it) but is another issue that coincided and which has nothing to do with this thread.
Hi everyone, now I was so glad that everything is working for me. Unfortunately today I updated to 1.7.3 and since then I've had the problem with the Pi ver. 1.2 camera that it responds with a very time lag. That means with about 1min offset. sometimes faster. I've now flashed the 1.7.3 and the night version again, but to no avail.
When I call up the camera, it also takes a very long time for a picture to appear, as long as it writes that it is loading. I tried to go back to 1.7.2 but I couldn't do it
Edit: back to 1.7.2 and it works again immediately
Apparently something must have changed in the new 1.7.3, even if it wasn't intended. it kinda felt like a memory overflow like the stream was lagging.