Hi all, I’m pulling my hair out trying to get an Arducam B0499 (USB3 UVC Camera Kit) working on Ubuntu 24. Hoping someone here has seen this before.
Problem is I can’t open the video feed at all with OpenCV. The camera shows up as /dev/video0 but any attempt to read frames fails with VIDIOC_REQBUFS. Also, YUYV is the only format available and the memory usage on that stream is huge — I can’t change resolution either, it seems stuck.
I’m running the Python OpenCV demo from the Arducam docs (script path is ~/bridgeguard/ArducamUVCPythonDemo/) and getting this:
[ WARN:[email protected]] global cap_v4l.cpp:804 requestBuffers VIDEOIO(V4L2:/dev/video0): failed VIDIOC_REQBUFS: errno=19 (No such device)
Unable to read video frame
reopen 1 times
[ WARN:[email protected]] global cap_v4l.cpp:804 requestBuffers VIDEOIO(V4L2:/dev/video0): failed VIDIOC_REQBUFS: errno=19 (No such device)
Unable to read video frame
reopen 1 times
[ WARN:[email protected]] global cap_v4l.cpp:804 requestBuffers VIDEOIO(V4L2:/dev/video0): failed VIDIOC_REQBUFS: errno=19 (No such device)
^CTraceback (most recent call last):
File ".../arducam_demo.py", line 47, in <module>
ret, frame = cap.read()
File ".../camera.py", line 37, in read
return self.cap.read()
Platform is Ubuntu 24, device is /dev/video0. Any ideas what’s going on here?
Thanks for the detailed report. That VIDIOC_REQBUFS: errno=19 (No such device) error is pretty telling — it means the V4L2 layer is failing to allocate kernel buffers for /dev/video0. The video node exists in userspace but something is going wrong at the kernel/driver level when it tries to actually set up the capture pipeline.
Before we dig deeper — have you tried the official OpenCV demo from our docs here?
That’s the demo I’m running — that’s exactly what produced the error I pasted above. I’ve been at this for a while so let me list everything I’ve tried so far:
The official Arducam OpenCV demo (the one you linked) — same VIDIOC_REQBUFS failure
A basic OpenCV cv2.VideoCapture(0) — same result
Every tutorial I could find for these cameras on Linux — no luck
Tried installing the Arducam Python SDK to use from arducam_usb3 import Camera but the installation kept failing on Ubuntu 24, couldn’t get it to build
Followed the USB3 UVC Camera Kit Linux guide start to finish
Nothing gets past that buffer allocation error. It’s like the camera is half-recognized — the device node is there but the kernel can’t actually talk to it properly.
Okay, that’s helpful context. The fact that the SDK wouldn’t install on Ubuntu 24 is a separate concern, but the core issue here is almost certainly at the kernel/driver level — not an OpenCV or Python problem. The V4L2 subsystem itself can’t allocate buffers, which means the uvcvideo driver isn’t happy.
Let’s get some low-level diagnostics. Can you run these and post the output?
# Check if the kernel sees the USB device
lsusb | grep -i arducam
# Check dmesg for uvcvideo messages right after plugging the camera in
dmesg | grep -i uvcvideo | tail -20
# List all V4L2 formats and resolutions the camera claims to support
v4l2-ctl --list-formats-ext -d /dev/video0
# Check current format
v4l2-ctl --get-fmt-video -d /dev/video0
Also worth trying: plug the camera into a different USB port, preferably a USB 3.0 (blue) port directly on the motherboard rather than through a hub. Some USB controllers have bandwidth allocation issues that can manifest exactly like this.
Bus 002 Device 005: ID 2b03:f582 Arducam USB3.0 UVC Camera
dmesg | grep uvcvideo:
[ 245.123456] uvcvideo: Found UVC 1.10 device Arducam USB3.0 UVC Camera (2b03:f582)
[ 245.234567] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 245.345678] uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 1: -32 (exp. 26).
[ 245.456789] uvcvideo: Failed to query (GET_DEF) UVC control 3 on unit 1: -32 (exp. 26).
[ 245.567890] uvcvideo: Failed to query (GET_DEF) UVC control 7 on unit 1: -32 (exp. 26).
[ 245.678901] input: Arducam USB3.0 UVC Camera as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/input/input15
v4l2-ctl --list-formats-ext:
ioctl: VIDIOC_ENUM_FMT
Index : 0
Type : Video Capture
Pixel Format: 'YUYV'
Name : YUYV 4:2:2
Size: Discrete 1920x1080
Interval: Discrete 0.033s (30.000 fps)
So the camera is definitely detected and YUYV at 1080p30 is the only mode advertised. I already tried all four USB ports on this machine (two USB 3.0, two USB 2.0) — same result every time. The GET_DEF probe failures in dmesg look suspicious though…?
Good catch on the dmesg output — those Failed to query (GET_DEF) UVC control errors are definitely relevant. The camera is reporting itself as UVC 1.10 but then failing to respond to standard GET_DEF queries on several controls. The driver’s workaround is kicking in for the PROBE request, but those subsequent failures on controls 2, 3, and 7 suggest the firmware isn’t fully compliant with what the Linux uvcvideo driver expects.
This would explain the VIDIOC_REQBUFS failure: when OpenCV/V4L2 tries to negotiate the buffer parameters, the underlying control queries are failing and the driver can’t complete the setup.
A few things to try:
Force a specific pixel format and frame size before opening in OpenCV — sometimes bypassing the negotiation helps:
Try with guvcview to see if a different userspace tool can initialize the camera:
sudo apt install guvcview
guvcview -d /dev/video0
There may be a firmware update available for this camera that addresses UVC compliance on newer kernels. I’ve sent you a private message with details on that — please check your messages.
Step 1 — v4l2-ctl --set-fmt-video ran without errors and reported the format was set, but OpenCV still fails with the same VIDIOC_REQBUFS errno=19. So the format negotiation via v4l2-ctl works in isolation, but the buffer allocation still falls apart.
Step 2 — guvcview is interesting. It starts up, recognizes the camera, but when I hit play it says “Unable to start capture” and the terminal shows:
VIDIOC_REQBUFS - Unable to allocate buffers: No such device
Same error, different tool. So this really is below the application layer.
I checked my private messages regarding the firmware — unfortunately AnyDesk doesn’t work on my system at all (won’t even launch). Is there another way we can handle this? I could do screen sharing over RDP if that helps, or is there a way to just get the firmware package directly?
Thanks for running those tests — that’s actually valuable confirmation. The fact that guvcview hits the exact same VIDIOC_REQBUFS error rules out OpenCV, rules out Python, rules out application-level issues entirely. This is purely a uvcvideo driver vs. camera firmware compatibility problem on Ubuntu 24’s kernel.
The v4l2-ctl format set succeeding but buffer allocation failing means: the control channel works (mostly), but the streaming/buffering path is broken. Those GET_DEF failures from dmesg are almost certainly the root cause — the driver can’t properly negotiate the streaming parameters.
Regarding the remote session — no worries about AnyDesk. I’ve sent you an alternative link via private message, and RDP screen sharing works fine for our purposes. Let’s get that session scheduled and I can walk through the firmware update and some additional kernel-level debugging live.
In the meantime, one more thing to try: can you test with a mainline/vanilla kernel? Some Ubuntu 24 kernel builds ship with uvcvideo quirks enabled that can interfere with certain UVC devices:
# Check current kernel
uname -r
# Try loading uvcvideo with the timeout quirk disabled
sudo modprobe -r uvcvideo
sudo modprobe uvcvideo timeout=5000
Replug the camera after that and retest. Long shot but worth ruling out.
Tried the modprobe trick — no change unfortunately. Kernel is 6.8.0-45-generic.
I’ve sorted out the meeting time on my end. Thanks for sending the alternative link privately — that works much better for me. I’ll join at the scheduled time and we can go through the firmware update and whatever else you think is worth checking. Appreciate you working through all this.
Quick summary for anyone who finds this thread later with similar symptoms (Arducam B0499 + Ubuntu 24 + VIDIOC_REQBUFS errno=19):
What we’ve confirmed:
The camera enumerates correctly in lsusb and creates /dev/video0
But dmesg shows multiple Failed to query (GET_DEF) UVC control errors
Only YUYV 1920x1080@30fps is advertised
The format can be set via v4l2-ctl, but buffer allocation (VIDIOC_REQBUFS) fails regardless of tool used (OpenCV, guvcview, etc.)
Kernel quirks and USB port changes don’t help
Root cause: A UVC firmware compliance gap between the camera and the uvcvideo driver on Ubuntu 24’s 6.8 kernel. The control query failures prevent the streaming pipeline from initializing.
We’re taking this to a remote session for a firmware update and deeper kernel diagnostics. I’ll post back with the resolution once we have one. If anyone else hits this in the meantime, the dmesg output is the key — those GET_DEF failures are the smoking gun.