Hey everyone, I’m having a weird issue with my Arducam B0498 (the USB3 one with the Sony STARVIS 2 IMX585 sensor, VID:PID 04b4:0498) on Linux. The camera seems to be detected fine — I get /dev/video0, /dev/video1, and /dev/media0 created, and dmesg shows the uvcvideo driver binding to it without any obvious failures. But no matter what I try, every viewer application just shows a completely black screen. The stream window doesn’t freeze or anything, it looks like it’s actively streaming, but there’s just… nothing. Has anyone run into this?
That’s an odd one, especially since the device nodes are being created properly. Can you try launching it with GStreamer from the command line and share what you see? Something like:
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! autovideosink
This will give us a baseline and should print some diagnostic info to the terminal. Also, which Linux distro and kernel version are you on?
Just tried the GStreamer command you suggested. The pipeline starts up and a window opens, but it’s just solid black. No error messages in the terminal output either — it negotiates the caps and starts playing, but the video is black. I’m on Ubuntu 22.04, kernel 6.2.0. Also tried pointing it at /dev/video1 just in case, same result.
Okay, that rules out a simple player issue. Let’s try a couple more tools to narrow things down. Give ffplay a shot — it tends to be pretty verbose about what it’s actually receiving from the device:
ffplay /dev/video0
Also try VLC. If both of those also show black, try actually recording a short clip with ffmpeg or similar and check whether the output file has any actual content or is just black frames.
ffplay is interesting — the window opens but the OSD overlay shows “nan” for the values and it’s all zeros. No actual image at all. VLC is the same story, just a black window. I also tested a handful of other v4l2-compatible viewers (guvcview, qv4l2, cheese) and they all show black.
As for recording: I recorded a short clip with ffmpeg and the file comes out with what looks like the expected file size for the duration, but when I play it back it’s completely black. So something is flowing through the pipeline, it’s just… black pixels.
That “nan” from ffplay is a pretty good clue — it suggests the frames being delivered don’t contain valid image data, even though the buffer sizes look right. Before we dig deeper, have you tried manually adjusting exposure and gain? Sometimes these USB cameras boot up with defaults that essentially produce no visible image until you crank those up. You can do it with v4l2-ctl:
v4l2-ctl -d /dev/video0 -c exposure_auto=1
v4l2-ctl -d /dev/video0 -c exposure_absolute=500
v4l2-ctl -d /dev/video0 -c gain=100
Try a range of values and see if anything changes.
Tried adjusting exposure and gain across a pretty wide range — auto exposure off, manual values from low to high, gain up and down. No improvement at all, still just black.
But I did dig through dmesg more carefully and found these errors that keep repeating whenever I access the camera:
Failed to query (GET_INFO) UVC control 2 on unit 2: -71
UVC non compliance - GET_DEF(PROBE) not supported
Those look like they might be relevant? The -71 is EPROTO I believe.
That’s the smoking gun right there. Those two errors together point to a specific underlying issue: your camera is enumerating as a USB 2.0 / UVC 2.0 device when it should be negotiating as USB 3.0 / UVC 3.0.
The Arducam B0498 is a USB 3.0 camera. When it falls back to USB 2.0 mode — which can happen due to cable quality, port negotiation issues, or hub topology — it gets detected as a UVC 2.0 device. The video device nodes still get created and streaming appears to work at the surface level, but the UVC protocol mismatch means the actual frame data never makes it through properly. Hence the black screen, the “nan” from ffplay, and specifically the GET_DEF(PROBE) not supported error (PROBE/COMMIT is a UVC 3.0 mechanism that doesn’t exist in UVC 2.0) along with the -71 on control unit 2.
Arducam has a troubleshooting guide specifically for this scenario. I’d start there — it covers checking which speed the device actually negotiated at and how to force proper USB 3.0 enumeration: Troubleshooting - Arducam Wiki
The key things to check: are you using the original cable? Is it plugged into a USB 3.0 (blue) port directly on the motherboard, not through a hub? You can also verify the current link speed by checking the output of lsusb -t or looking at the device in lsusb -v to see if it’s running at 480M (USB 2.0) or 5000M (USB 3.0).