USB3 bandwidth for a multi-stream pipeline: size each stream

You want everything a multi-sensor 3D camera can emit — color, the stereo pair behind depth, the rectified outputs and the IMU — captured for minutes or hours without a single dropped frame. Whether that fits on one USB3 link is not a vendor promise; it is one addition problem. Multiply fps × resolution × bytes per pixel for every stream, add the streams up, and compare the total with the roughly 400 MB/s a USB3 port delivers in practice. This guide runs that arithmetic on a realistic five-stream capture, shows where the identical wishlist breaks at full HD, and adds the queue, disk and exposure checks that decide whether frames survive the trip.

The ceiling that decides it: about 400 MB/s per USB3 port

USB3 in its 5 Gbit/s generation — sold as USB 3.0, SuperSpeed USB and USB 3.1 Gen 1, all the same speed — moves 5 Gbit/s of signaling. Under 8b/10b encoding every byte costs 10 bits, so the wire delivers 5 Gbit/s ÷ 10 = 500 MB/s of payload. Controllers and OS stacks rarely sustain all of it: about 400 MB/s is what real links deliver, so size your budget to 400 MB/s and treat 500 MB/s as the hard wall. The USB 3.0 signaling and rate reference has the encoding arithmetic.

Read "5 Gbps" on any spec sheet as 500 MB/s of payload, never 5 GB/s. And note whose budget it is: the port's, not the camera's. RGB, depth, mono and IMU from one multi-sensor camera share that single link, and so does any second device behind it. Whatever you enable, on whatever sits on that port, goes into one sum.

The formula: fps × pixels × bytes per pixel

One multiplication per stream settles the question. The only input engineers get wrong is bytes per pixel, so pin those down first:

Bytes per pixel is always bits ÷ 8. Use the format the SDK actually emits on the wire: depth shipped as 8-bit disparity costs half the 16-bit figure, and Bayer raw costs a third of demosaiced RGB888. Stream only the resolution your measurement needs — the depth-camera pixel size method sets that from the part, not the sensor. The same multiplication sizes any interface; the USB2 frame-rate budget runs the identical numbers against a far smaller ceiling.

Worked example: five streams at 1280×720 and 30 fps

Take the full wishlist: RGB888 color, 16-bit depth, both rectified mono feeds and the IMU, all at 1280 × 720 and 30 fps. The pixel count is 1280 × 720 = 921,600. RGB is the heaviest term, so follow it through completely: 921,600 px × 3 B = 2,764,800 B per frame, and 2,764,800 B × 30 fps = 82,944,000 B/s ≈ 82.9 MB/s. Every other stream repeats that pattern with a different byte count:

The sum is 82.9 + 55.3 + 27.6 + 27.6 + 0.01 ≈ 193 MB/s — 48% of the 400 MB/s ceiling, so the entire wishlist fits on one port with its headroom doubled. The IMU term looks absurd next to the others: a few dozen bytes, a few hundred times a second. It earns its row because it settles the question honestly and costs nothing. Recording the lot for an hour writes 193 MB/s × 3,600 s ≈ 700 GB, which any drive sustaining about 200 MB/s absorbs with room to spare.

Decision: at 1280 × 720 and 30 fps, enable all five streams. One port carries them.

The same pipeline at 1920×1080 busts the port

Full HD raises the pixel count to 1920 × 1080 = 2,073,600 — 2.25× the 720p frame. Nothing else changes and the sum crosses the wall:

435.4 MB/s exceeds the ceiling by 9% before the IMU is even counted. On paper that looks survivable; in practice three 30 fps streams burst together, the link saturates, queues fill and frames vanish without an error message. Shrink the largest term, RGB:

• RGB at 15 fps instead of 30: RGB halves to 93.3 MB/s, total ≈ 342 MB/s (86% of the ceiling) — fits, but thin.
• RGB888 to NV12 at 30 fps: bytes per pixel halves to 1.5, RGB again 93.3 MB/s, total ≈ 342 MB/s.
• Both levers together: RGB ≈ 46.7 MB/s, total ≈ 296 MB/s (74%) — comfortable margin.
• Drop the two rectified mono feeds and keep depth: total ≈ 311 MB/s (78%).
• Encode RGB inside the SDK instead of shipping raw pixels: that typically removes an order of magnitude from the RGB term, at the cost of compression artifacts.

Decision: at 1080p, five raw streams at 30 fps do not fit. Halve the RGB term once and you fit at 342 MB/s; apply both RGB levers and you land at 296 MB/s with real margin.

Frames drop in queues and disks, not on the wire

