Black picture box on USB camera decode: select the right device

A decode application shows a black picture box while the same USB camera plays live video in the Windows Camera app. That combination rules out a dead camera and points at the software: the application is opening a different capture device, most often the integrated webcam at device index 0, or reading a stream another program still holds. The checks below run in the order that finds the cause fastest. You will identify which device your code actually opened, free the stream, select the USB camera by index, and pin that choice so the box stays live on the next machine.

Why is the picture box black when the Windows Camera app shows video?

The cause is almost always a device mismatch, not a failed camera: your application opened capture device 0, which on a machine with an integrated webcam is that built-in camera or a stream another client already holds, not the USB camera you verified.

The Camera app switches devices with its change-camera control, so it shows the camera you verified regardless of enumeration order. A decode demo has no such switch: it opens the default device, renders whatever comes back, and paints nothing when no frames arrive. Reinstalling or downgrading the demo changes nothing, because the code still asks for device 0.

Separate the two black-box signatures before you touch anything. Black on every grab points at device selection. A live frame appearing now and then points at grab mode instead, which is a different fault with a different fix: see USB camera returns black images on most grabs: snap vs grab modes.

Which capture device is my code actually opening?

Without an explicit device index, capture libraries open device 0 by default; on a laptop or desktop with an integrated webcam that is the wrong camera, and with two USB cameras it is whichever one enumerated first.

Enumeration order follows the driver and the USB topology, so it is not stable across reboots. Probe before you decode: the loop below opens each index in turn, asks for a frame and reports which devices actually deliver.

import cv2

working: list[int] = []            # indices that delivered a frame
for index in range(3):             # int: tries 0, 1, 2
    cap = cv2.VideoCapture(index, cv2.CAP_DSHOW)   # DirectShow back-end
    for _ in range(5):             # let the driver settle
        ok, frame = cap.read()     # ok: bool; frame: image array
        if ok and frame.mean() > 0:
            working.append(index)
            break
    cap.release()

print(working)                     # [0, 1] means two live devices

cv2.VideoCapture, cap.read(), cap.release() and cv2.CAP_DSHOW are documented OpenCV names; working, index, ok and frame are illustrative variables with the types shown. The test is the printed list: an index lands in working only when a real, non-black frame arrived.

Read the result like this. [0, 1] means two live devices and your USB camera is index 1. [0] alone means the second camera is missing, busy or blocked. An empty list means every open failed, which is a pipeline or permission problem rather than a wrong index: Camera detected but cannot be opened: fix the capture pipeline covers the first case and Windows camera access permission: why apps cannot open a USB camera the second.

How do you point the decode at the right USB camera?

Close every other camera client first, then open the USB camera by the index your probe found (index 1 on any machine that also has an integrated webcam) and verify with a five-frame grab whose pixel values change between frames.

1. Exit every camera client: the Windows Camera app, conferencing tools, browser tabs running a video call. Exit, not minimize.
2. Run the probe from the previous section and note the indices that return frames.
3. Open the USB camera by that index explicitly, for example cv2.VideoCapture(1, cv2.CAP_DSHOW) on a laptop whose integrated webcam sits at index 0.
4. Grab five frames in a row and compare their mean pixel values. Five identical all-black frames mean the device opened but delivered nothing, which is the busy-device signature again.
5. If no index returns frames, fix the pipeline or the permission first, then come back to selection.

The same selection code acquires from the integrated camera when it is the only one on the bench; the pattern is in Use an integrated webcam for image acquisition in vision software.

Can another program hold the camera and black out my preview?

Yes: a Windows capture device generally serves one exclusive client at a time, so when the Camera app, a video call or a background service keeps the handle open, a second application's grab returns no frames and its picture box renders nothing.

The signature is clean: the box is black only while the other program runs and live again once it exits. Close candidates one at a time, Camera app first, then conferencing clients, then browser tabs, and grab after each; one of them will restore the stream.

Windows can share some cameras between apps through its frame-server service, but capture stacks that open the device directly, DirectShow-based ones in particular, receive no frames while an exclusive client holds it. The Linux equivalent shows up as device nodes that vanish when the second process starts; Camera device nodes disappear when a second application starts walks that case.

