How many camera streams can this hardware actually handle?
Decode, encode, inference, preprocessing, memory and network are evaluated together for one workload. Decode capacity comes from NVIDIA's own per-codec tables with the datasheet section cited; the result says what breaks first and how many streams are comfortable, likely viable, and one too many.
Method v1.8.0 · data verified 2026-09-29 · registries: decode-capacity, hardware-capabilities, benchmark-corpus, benchmarks-v2, camera-bitrate-behavior, camera-interfaces, production-carriers · methodology
01 · Define workload
03 · How this works
Pipeline constraints for this workload
Each quantitative stage is evaluated by the shared constraint kernel. A stage remains PASS up to and including its capacity limit. Robustness is reported separately as COMFORTABLE, TIGHT or AT_LIMIT according to the shared policy. Above the limit, the stage is FAIL. Filling a limit exactly is still a fit with zero headroom, not a failure.
Current bottleneck
The current primary bottleneck is the eligible independent quantitative constraint with the highest utilisation at the requested workload. Evidence strength does not change bottleneck ranking.
Stream capacity
The engine re-runs the complete pipeline at stream counts 1, 2, 3 … up to the first failure (or 64). Comfortable is the largest count where every material quantitative constraint is COMFORTABLE. Near limit is the largest count with no FAIL where at least one stage is TIGHT or AT_LIMIT. Modeled ceiling is the largest count with no required FAIL (filling a limit exactly is still a fit with zero headroom). Fails at is modeled ceiling plus one when a failure exists; the capacity ceiling names which constraint fails there. Validation-limited landmarks are reported when a required INDETERMINATE appears before the modeled maximum.
Decode
Decode starts from the vendor's published codec capacity. When your resolution and frame rate match a published operating point the row stays evidence class A and the datasheet source is attached. Unpublished profiles are modelled (class D) by comparing pixel rate against the published throughput for that codec — never scaled from another codec. On Orin the NVDEC clock is the same in every power preset; on Thor the datasheet publishes a table per mode and the tool switches with your selection.
Inference
Required throughput is cameras × detection frame rate. Available throughput follows the benchmark hierarchy — EdgeAIStack measurement (B), external measured benchmark (C), then model (D) — with multi-stream efficiency and power-mode scaling where calibrated. The evidence chain on the result row shows how the available figure was derived.
Memory
Memory uses the shared budget model across engines: weights, runtime workspace, per-stream decode and preprocess buffers, tracker state, OS reservation and a percentage reserve. Expand the memory row for the component breakdown and formula.
Network
When cameras arrive over Ethernet, network compares peak bitrate from the camera bitrate table against ingress from the carrier, module MAC or a 1 GbE planning assumption. The row shows the capacity basis and whether a carrier was selected.
Link
When the camera link is not Ethernet, the camera-interface stage budgets CSI-2, USB or GMSL2 instead and the network ingress row is not applicable. Carrier and sensor selections refine lane counts and bit depth.
Encode
Encode is evaluated only when recording re-encodes or restreams. Passthrough recording and record-as-is modes leave encode not applicable and are listed under the constraint table.
Host-side budget for accelerator cards and SBC NPUs
Hailo-8, Hailo-8L, Hailo-10H, Google Coral and RK3588 platforms only run the model on the card or NPU — the host CPU still decodes the stream (in software when the host has no hardware decoder for the codec), resizes and normalises every detection frame, copies it across the card's interface, and runs post-processing. For these platforms three more rows appear: Host CPU (CPU-ms/s used against cores × a fixed budget), Host link (MB/s of detection frames against the interface's throughput) and Preprocessing (the host's own resize rate). Choose the host — Raspberry Pi 5, an x86 mini-PC, or the RK3588's own cores — and the interface it is attached through (a PCIe HAT, a USB accessory, or integrated for the RK3588), or leave the platform's default in place. The result page's Host budget block lists the resolved host, interface, core count, whether decode ran in hardware, the per-frame timings and the link throughput used. Full formulas and sources: host-side budget methodology.
Full formulas, data tables and what invalidates a result: methodology. Static tables: decode capacity by Jetson module.