Under the ceiling is necessary, not sufficient. Frames are lost in the receive path far more often than on the wire: a callback that writes to disk inline stalls its stream, the camera-side queue overflows, and the SDK discards frames before your code ever sees them. Four rules keep a capture lossless:

1. Return from every receive callback immediately and hand each buffer to a writer thread.
2. Give each stream its own queue and consumer, so a slow depth consumer cannot starve the mono callbacks.
3. Size the disk by sustained write, not peak: a 193 MB/s capture needs a drive that sustains about 200 MB/s for the whole session.
4. Soak-test for 30 minutes with the SDK's queue-event statistics logged, and compare delivered fps against requested fps per stream; any gap marks a queue to fix, not bandwidth to buy.

Two failure modes deserve their own reading: Linux caps how much memory the USB stack may buffer per transfer by default, which is why two USB3 cameras at full resolution fail together, and a consumer pattern that only asks for the latest image drains nothing and returns duplicates. For long sessions, write into a container your analysis can reopen — the H5 recording workflow — and follow the disk streaming pattern for the writer threads.

Exposure time caps fps before bandwidth does

30 fps leaves a 33.3 ms period per frame, and exposure has to fit inside it. Auto-exposure drifting to 40 ms turns a requested 30 fps into a delivered 25 with nothing wrong in the bandwidth math. Stereo depth takes the hit twice: both mono sensors must finish their exposure before the depth engine has a pair to match. Bound auto-exposure below about 70% of the frame period — 23 ms at 30 fps — or lock it outright; the depth camera fps-drop diagnosis walks the checks.

Sizing a single USB3 area scan camera by the same math

The same multiplication tells you when one ordinary camera fills a port. A 12 MP sensor running 4000 × 3000 at 30 fps needs, at one byte per pixel, 4000 × 3000 × 1 × 30 = 360 MB/s — 90% of one port, workable only as that port's only tenant. The same frames at 3 bytes per pixel would need 4000 × 3000 × 3 × 30 = 1,080 MB/s, which no USB3 link carries; that is why 12 MP-class USB3 cameras stream 8-bit formats rather than raw RGB888. The LS-CMR-0166 streams 4000 × 3000 at 30 fps over USB3 — by this math it owns its port outright.

A 6 MP mono camera is the comfortable case. Six million pixels × 1 B × 30 fps = 180 MB/s, half a port; a second camera like it goes on its own port, not a shared one.

When streaming everything is the wrong plan

Some streams are derivable, and derivable streams are droppable. The rectified mono pair exists to feed stereo matching; once depth is computed, rectification can be re-derived offline from calibration you already hold. Keep the raw pair while you calibrate, drop it in production: the 720p wishlist then costs 82.9 + 55.3 + 0.01 ≈ 138 MB/s instead of 193. The same logic applies to the IMU when you need it only for coarse time alignment — a reduced sample rate costs nothing that matters. And when several depth cameras share one host, the budget moves from per-port to per-host: the four-camera host sizing guide covers that case, and one-stream-at-a-time isolation finds which device stalls a shared host.

The decision, and the checks before you record

Three lines, derived from the 400 MB/s ceiling:

• Total ≤ 300 MB/s (75% of the ceiling): record everything; the margin absorbs burst collisions.
• Total between 300 and 400 MB/s: fits only with non-blocking callbacks and proven sustained disk — soak-test before you leave the rig running unattended.
• Total above 400 MB/s: halve the RGB term first (frame rate or NV12), then drop derivable streams.

Applied to the examples: the five-stream 720p capture at 193 MB/s records everything at 48% of the port. The same wish at 1080p, at 435.4 MB/s, cannot; both RGB levers bring it to 296 MB/s, which does. A single 12 MP 8-bit camera at 360 MB/s records fine, alone on its port.

Before the first long session:

1. Write the per-stream table down: fps, resolution and bytes per pixel per stream, summed once.
2. Confirm the emitted formats — an RGB888-to-NV12 switch halves a term only if you caught it on paper.
3. Measure sustained disk write with a full-length test capture, not a spec-sheet peak.
4. Log queue events and delivered fps for 30 minutes before trusting the rig unattended.
5. Bound exposure below the frame period.
6. Keep one camera per host-controller port and no hubs in the capture path.

Multi-sensor depth cameras sit in the 3D sensors category; single-sensor USB3 capture comes from the area scan cameras page, filtered by interface in the camera finder. The camera configurator builds the chain end to end, and more multi-sensor reading sits with the 3D vision guides. Send us your stream list — fps, resolution and format per stream — through the contact page and we will total it against your link before you order.