Multi-camera RGB depth bandwidth: size a four-camera host

Four cameras can expose a host bottleneck that remains invisible during single-camera testing. Adding a faster processor or graphics card may not help when every camera shares the same constrained USB path. This guide is for engineers specifying a dedicated host for simultaneous RGB and depth recording. You will calculate the data budget, identify shared resources, and build a staged acceptance test before committing to hardware. The worked example uses application requirements, not specifications for any catalog camera.

Define the capture contract before choosing hardware

For multi-camera RGB depth bandwidth, start with the streams the application must preserve. Specify camera count, image dimensions, frame rate, pixel format, timestamps, recording duration and permitted frame loss. Also distinguish raw acquisition from alignment, filtering, point-cloud generation and display.

For the worked example, assume:

• Four cameras, each delivering RGB and depth.
• Both images contain 1280 × 720 pixels at 30 frames/s.
• RGB arrives as uncompressed, three-byte color pixels.
• Depth arrives as two-byte values.
• Every image must be recorded without intentional frame dropping.

These are hypothetical application settings. Actual transport formats may differ from the images exposed by your software. A device might transmit compressed color, additional infrared images, or padding that changes the bandwidth requirement.

The first purchasing decision is therefore about architecture: choose a host whose USB controller paths, memory system and storage can sustain the required workload together. Processor and GPU selection come after that transport check.

If camera technology is not settled, start with the 3D sensors category and camera finder. Verify simultaneous stream modes and the manufacturer's supported interface before sizing the host.

Calculate payload bandwidth and state the assumptions

For an uncompressed stream, payload follows directly from image size, pixel storage and frame rate:

Use decimal units here: 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes. Do not mix these with binary memory units when comparing measurements.

The combined application payload is therefore approximately 553 MB/s. Expressed in bits, 552.96 × 8 = 4423.68 Mb/s, or about 4.42 Gb/s.

That is not a complete USB link budget. Transport overhead, scheduling, other endpoints and any additional streams still need accounting. A nominal interface rate is not a promise of equivalent usable image throughput.

Measure both the negotiated camera transport and the frames your application receives. A conversion from packed color to three-byte color can increase host-side traffic without increasing camera-side traffic.

If you reduce dimensions, confirm where the reduction happens. Source-side camera ROI cropping explains why resizing after reception does not relieve an already saturated camera link.

Map USB controller paths, not just connector counts

Separate physical connectors do not necessarily provide independent bandwidth. Several sockets may feed one hub, one host controller, or another shared upstream resource. A powered hub can address some power limitations without adding upstream data capacity.

Record the complete connection path for every camera:

1. Camera and cable.
2. Intermediate hub or extension, if present.
3. Host USB controller.
4. Adapter upstream connection and expansion-slot configuration, where applicable.
5. Other active devices sharing those resources.

Use the operating system's device topology information and the host manufacturer's documentation. Label physical ports so the validated arrangement can be reproduced after maintenance.

The frame grabbers and interface adapters category includes different acquisition interfaces. For a USB camera, select a suitable USB adapter rather than assuming any frame grabber provides USB connectivity.

The MV-GU2204 is a catalog USB adapter candidate. Its listing alone does not establish independent controller paths, aggregate sustained throughput, or compatibility with your camera software.

Before selecting an adapter, confirm controller topology, operating-system support, upstream bandwidth and power requirements. Check the installed slot's electrical connection rather than relying on its physical length.

A useful experiment is to move one camera to a documented separate controller while leaving all stream settings unchanged. Improvement suggests a shared-path constraint, although it does not identify the exact cause by itself. For additional enumeration and startup checks, use the multiple USB depth cameras startup troubleshooting guide.

Budget memory traffic, processor time and GPU transfers

RAM capacity determines how much you can retain. Memory bandwidth and software ownership determine how efficiently frames move through the pipeline. A large memory allocation cannot compensate for an acquisition rate that continuously exceeds processing or storage capacity.

For the example, a two-second raw buffer requires:

That excludes SDK buffers, queue metadata, alignment padding, converted images, point clouds and the operating system. Count each representation that remains alive concurrently rather than multiplying one image size by an arbitrary safety factor.

A full host-memory copy reads the source and writes the destination. Copying the entire example payload once adds approximately 552.96 + 552.96 = 1105.92 MB/s of memory traffic. Multiple copies multiply that cost, even though the camera link carries the original payload only once.

Trace ownership at each boundary: acquisition, processing, display and recording. Consult camera frame memory lifetime before replacing copies with borrowed buffers; avoiding a copy is not useful if the underlying image becomes invalid.

Convert processing time into a CPU budget

Four cameras at 30 paired RGB-depth captures per second produce 120 pairs/s. If processing takes 8 ms of CPU time per pair, the workload consumes:

That approaches one fully occupied core before acquisition, conversion, recording and other work. At 20 ms per pair, demand becomes 2.4 CPU-seconds per second. Parallel execution may help, but serial stages and shared locks can prevent useful scaling.

The per-camera interval is approximately 33.3 ms. A single serial worker handling all cameras instead has an average budget of about 8.33 ms per pair. Measure individual core usage and stage latency, not only total processor utilization.

Require an explicit GPU execution path

Installing a GPU or compiling optional acceleration support does not prove that processing uses it. The application must invoke supported accelerated operations through the software layer that actually handles the frames.

An intermediate wrapper may expose only CPU processing, even when an underlying library contains GPU implementations. Verify documented API support and measure transfers, execution and synchronization separately.

