Two capture cards, one USB controller, no video
You added a second capture card to a machine with six free ports. One of them stopped working, and swapping ports did not help. Ports were never the constraint.
Your machine has six USB ports. They are not six lanes.
Behind them sit one or two host controllers, and every device on a controller shares that controller's bandwidth.
What a capture card actually asks for
An uncompressed 1080p60 feed in YUY2 is 16 bits per pixel. Multiply it out: 1920 times 1080 times 60 times 16.
That is about 1.99 gigabits per second. For one card.
USB 3.0 signals at 5 Gbps and delivers roughly 4 Gbps of payload after overhead. Two uncompressed 1080p60 cards ask for close to 4. There is no room left, and the second device is the one that fails.
The other port is usually on the same controller. You moved the device. You did not move the bottleneck.
How the failure looks
- The second card appears in the device list and shows a black frame.
- One card drops to 30 fps on its own, or falls back to a lower resolution.
- Both work until you start a webcam, and then one dies.
- Windows reports there is not enough bandwidth for this device.
That last message is the honest one. The rest are the same problem wearing different clothes.
What to do
| Fix | What it buys |
|---|---|
| Set the card to MJPEG or NV12 instead of YUY2 | NV12 is 12 bits per pixel, so about 1.5 Gbps. MJPEG is compressed and far smaller. Free, and often enough. |
| Split across controllers | Front-panel and rear ports are often on different controllers. So are add-in cards. |
| Add a PCIe USB card | A new controller with its own bandwidth. The reliable fix on a desktop. |
| Use internal PCIe capture | Skips USB. The right answer for a fixed rig with two or more feeds. |
Before you buy anything
Find out how your ports are grouped. On Windows, Device Manager can list devices by connection. On Linux, lsusb -t draws the tree.
Five minutes of that tells you whether you need a new card or just a different socket. Most of the time it is the socket.
Sources
The Rig Wire reports on streaming technology from public documentation, source repositories and vendor releases. We did not bench-test what is described here. When we have tested something, we say so.