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.
01 · Define workload
03 · How this works
Six constraints, one workload
Each pipeline stage is scored as required against available in the same unit. Under 80 % is PASS, 80–100 % is NEAR LIMIT, 100 % and above is FAIL. The primary bottleneck is the stage with the highest load, weighted by how severe its status is and how confident the underlying evidence is.
Decode is the vendor's number, not ours
NVIDIA publishes, per module and per codec, the maximum number of simultaneous streams at 8K30, 4K60, 4K30, 1080p60 and 1080p30 together with a megapixels-per-second throughput. When your profile is one of those points the published count is used and the row is evidence class A. Anywhere else the pixel rate of your streams is compared with that throughput and the row is class D — our interpolation of their table. H.264, H.265, AV1 and VP9 each use their own row; nothing is scaled from H.265. 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, memory, network
Inference uses the benchmark hierarchy — an EdgeAIStack measurement (B), then an external measured benchmark (C), then a model (D) — with multi-stream efficiency and power-mode scaling applied and the fallback chain reported. Memory is the shared budget used across engines: weights, runtime workspace, per-stream decode buffers, preprocessing, tracker state, OS and a reserve. Network uses the camera bitrate table against a 1 GbE ingress. Preprocessing is an engineering heuristic (E) on platforms without a host budget.
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.