A useful timing model is:

Keeping several operations on the GPU can reduce repeated transfers. Uploading and downloading around every small operation can erase the benefit. Use slow GPU image-processing diagnosis when acceleration is enabled but throughput remains disappointing.

Size storage for sustained recording, not short bursts

With no compression or container overhead, ten minutes of the example capture produces:

Allow additional capacity for indexes, metadata, temporary files and the required free-space reserve. Do not assume a compressed recording will achieve a fixed ratio; scene content and codec settings change both size and processing demand.

As an initial engineering target, a sustained write budget of 1.5 times the raw payload would be 552.96 × 1.5 = 829.44 MB/s, approximately 830 MB/s. This is a planning allowance, not a universal requirement or a guarantee of successful capture.

Validate the actual recorder, filesystem and target drive over the intended recording duration. A short benchmark may measure cache performance rather than sustained writes. Include representative free-space conditions and any competing writes expected during operation.

Monitor queue occupancy alongside disk throughput. A queue that grows steadily indicates a sustained deficit; increasing its capacity merely postpones failure. For alternative storage representations, review reducing depth recording file size, then repeat the CPU and quality checks after changing the format.

Validate the host through staged load tests

Change one workload dimension at a time. Save the configuration and measurements from every stage so a failure can be associated with a specific addition.

1. Establish the single-camera transport baseline

Run one camera with the required RGB and depth modes. Disable display, optional processing and recording. Retain the minimum frame handling required for valid acquisition.

Record delivered frame rate, timestamp intervals, frame identifiers where available, error counts and negotiated connection speed. Confirm that your diagnostic loop does not retain frames indefinitely.

2. Add cameras on documented controller paths

Repeat with two, three and four cameras. Keep formats and application behavior unchanged. Measure each camera separately so a healthy aggregate rate cannot hide one struggling stream.

If the failure appears only when cameras share a controller path, repeat with a different allocation. If it follows a particular camera or cable, investigate that component before changing the host specification. The USB camera disconnection guide covers that separate fault-isolation path.

3. Add recording without processing

Write the intended recording format to the intended drive. Log write latency, throughput and queue depth. Run long enough to exceed temporary buffering and expose sustained behavior.

Compare acquisition counters with recorded frames. Successful writes do not prove every acquired frame reached the recorder, especially if queues silently discard old data.

4. Add processing one stage at a time

Enable alignment, filtering, reconstruction or other required operations individually. Measure CPU time, elapsed latency, retained memory and copies after each addition.

Only then compare documented CPU and GPU implementations using equivalent inputs and output checks. If a depth pipeline stops producing output, the point-cloud pipeline load guide helps separate acquisition from downstream processing.

5. Add display, synchronization and normal background work

Introduce the final preview arrangement and operational background tasks. Preview can use a reduced update rate if recording still receives every required frame.

Also verify timing independently of throughput. Four complete recordings need not represent simultaneous exposures. Use the multi-camera RGB exposure-timing guide when temporal alignment matters.

Finish with repeated application restarts and the full intended recording duration. A brief successful demonstration is not an acceptance test.

Turn the measurements into a purchasing specification

Specify measurable requirements instead of selecting a processor family or graphics-card tier by reputation.

Select cables by connector compatibility, documented interface support and routing requirements. The LS-CBL-0219 is listed as a high-flex USB camera cable. Verify suitability for the selected camera and host rather than treating that description as a compatibility guarantee.

Use the cables category and accessories finder to shortlist connection hardware. Test the exact cable arrangement intended for deployment; replacing it after validation introduces a new variable.

For a separate host shortlist, compare industrial mini PCs against your measured requirements. Confirm operating-system support, controller topology, expansion options and storage configuration for the exact configuration under consideration.

Check acceptance criteria and recognize the exceptions

Write pass criteria before the final test. For a lossless recording task, a reasonable starting checklist is:

• Every required stream maintains its requested delivered rate over the full run.
• Frame counters and timestamps show no unexplained gaps or duplicates.
• Recording counts reconcile with accepted acquisition counts.
• Queue occupancy remains bounded rather than trending upward.
• Memory use stabilizes after initialization and normal buffering.
• CPU, GPU and storage measurements retain headroom under expected background load.
• The tested port allocation and cable arrangement are documented.
• Restart behavior is repeatable without changing the validated configuration.

Not every application needs every stream at maximum settings. Lowering RGB frame rate may preserve the depth measurements that matter. Reducing depth dimensions may be unacceptable for small features even when it solves transport load. Treat either change as an inspection decision, not merely a performance adjustment.

Likewise, compressed transport can relieve a link while increasing decode demand. GPU processing cannot fix a constrained USB path, and separate controllers cannot repair an overloaded recorder.

If transport and resource measurements remain healthy but acquisition still stalls, switch to the closest software diagnostic path: multi-camera callbacks and buffer queues. That investigation addresses ownership and scheduling rather than host purchasing.

Move from a test budget to a validated system

Prepare a requirements sheet containing the stream contract, controller map, payload calculation, processing timings, sustained recording measurement and acceptance results. Ask for configuration-specific confirmation wherever the catalog does not establish compatibility or aggregate performance.

Use the accessory configurator to assemble the connection shortlist, or contact applications support with your measurements and required recording duration. The next useful step is a documented load test on the proposed configuration, not an isolated upgrade chosen without a bottleneck measurement.