Quick answer: A USB video capture device takes an HDMI signal, decodes it to a digital video stream and sends it to the host as a USB Video Class camera, which is why it needs no driver. The payload decides the USB version: 1080p60 as uncompressed 8-bit 4:2:2 is about 249 MB/s, or roughly 2 Gbit/s, so it needs USB 3.0 and above. Compressed as MJPEG the same stream is 30 to 80 Mbit/s and fits on USB 2.0, at the cost of quality and latency. 4K30 uncompressed is about 498 MB/s, which is why most dongles cap 4K at 30 Hz.
Capture failures usually look like software failures: the preview stutters, the recording drops frames, or the device appears and disappears. Behind them is almost always a bus link that cannot sustain the stream, or an encoder that cannot compress it in real time. Working out which one requires a bandwidth calculation before a driver reinstall.
What the dongle actually does
HDMI receiver, then a video class device
An HDMI receiver chip locks to the incoming timing and hands the pixels to a bridge that presents itself to the host as a UVC camera. Because UVC is a standard class, Windows, macOS and Linux load a driver automatically, and any application that can open a webcam can capture from it. No vendor software is needed for basic capture, though vendor tools add features such as colour controls and firmware updates.
Encoder or no encoder
Cheap dongles always compress, usually to MJPEG, and the host decodes. Better ones offer uncompressed YUY2 as well, which uses more bus bandwidth but no compression artefacts and much less latency. Mid-range models add H.264 in hardware, which is efficient for recording but adds 50 to 150 ms of encode and decode delay.
The bandwidth arithmetic
Uncompressed is simple to calculate
Multiply pixels by bytes per pixel by frames per second. 1080p at 4:2:2 8-bit uses two bytes per pixel, so 1920 x 1080 x 2 x 60 is about 249 MB/s. Add USB protocol overhead and you need a 5 Gbit/s port with headroom, which is why some USB 3.0 hubs cannot carry two such streams at once.
Compression moves the problem to the CPU
MJPEG at quality 80 lands around 30 to 60 Mbit/s for 1080p60, which is comfortable on USB 2.0. The cost appears at the host: decoding several MJPEG streams consumes CPU and adds latency, and text or fine detail shows block artefacts. For a lecture recording that is acceptable; for measuring a reaction time it is not.
What each mode needs
| Mode | Payload | USB needed | Notes |
|---|
| 1080p30 MJPEG | 15 to 30 Mbit/s | USB 2.0 | Works on any port |
| 1080p60 MJPEG | 30 to 60 Mbit/s | USB 2.0 | CPU decode, mild artefacts |
| 1080p60 YUY2 | About 2 Gbit/s | USB 3.0 | Low latency, no artefacts |
| 4K30 YUY2 | About 4 Gbit/s | USB 3.0, direct port | Marginal through a hub |
| 4K60 H.264 | 20 to 50 Mbit/s | USB 3.0 | Encoder latency, needs HDMI 2.0 input |
Where capture setups break
The most common fault is a dongle on a hub shared with storage, so the video stream competes with a file copy and the preview drops frames while the recording continues. The second is HDCP: a protected source such as a streaming box will not deliver an image to a capture device, and the preview stays black with no error. The third is the wrong input timing, where the source outputs 1080i or an unusual refresh rate and the device silently converts it to 30 Hz.
Keep the capture path short. A USB-C to HDMI cable on the output side of a laptop and a direct USB 3 cable to the host is more reliable than any adapter chain, and a USB-A extension cable should be avoided entirely at these data rates because it adds a connector pair with no repeater.
Drivers, firmware and HDCP
UVC devices are driverless, but the HDMI receiver inside runs firmware, and that firmware decides which timings and which HDCP versions it accepts. A device that works on one computer and not another is usually negotiating a different HDCP revision, not missing a driver. Check the input spec for HDCP 2.2 support if the source is a protected 4K stream, and remember that a splitter or an AV receiver in the chain can strip HDCP and leave the dongle with a black input.
Practical scenarios
- Recording a camera feed for a webinar: 1080p30 MJPEG on a USB 2.0 port is stable and leaves the USB 3 controller free for storage.
- Measuring a mechanical process: use uncompressed YUY2 at 1080p60 on a direct USB 3 port, because encoder latency and frame reordering make timing measurements meaningless.
- Game capture from a console: check HDCP first, then confirm the source is set to 1080p60 rather than 4K30, since the dongle may downscale silently and add a frame of delay.
- Multi-camera classroom: give each dongle its own USB controller where possible; two uncompressed streams on one controller will not fit in 5 Gbit/s.
FAQ
Why is my capture device black?
HDCP on the source is the first thing to rule out; a protected stream refuses to authenticate and the device shows nothing. Next, check that the source resolution and refresh rate are within the device’s input range, and that the cable carries the full bandwidth, since a thin HDMI cable at 1080p60 is usually fine but at 4K60 is not.
Do I need USB 3.0 for 1080p60?
Only for uncompressed video. In MJPEG, 1080p60 fits in USB 2.0 bandwidth comfortably. If the software offers a YUY2 or NV12 mode, that mode needs USB 3.0 and a direct port rather than a hub.
Why does the preview stutter but the recording is fine?
The preview path is competing for CPU and GPU with the encoder. Reduce the preview resolution, disable deinterlacing in the capture application, or move the recording target to a different drive. A stutter that appears only in preview is a host performance issue, not a cable problem.
