zim wrote: ↑
Wed Aug 01, 2018 4:32 pm
I've started interacting with my new PiNoIR camera v2 using the v4l2 C API, and I must say that until now it's a bit of a let-down.
First I queried the device capabilities, and it's telling me that I can capture in RGB3 or BGR3 format in any resolution from 32x32 up to 3280x2464 with a step-size of 2. So far so good. But each time I try to set the pixel format with VIDIOC_S_FMT ioctl, I get error 22 (Invalid argument). This was at a resolution of 32x32. I kept hitting my head against a wall and tried with many other formats, and only 2-3 seemed to work (MJPEG and NV21 I think). Finally I tried with a different resolution, and at 320x240, I managed to set the format to RGB4, but the buffer isn't filled correctly (using mmapped io). Anyway, some wasted time later I tried 1024x1024, and didn't get the error anymore, but my program hangs when trying to stream. Finally, when setting it to 1920x1080, I'm able to actually capture images and write them to files, but the resolution if far too large for my intentions.
- Can any of the device capabilities reported by the v4l2 driver for bcm2835 actually be trusted, especially concerning resolutions available?
Yes, all the resolutions should be available.
It does lie on the framerate achievable as there are too many permutations available. The Pi camera is not as simple as most USB cameras in that there are multiple processing steps involved, and some are less optimised than others.
zim wrote: - How can I capture a 320x240 image (or similar size) in BGR3, RGB3 or similar format using v4l2? Is it even possible? Or will I need to convert needlessly from JPEG each time?
Code: Select all
v4l2-ctl -v width=320,height=240,pixelformat=RGB3
v4l2-ctl --stream-mmap=3 --stream-count=100 --stream-to=file.rgb
Should save you a file that is a concatenation of 100 rgb images.
Have a look in the dmesg logs to see what it's complaining about if S_FMT is failing.
Please confirm which distribution and kernel you are running. "uname -a" and "cat /etc/os-release". If other than Raspbian with a 4.14 kernel then you're a little on your own. I have a bundle of updates coming, and I think there is a minor regression on the latest mainline kernel.
You don't say in what way you believe the buffer is not filled correctly, but you MUST also abide by the bytesperline value returned by the driver. It may not be width * bpp as the GPU has other requirements on the stride of the image (normally a multiple of 32 pixels). There's also a vertical padding requirement so sizeimage may well be greater than bytesperline * height.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.