Multi Camera Test

Introduction

The DeviceHub Multi Camera Test previews two cameras side by side when your computer or phone exposes multiple video inputs through the WebRTC device enumeration APIs. Creators running a face cam plus an overhead document camera, teachers alternating between room-wide and desktop views, developers debugging exact deviceId selection in getUserMedia constraints, and IT staff validating USB docks with several webcams need concurrent visibility that a single-preview diagnostic cannot provide. This free browser page uses getUserMedia and mediaDevices.enumerateDevices to open distinct MediaStreams when the operating system, drivers, and browser jointly permit dual capture. Not every phone or laptop allows two open cameras at once, the test surfaces that limitation honestly instead of silently falling back to duplicate feeds. No native installer is required; everything executes locally inside a secure browser context with permission-gated labels. Understanding whether your hardware supports simultaneous streams saves hours of misconfigured OBS scenes or broken secondary-camera options in meeting software. Classroom AV staff validating document cameras plus presenter webcams before hybrid lessons use dual preview to confirm both deviceIds open without silent fallback to duplicate feeds. Hybrid event producers confirming presenter and audience camera paths before streaming to YouTube or Teams Live Events use dual preview to catch silent deviceId misconfiguration early.

What this tool does

The tool enumerates videoinput devices after an initial permission grant, lets you assign distinct cameras to two preview panes, and attempts to start separate getUserMedia calls with exact deviceId constraints for each selection. Each pane indicates whether its MediaStream is live, stalled, or failed so you can spot exclusive-access errors quickly without reading console logs. You can swap assignments between panes to verify deviceIds are truly distinct rather than accidentally opening the same sensor twice with different labels. Stopping releases both streams through track.stop() on every active MediaStreamTrack. The page is a concurrency and selection diagnostic, not a full production switcher, NDI router, or multi-track recorder. When dual open fails, you still learn which single camera works in isolation, a valuable narrowing step for support tickets blaming "broken second cam" hardware. When dual open succeeds, optional per-pane getSettings() readouts help confirm distinct width, height, and deviceId values rather than duplicated negotiation on one sensor.

When to use it

Use Multi Camera Test when building or supporting two-webcam setups for streaming or hybrid classrooms, when a meeting app's secondary camera option fails despite both devices appearing in Windows Device Manager, when validating that a capture card and a USB webcam both enumerate with unique deviceIds, and when confirming that a docking station does not drop the second device under sustained load. Workshop facilitators checking presenter and audience cameras benefit from a quick side-by-side sanity check before going live. QA engineers reproducing deviceId regression bugs across browser versions use it as a minimal reproduction surface. Mobile users should expect frequent single-camera limits due to OS policy. If you only have one physical sensor, the standard Webcam Test is the appropriate starting point rather than this dual-pane page. OBS users debugging which physical sensor maps to which browser deviceId before writing exact constraints in browser-source capture workflows benefit from side-by-side verification here. Help-desk scripts that ask users to verify a second USB webcam before approving hardware replacements can link directly to this concurrency diagnostic instead of vendor utilities.

How it works

After an initial getUserMedia grant, often with video: true to satisfy privacy rules for label disclosure, mediaDevices.enumerateDevices() lists videoinput entries including deviceId and label fields once the Permissions API allows friendly names to appear. Each preview pane requests its own getUserMedia({ video: { deviceId: { exact: id } } }) invocation to bind a specific sensor rather than accepting the browser default first available device. Successful negotiation yields two independent MediaStreams attached to two HTMLVideoElement nodes for side-by-side comparison in the same tab. Failure commonly surfaces as OverconstrainedError when a deviceId is stale after unplug, or NotReadableError when hardware cannot open both streams concurrently due to driver exclusivity or mobile OS policy. MediaStreamTrack.getSettings() can be read per stream to confirm distinct width, height, or deviceId values and catch accidental duplicate opens of the same physical sensor. HTTPS secure context is mandatory for enumerateDevices label disclosure and for concurrent getUserMedia calls with exact deviceId constraints on both preview panes in the same tab. Permissions API camera grant must precede meaningful enumerateDevices labels; without it, pane assignment dropdowns show opaque ids that are easy to confuse during dual-stream setup.

Step-by-step instructions

1. Connect every USB webcam or capture device you plan to test, confirm the operating system recognizes them in Device Manager or system settings, then open the Multi Camera Test page on DeviceHub over HTTPS.
2. Click Start and allow camera permission when prompted so mediaDevices.enumerateDevices() can return videoinput labels instead of blank strings tied to opaque deviceId values before grant.
3. Select camera A for the first preview pane and camera B for the second pane using distinct entries from the enumerated device list, avoiding two labels that might refer to the same underlying sensor hardware.
4. Start both previews and verify each HTMLVideoElement pane shows a unique moving image with independent motion rather than duplicated feeds or a frozen black tile indicating a failed second getUserMedia call.
5. If the second stream fails with NotReadableError, stop both previews, test each camera alone in single-device mode, then retry dual mode to determine whether the limitation is hardware exclusivity or a stale deviceId constraint.
6. Stop all active MediaStreamTracks before unplugging USB hardware so track.stop() releases driver locks cleanly and the OS does not leave a camera indicator stuck on after troubleshooting. Document browser engine and OS version when filing concurrent getUserMedia bugs.

Common problems

Many phones and some integrated laptops allow only one camera open globally regardless of browser engine, which manifests as the second getUserMedia call failing even though enumerateDevices lists two videoinput entries with distinct deviceIds. Windows applications using exclusive-mode capture can block the second stream until those apps close completely and release the sensor. USB bandwidth on unpowered hubs may drop the second 1080p camera or force both streams into unexpectedly low resolution modes during concurrent capture. Identical marketing labels can still map to different deviceIds, compare ids using Device Information if pane assignment seems ambiguous during setup. Browser engines differ: one may permit dual open on a given PC while another refuses with identical hardware, document engine version when filing concurrency bugs. Stale deviceIds after sleep, dock, or unplug events require refreshing enumeration before retrying exact constraints on the second pane assignment dropdown.

Privacy explanation

Both preview panes remain local to your browser session on your device; neither stream is uploaded, relayed through WebRTC, or stored on DeviceHub servers during dual-camera testing. Camera permission through the Permissions API is required to enumerate friendly device names and open hardware via getUserMedia for each pane. Stop all tracks with track.stop() to extinguish camera indicator lights and release sensors for Zoom, Teams, or OBS. Revoke site access when multi-camera troubleshooting is complete if you prefer not to retain grant for this origin. Dual capture does not create server-side recordings; both MediaStreams remain in your browser memory until track.stop() releases each sensor. Revoke site access when multi-camera troubleshooting is complete if shared workstations should not retain camera grant for this origin after IT validation finishes. Neither pane uploads frames to DeviceHub; both streams remain client-side until you stop all tracks explicitly.