When a USB camera is not a UVC webcam: what to do

You plugged a USB camera into Windows, opened the application, and the camera list is empty. The software enumerates standard webcams and nothing else, while the camera's own sample GUI shows a clean image. This dead end shows up with evaluation kits, RGBIR sensors and most industrial USB cameras, and it has one root cause: the camera does not implement USB Video Class.

This explainer gives you the rule that settles the case, why neither a driver nor a virtual-camera utility can change it, a bandwidth check that proves the connector was never the problem, and the three paths that work. You will finish knowing which path your project is on, and what to order if the answer is a different camera.

The decision, up front

A USB camera appears as a webcam if, and only if, its own firmware implements USB Video Class (UVC). Windows and Linux each ship one class driver for that standard, so a compliant device works with no vendor software installed, and a non-compliant device stays invisible to every webcam interface on the machine. Nothing you install on the host moves a camera from one side of that line to the other.

That leaves a three-way decision:

• The application must enumerate the physical camera itself, with no helper software: replace the camera with a UVC-compliant one, named as such in the interface specification before you order.
• You control the software on that PC: keep the camera and integrate its SDK, or run an SDK grabber that feeds a virtual webcam.
• The sensor is fixed but the product is yours: put a USB bridge with UVC firmware between your board-level sensor and the port.

The kit's own software showing a perfect image while the operating system lists nothing is the signature of this situation: two different protocols sharing one cable.

What makes a USB camera a webcam

Every USB device declares a class in its descriptors, the data structures the device itself sends during enumeration. UVC is the video class: it defines standard descriptors and streaming behaviour, so an operating system that implements the class once can receive video from any compliant device. Those descriptors and that streaming logic live in device firmware, which fixes the trait on the production line.

The practical reading of a datasheet: "driver-free" means the firmware already speaks the class and the operating system's inbox driver takes over. A support package that consists of an SDK, sample applications and a download portal describes the opposite arrangement, a vendor-specific interface that only the vendor's library understands.

The host still has to meet the device halfway. On embedded images the class driver must be present in the kernel: UVC-compliant USB cameras on embedded Linux: skip the driver rebuild covers that side, and what support a UVC camera needs on an industrial controller does the same for control hardware.

Why no host driver can add UVC

A driver binds to an interface the device offers. Your kit offers a vendor-specific interface for its SDK, and the descriptors it sends never announce a video-class interface, so the operating system's class driver, and any third-party one, has nothing to attach to. A "UVC driver for Windows" for such a device would not help either: the class protocol is spoken by the device, in firmware, and this device speaks something else.

This is why the advice to install a generic USB video driver is noise. Generic class drivers exist precisely for hardware that already declares the class. The only software that reaches your camera is the vendor's SDK, which is why the bundled GUI streams happily while everything else sees an unknown device.

Why a virtual webcam cannot rescue it

A virtual camera is a sink, not a source. It re-publishes frames another program on the same machine has already captured: a working webcam, a video file, a window. Out of the box it cannot attach to your kit, because the only route those frames take to the host is the vendor library, and no utility links itself into a proprietary SDK stream.

So a virtual camera is not a bypass of the SDK; it is a layer on top of one. If you may run your own service beside the application, a small SDK grabber feeding a virtual webcam is a real integration and it works. Budget about a frame of added latency and a pixel-format conversion, and accept that the application now drives a virtual device, with whatever exposure and trigger hooks your grabber passes through. If the application must enumerate the physical camera with no helper process, no software on that PC can produce that.

You can run that test with no hardware at all by feeding a virtual USB camera with test images.

Worked example: streaming 5 MP over USB 3.0

The case is the one that triggers this article: a 5 MP USB 3.0 evaluation kit whose RGB stream has to reach an application. Inputs: a 5 MP sensor at 2592 × 1944 pixels; 30 fps at full resolution; the class's standard uncompressed format, 8-bit YUV at 2 bytes per pixel; USB 2.0 High-Speed at 480 Mbit/s and USB 3.0 SuperSpeed at 5 Gbit/s of signalling.

The rule in words: multiply pixels by bytes per pixel and by frame rate, then by eight for bits.

• 2592 × 1944 = 5,038,848 pixels, about 5.0 MP
• × 2 B per pixel = 10,077,696 B per frame, about 9.6 MiB
• × 30 fps = 302,330,880 B/s, about 288 MiB/s
• × 8 = 2,418,647,040 bit/s, about 2.42 Gbit/s