Why do two USB cameras work alone but fail together?

Bandwidth decides it: a 1920 x 1080 uncompressed YUY2 stream at 30 fps needs about 995 Mbps and a USB 2.0 port carries 480 Mbps raw, so two such cameras cannot stream uncompressed through one controller, and the failing camera shows up as a black box rather than an error.

Two cameras change the maths twice. MJPG compresses by roughly an order of magnitude at usable quality (an estimate, since detail-heavy scenes compress less), so two 1080p30 MJPG streams near 85-125 Mbps each fit on paper. Two uncompressed streams do not, and neither do two compressed streams behind one hub whose real throughput sits below the raw figure. Put each camera on ports that do not share a hub: rear-panel ports on a desktop, or a separate controller card for the third camera.

The other failure is a claim conflict: both decode threads race for the same device, one grab wins and the other shows black. Two cameras interface claim conflict: diagnose USB access diagnoses that case. A depth camera on the same machine behaves the same way, as Depth camera not detected: the integrated webcam conflict shows.

When should you stop fighting the webcam stack?

When the decode must run unattended, move to hardware that removes the desktop capture stack: a USB3 Vision camera whose SDK enumerates by stable device ID, a smart camera that decodes on the device itself, or a vision controller with one camera per port.

Desktop capture is built for one camera, one user and one window. Industrial acquisition is not: USB3 Vision and GigE Vision devices enumerate through GenICam with stable device IDs, so your code selects by identity instead of by index and never wins or loses a race for device 0. Browse the USB3 area scan cameras or the camera finder for the range. A 12 MP USB3 sensor with C-mount optics gives a decode station room to crop:

The LS-CMR-0166 pairs a 12 MP IMX226 sensor with 30 fps over USB3, and its 4000 x 3000 frames leave room to zoom in on a small label without a second camera. Most 1D and 2D decode stations need less: pick the smallest resolution that still delivers at least 3 pixels across the narrowest bar.

When the line needs verdicts rather than images, a smart camera decodes on the device and publishes results over Ethernet. No picture box, no capture pipeline, no device index. The smart cameras category exists for exactly this job: a unit that checks a label at line rate and reports pass or fail:

The LS-SMC-0063 runs a 1.6 MP sensor at 60 fps with its 16 mm lens, and the decode decision leaves the camera as a result message. If you would rather keep your own decoder, weigh the trade-off in Software barcode decode in your own camera app: build or buy a reader.

A multi-camera station adds a third requirement: ports. Give every camera its own port so enumeration stays stable and no two cameras share bandwidth, and drive the strobes from the same box. The vision controllers are sized for that:

The MV-VC2140-128G40-1T combines an Intel N-series processor, two USB 3 ports, four built-in light channels and 8 GB of RAM. That covers a two-camera decode cell with strobed illumination, one camera per port and the lights driven from the same box. Size the whole chain, camera, lens, light and controller, in the system configurator.

How do you stop the black box coming back on the next machine?

Pin the camera by a stable identifier, device path or serial number, not by enumeration order: index order follows driver load and USB topology, and one slow camera or a newly added hub moves every index after it.

Make the behaviour a checklist:

At start-up

• Enumerate every capture device and log its name and device path; the log turns a black box into a named wrong camera in one read.
• Match the wanted camera by serial number or device path, and fall back to an index only when the path is not exposed.
• Probe the chosen index with a five-frame grab and check pixel variance before you render or decode.

While it runs

• Show the opened device's name in the interface state, so a black box always says which camera failed.
• Treat five identical black frames as a busy device, not a decoder bug.

On exit and on the bench

• Stop acquisition and release the handle before the process closes, or the next start inherits a busy device; USB camera timeout on reopen: stop acquisition before you close shows the pattern.
• Keep two cameras on separate controllers and skip unpowered hubs.

Once the camera choice is settled, load the station into the configurator and let it pair camera, lens, light and controller in one pass; the systems guides on the hub carry the rest of the acquisition patterns.