A multi-camera Jetson bandwidth budget should follow each stream through its actual route: sensor output, SerDes link, deserializer CSI output, capture memory, and application workload. Adding camera megapixels or quoting a platform’s maximum camera count does not establish that a particular simultaneous configuration fits.
Build the budget from documented image modes and lane routing, keep assumptions visible, and verify the proposed set with concurrent capture. A pixel-rate calculation is a lower-bound planning tool, not a measured throughput guarantee. The acceptance test must use the same modes and processing path the application will run.
The BSP compatibility checklist establishes which combination is supported. This worksheet addresses capacity after that decision: how much load each stream contributes, where streams share resources, and what evidence confirms that the complete set runs together.
Inventory modes before calculating rates
For each camera, record active width and height, intended frame rate, transmitted pixel representation, sensor timing, metadata streams, CSI lane count, output lane rate, and capture representation. Include camera count, driver/BSP revision, and any preprocessing or conversion. Use the effective mode rather than a product’s largest advertised resolution.
The V4L2 image-format documentation distinguishes image representations. Keep wire bits per pixel separate from the bytes used in a captured buffer. A packed transport format can have a different memory footprint after capture or conversion.
Inspect the effective frame interval as well as the format. The V4L2 streaming-parameter reference describes frame-interval negotiation where the driver supports it. Save the returned setting and observed capture behavior, because an application’s requested rate is not itself a measurement of delivery.
Calculate active-image payload as a lower bound
For a simple planning calculation, active-image payload in bits per second is width multiplied by height, frames per second, and transmitted bits per pixel. Sum only the streams sharing the boundary being evaluated. Keep units explicit: bits per second for a serial-link budget and bytes per second for memory or storage.
Illustrative example: one 1280-by-720 stream at 30 frames per second and 10 transmitted bits per pixel has an active-image payload of 276,480,000 bits per second, or about 0.27648 Gbit/s. Two such streams total 0.55296 Gbit/s before additional traffic. These are arithmetic examples, not claimed modes or measured rates for any camera.
Do not label that lower bound “required lane speed.” It excludes whatever packet, metadata, timing, and scheduling effects apply to the actual transport. If the supplier provides a validated output rate, retain its assumptions and compare them with your selected modes. Avoid adding an arbitrary universal overhead percentage.
| Budget boundary | Input to record | What the active-payload sum omits |
|---|---|---|
| Sensor to serializer | Mode timing and transmitted representation | Device-specific timing and additional streams |
| GMSL link | Supported link configuration for each camera | Transport and control behavior of the chosen parts |
| Shared CSI output | Aggregated streams, lanes, output rate and routing | Packet scheduling and documented interface constraints |
| Capture memory | Actual buffer layout, stride and rate | Extra buffers and copies elsewhere in the pipeline |
| Application and recording | Conversion, processing, storage and concurrency | Load from the rest of the system |
Draw the shared CSI route explicitly
Map each camera to its serializer, deserializer input, output CSI port, lane arrangement, virtual channel, and receiving endpoint. Group streams by the output they actually share. A system with several camera connectors can concentrate traffic on one CSI route, while another design distributes it across different routes.
The NVIDIA r36.4.4 GMSL reference documents shared-port routing and lane-configuration constraints. Check your actual aggregator’s supported modes; virtual channels identify multiplexed streams but do not create additional physical lanes.
Use the selected carrier-board routing documentation to identify the physical connection. Do not infer it from a module’s overall interface capability. Keep board revision and any camera adapter revision alongside the route drawing.
The GMSL2 manufacturer guide provides transport and aggregation context. The exact SerDes parts and operating mode still determine applicable limits. Request a mode-specific supported topology rather than translating a headline link rate directly into a usable camera count.
Keep sensor clocks and output clocks distinct
Record the clock definitions used by the driver. NVIDIA’s sensor-driver programming guide distinguishes sensor pixel-clock information from SerDes output-clock information. They describe different boundaries; neither should be replaced by the application’s target frame rate alone.
Ask for the documented deserializer output rate, lane count, representation, and the calculation used for the configured SerDes clock. Compare those values with the effective configuration. A copied clock parameter can make an apparently conservative pixel budget irrelevant to the actual receiver setup.
For mixed modes, request explicit confirmation that the aggregator supports the combination. Different resolutions or rates may introduce constraints beyond their total active payload. Keep that supported-mode statement separate from the arithmetic so the worksheet shows which conclusions are documented and which remain assumptions.
Budget captured buffers and downstream copies
Use actual buffer stride and allocation information for the memory estimate. For a simple uncompressed single-plane buffer, bytes per line multiplied by height and delivered frames per second gives a starting byte-rate estimate. Multi-plane layouts need the corresponding plane sizes. Preserve measured or negotiated layout values rather than assuming width times wire bits per pixel.
As another illustrative example, storing the earlier 1280-by-720 image with a hypothetical 16-bit-per-pixel memory representation and no padding would require 1,843,200 bytes per frame. At 30 frames per second that is 55.296 MB/s per stream using decimal units. This is a representation example, not a specification for Jetson capture or a particular driver.
List each additional representation and copy: raw capture, processed output, application input, recording buffer, and any network output. Compression changes storage load but adds a processing stage. A camera can fit its input link while the complete workload misses delivery requirements elsewhere.
The sensor-fusion requirements guide helps define which representations the application actually needs. Avoid budgeting every hypothetical consumer when the intended product uses only a subset, but include the real LiDAR and other workloads in the concurrent test.
Validate with a concurrency acceptance matrix
Test each camera alone in the intended mode, then supported pairs, then the complete set. Repeat with the application’s normal processing and recording enabled. Keep camera identities distinct so two successful outputs are not accidentally copies of one stream.
For each row, retain requested and effective modes, observed frame delivery, gaps or errors, output identity, resource observations, and the test interval. Agree acceptance criteria from the application before comparing results. Keep a failed row as evidence and change one justified variable before repeating it.
Do not treat reduced resolution or rate as proof that the original configuration was within capacity. It is a different operating point. Document whether the change addresses a supported mode restriction, a shared-route limit, or a downstream workload boundary.
Concurrent throughput also does not establish synchronized acquisition. Use the clock-check guide when alignment matters. Preserve the final budget, routing plan, source documentation, and capture matrix with the selected camera models so the qualification can be repeated after a hardware or software change.
Frequently asked questions
Can I divide a headline link rate by the pixel-rate estimate?
That gives an incomplete planning comparison. Include documented transport and topology constraints, then verify the complete supported configuration.
Do virtual channels add bandwidth?
No. They identify streams sharing a route. Physical lanes, configured output rates, supported modes, and downstream capacity remain separate constraints.
Is transmitted bit depth equal to captured bytes per pixel?
Not necessarily. Inspect the actual memory representation, stride, and plane sizes before calculating buffer or storage load.
What proves the proposed camera set is usable?
A documented supported topology and repeatable concurrent capture in the intended modes with the normal application workload, judged against predefined criteria.