Against the two buses: 2.42 Gbit/s is 5.0 times USB 2.0's 480 Mbit/s, which rules it out, and leaves about 2.1 times headroom inside USB 3.0's 5 Gbit/s, which is comfortable.

The decision: the USB 3.0 port on a 5 MP kit is doing genuine work, and compliant webcams run these same formats over this same pipe, so bandwidth is not why your camera is invisible. The missing class firmware is. Where webcams do survive on USB 2.0, they send MJPEG, compressed per frame and typically close to an order of magnitude smaller; that figure moves with scene detail and quality settings, so treat it as an estimate.

The three paths that work

For the build path, the bridge firmware is the whole game: what a MIPI CSI to USB UVC converter board must include lists the pieces, sensor-to-bridge pairing follows board-level camera and USB3 bridge board: match before you stream, and choosing a sensor and USB bridge for a UVC camera walks the format decisions. For the replace path, say so when you order: webcam enumeration is a per-model firmware trait, and we match the model to the requirement.

Cameras for the SDK path

Industrial machine-vision USB3 cameras sit on the USB3 Vision and GenICam standards and stream through their vendor SDKs, the same integration position as the evaluation kit, in a production housing with locking connectors. Filter the camera finder to interface USB3; both area scan cameras and board-level cameras carry them, and the camera step of the configurator narrows by sensor format and shutter.

For a bench inspection station, the LS-CMR-0166 is a 12 MP USB3 area scan camera on the IMX226, a 1/1.7" rolling-shutter sensor delivering 4000 × 3000 at 30 fps.

To embed the sensor in your own head, the MV-CB060-10UM-B is a 6 MP USB3 board-level camera on the IMX178, mono, with a 1/1.8" sensor supplied as a bare board.

Two compact C-mount options: the LS-BCM-0003 is a 3.1 MP USB3 board-level camera, IMX252, 1/1.8" global shutter, 120 fps; the LS-BCM-0047 is a 1.3 MP color USB3 board camera on a 1/2.7" sensor.

Every camera here is built for the SDK path: frames arrive in your software, in exchange for trigger, exposure and format control that a webcam never offers. On a moving bracket, keep the link stable with a drag-chain rated lead such as the LS-CBL-0219, a 3 m high-flex USB3.0 camera cable, from cables.

How to check before you order

• Read the interface line for the words "USB Video Class" or "UVC", often phrased as driver-free or standard webcam. An SDK, a sample GUI and a download portal describe the other kind of device.
• On arrival, plug into a clean system before installing anything: a compliant camera lists itself among the operating system's cameras on its own.
• Match the enumerated formats to the application: uncompressed and MJPEG entries at your resolution and frame rate.
• On an embedded or industrial controller, check that the OS image carries the class driver. A stripped kernel hides compliant cameras, and a UVC camera not recognized on an industrial controller is a kernel configuration fix.
• If a compliant camera shows only a generic name, reinstalling the device entry usually restores the proper one.
• Rate the cable for the motion it will see, especially on robots and gantries.

When the usual answer is wrong

• "Install a generic UVC driver." Class drivers bind to declared interfaces, and this device declares none. There is no host-side fix, only firmware or a different camera.
• "Any camera plus a virtual webcam." That works only with your own SDK grabber running, and the application then drives a virtual device: no hardware trigger, no exposure lock, unless your grabber implements them.
• "A webcam is good enough for inspection." Consumer webcams bring consumer controls, with no trigger input, no genlock and often a rolling shutter. When the task needs synchronized capture, renegotiate the webcam requirement instead of the camera.
• "UVC will carry the IR channel." The class moves standard video formats; a raw RGBIR frame, an IR plane or depth data is vendor payload, on the same boundary that means a ToF depth camera needs more than a USB UVC bridge.

A compliant camera that still does not appear is a host problem, not a camera problem: the kernel or driver image is missing the class support, which is the kernel-configuration case above.

Checklist before you commit

• Which side enumerates the device: the application itself, or a helper process you may run?
• The interface specification says USB Video Class.
• The standard format list covers your resolution and frame rate.
• The host image carries the class driver.
• The payload is standard video, not vendor data the SDK must unpack.
• The cable is rated for the motion it will see.

If the application must see the camera itself, the decision is a UVC-compliant model: tell us the camera-list requirement and we will match one. If you own the software, the SDK path is the stronger engineering position, and the finder links above narrow it to interface USB3 in a few clicks. More integration notes are on the systems topic page.