How the Camera Stream Capacity engine decides what breaks first.

Contents

1. What it computes, and what it does not
2. Constraint objects and status thresholds
3. Decode stage
4. Encode stage
5. Inference stage
6. Preprocessing stage
7. Memory stage
8. Network stage
9. Host-side budget (accelerator cards and SBC NPUs)
10. Primary bottleneck and headroom ladder
11. Evidence classes and the confidence rule
12. Data tables and sources
13. What invalidates a result
14. Method changelog

1. What it computes, and what it does not

The engine evaluates a camera pipeline stage by stage: hardware decode, hardware encode (only when recording re-encodes or restreams), inference, preprocessing, memory and network ingress. Each stage becomes a constraint: a required amount and an available amount in the same unit, a utilization, a status, an evidence class and the sources the available amount came from. The output is the list of constraints, a ranked bottleneck list, a headroom ladder (how many cameras are comfortable, likely viable, and where it fails) and a confidence label per stage.

It does not predict throttle temperatures, model accuracy, end-to-end latency, or anything about the camera itself (lens, sensor, RTSP stack). It does not model MJPEG decode (NVJPEG) yet. Hailo-8/8L/10H, Google Coral and RK3588 platforms get a modelled host budget (§9) for decode, pre/post-processing and the card's interface; every other non-Jetson platform still falls back to a labelled modelled decode ceiling only. Inference and memory are estimates from benchmark tables and a memory model, not measurements of your build. Where the engine has no data it returns UNKNOWN or UNSUPPORTED rather than a guess.

2. Constraint objects and status thresholds

Every stage returns the same shape. Utilization is required over available, rounded to four decimals; status follows fixed thresholds that are identical for every stage and every engine on the V2 framework.

Two more statuses exist in the shared schema, REQUIRES_VALIDATION and VERSION_RISK, for stages that depend on a software configuration the engine cannot see. Version 1.0 of this engine does not emit them.

3. Decode stage

Decode is measured in megapixels per second (MP/s) so that any resolution and frame rate can be compared against the vendor's rated throughput. The required side is arithmetic on your inputs; the available side comes from the NVIDIA datasheet row for the module and codec.

Class A path. When your profile is one NVIDIA prints (for example 18 × 1080p30 H.265 on Orin NX), the engine uses that stream count verbatim and converts it to MP/s only so the required and available sides share a unit. Nothing is scaled. The source line under the row names the datasheet, revision and table.

Class D path. For any other profile (1440p, 20 fps, 25 fps, 2688×1520 and so on) the engine compares your pixel rate against the MP/s figure NVIDIA rates the decoder at for that codec. The number is therefore ours, not NVIDIA's, and the row is labelled class D with the assumption spelled out. The pixel-rate path assumes NVDEC throughput is roughly linear in pixel rate between published points, which holds within the published range and is not asserted outside it.

Adjustments. YUV 4:4:4 halves the available figure (datasheet note). 10-bit Main10 uses the same row as 8-bit Main, as the datasheets list them together. Thor tables are per NVDEC instance; the engine multiplies by the instance count exactly as the datasheet's "Total Mpix/sec (2x)" column does. Orin tables are already per module. If the module publishes no row for the codec (for example hardware AV1 on a module without it) the status is UNSUPPORTED.

Power mode. On the Orin family the NVDEC maximum clock is the same in every nvpmodel preset, so the power mode does not change decode capacity. This is a class A statement from NVIDIA staff (forum thread 380328, 17 Aug 2026). On Thor the NVDEC clock follows the power mode (1.56 GHz at 120 W and 70 W, 1.69 GHz at MAXN) and the datasheet publishes separate tables per mode, which the engine selects from the power_mode input.

Non-Jetson platforms. Hailo-8/8L/10H, Coral and RK3588 use the host's own decoder instead of this ceiling — hardware when the host has one for the codec, else software on the host CPU (see §9). Any other non-Jetson platform falls back to EdgeAIStack's modelled host-decode ceilings (class D, LOW confidence): per resolution at 30 fps, derived in the Stream Calculator research series.

4. Encode stage

The encode constraint appears only when recording is set to re-encode or restream is enabled. Passthrough recording writes the camera's own bitstream and needs no encoder. The arithmetic mirrors decode: a published NVENC point is class A, a pixel-rate comparison against the rated encoder MP/s is class D. Modules without a hardware encoder for the requested codec fall back to the codec they do publish (H.265, then H.264) and say so.

Jetson Orin Nano has no NVENC. The datasheet states "1080p30 Supported via CPU Cores with Software"; the engine treats that as a total software encode budget of one 1080p30 stream (62.2 MP/s), class A, and warns that re-encoding competes with inference for CPU cores.

5. Inference stage

Required throughput is cameras × detection frame rate, in frames per second. Available throughput starts from a single-stream benchmark for the platform, model family, variant, precision, runtime and detection resolution, found through a fixed lookup hierarchy, then scaled for multi-stream efficiency and the power mode.

The chain the lookup walked is reported in the constraint detail. A class C benchmark that had to be resolution-scaled or power-mode-scaled is downgraded to class D, because the resulting number is no longer the published one. The multi-stream efficiency table and the power-mode multipliers are EdgeAIStack calibrations carried over from the Stream Calculator research series (P170 to P176); tracking overhead is listed as an assumption and not yet deducted.

6. Preprocessing stage

Resize and colour conversion before the detector are budgeted as a fixed number of detection frames per second per node: 480 frames/s on the hardware path (VIC or GPU), 120 frames/s on the CPU path. These are engineering heuristics (class E, LOW confidence) and the result page says so. Measure with tegrastats before relying on this row; a measured host-side budget module replaces it in a later package.

7. Memory stage

Jetson modules share one memory pool between CPU and GPU, so the budget is a single sum compared against the module's installed memory. Every part is listed in the assumptions on the result page.

The model is class D with MEDIUM confidence: the part sizes come from EdgeAIStack measurements and community reports collected for the Memory Estimator, but your runtime, plugins and container overhead can move the total by hundreds of megabytes.

8. Network stage

Required ingress is the summed peak bitrate of all cameras from the shared camera bitrate table (resolution × codec × frame rate, moderate scene complexity), compared against a 1 GbE ingress port of 1000 Mbit/s. AV1 uses the H.265 row and is flagged, since AV1 typically lands 20 to 30 % lower. This is class D, MEDIUM confidence, and it says nothing about switch backplanes, PoE budgets or Wi-Fi; those live in the Network Bandwidth and Power Budget engines.

9. Host-side budget (accelerator cards and SBC NPUs)

Hailo-8, Hailo-8L, Hailo-10H, Google Coral and RK3588 (hailo_8, hailo_8l, hailo_10h, coral_tpu, rk3588_npu) run the detector on a card or NPU, but the host still decodes the stream, resizes and normalises every detection frame, copies it across the card's interface, and runs post-processing. For these platforms the engine adds three constraints — cpu, interface and preprocessing — built from an explicit or defaulted host (raspberry_pi_5 · x86_mini_pc · rk3588_integrated) and interface (pcie_gen2_x1 · pcie_gen3_x1 · pcie_gen3_x4 · usb3 · usb2 · integrated). Jetson and server-GPU platforms run their own pipeline and reject a host input. Decode for these platforms is described here, not in §3: the decode row uses the host's own hardware decoder when it has one for the codec, else software decode on the host's cores.

The CPU and preprocessing constraints share the same 80% utilisation budget — the CPU row is the ms/s ceiling, the preprocessing row is the frames/s equivalent of the pre-processing half of it — so on a bottleneck run they move together. The interface required side charges 256 KB per detection frame beyond the raw pixel tensor for results and metadata (class E).

Hosts

The x86 mini-PC row is a deliberately generic 4-core class (an Intel N100 or similar Core i3) with no single vendor datasheet — its CPU class, hardware-decode figure and preprocessing scale (×0.6, faster than the Pi 5) are engineering estimates, class E throughout.

Interfaces

Per-frame host processing (ms), by detection input size

Class D — EdgeAIStack corpus timings (P147 Raspberry Pi 5 + Hailo-8 / Coral USB3, P141 RK3588), split 60/40 pre/post (class E). The x86 mini-PC row scales the Hailo/Coral tier by ×0.6 (class E, faster CPU class).

On the x86 mini-PC these figures are multiplied by 0.6 before the 60/40 split. The nearest tier by pixel count is used when the detection size falls between published points.

Evidence classes used here

• A — vendor figures: Raspberry Pi 5 core count and CPU, PCIe 2.0 x1 and USB 3.0/2.0 ports, the HEVC 4Kp60 decoder, the AI HAT+ connecting over PCIe; RK3588 core count, decoder ceiling and 2D acceleration; the M.2 HAT+ 500 MB/s peak figure.
• D — EdgeAIStack corpus per-frame timings (P147, P141); the PCIe 3.0 x1 985 MB/s figure derived from the published lane rate.
• E — the pre/post 60/40 split; the 80% CPU utilisation budget; the entire x86 mini-PC host class (CPU class, hardware-decode figure, no cited source); the derived PCIe 3.0 x4 figure (4 × the x1 rate, no vendor page); USB "sustained" practical throughput factors versus signalling rate; the 256 KB per-frame interface overhead.

What invalidates a host-budget result

• A different mini-PC. The x86 host is a generic 4-core class with no vendor datasheet; a specific SKU's CPU, iGPU decode ceiling or M.2 slot generation can differ materially from the modelled row.
• An uncertified PCIe link. Raspberry Pi 5 at PCIe 3.0 x1 needs a device-tree override and is, in the Pi 5 documentation's own words, not certified — expect instability the engine does not model.
• A different card or firmware. The per-frame timings are corpus measurements for a Hailo-8 / Coral USB3 pairing at the tested detection sizes; a Hailo-10H, a different SDK version, or a different pipeline (e.g. a different NMS implementation) can move the frame_ms figure.
• Shared-bus contention. The host CPU budget and the interface budget are modelled independently; simultaneous decode, other camera streams, or other processes on the same host reduce both below the modelled ceiling.
• Non-default preprocessing path. The preprocessing input (hw/cpu) does not change the host-budget preprocessing rate in this version; it only affects the class-E heuristic used for platforms without a host budget.

10. Primary bottleneck and headroom ladder

The primary bottleneck is the constraint with the highest bottleneck score. A failing stage always outranks a near-limit stage, and a well-evidenced stage outranks a heuristic one at equal utilization.

The headroom ladder re-runs the decode, inference, memory and network stages for 1, 2, 3 … cameras (up to 64) and takes the maximum utilization at each count. Comfortable is the largest count at or under 60 % utilization, likely viable the largest at or under 85 %, and fails at the first count that reaches 100 %. Encode and preprocessing are excluded from the ladder because one is conditional and the other is a heuristic.

11. Evidence classes and the confidence rule

Every available figure carries one of five evidence classes. Class A and class E are never rendered with the same visual weight.

The confidence label per stage follows one rule in three steps:

For the decode stage the rule is applied to the underlying class A table: an exact published point is HIGH; a pixel-rate point inside the published range counts as interpolation distance 0.5 and lands at MEDIUM; a point beyond the largest published per-stream rate is treated as extrapolated and lands at LOW. Any row from a module NVIDIA marks preliminary (Thor T4000) is forced to LOW regardless. The overall label is the weakest stage.

12. Data tables and sources

The decode dataset contains only rows copied verbatim from NVIDIA datasheets, one source record per row with document id, revision, table, retrieval date and a short quote. Rows NVIDIA does not publish are absent; the engine never fills a gap. Static per-module, per-codec tables with the full rows are at /decode/. Dataset version 2026-09-07.

Documents

Modules in the dataset (H.265 / H.264 / AV1 at 1080p30, module totals)

Thor counts are module totals (two NVDEC instances on T5000, one on T4000). VP9 rows exist for every module and are used when requested. The T4000 AV1 MAXN row is printed inconsistently in the datasheet (a 1080p30 count lower than twice the 1080p60 count); it is kept verbatim and flagged on any result that uses it.

Other tables the engine reads

• Platform catalog for installed memory per module (vendor specification).
• Inference benchmark library and the multi-stream efficiency and power-mode multiplier tables from the Stream Calculator research series (P170 to P176).
• Memory Estimator part sizes: per-stream decode buffers, tracker memory, OS baseline.
• Camera bitrate table (resolution × codec × frame rate) shared with the Network Bandwidth and Storage Endurance engines.
• Host budget registry (hosts, interfaces, per-frame corpus timings) for Hailo, Coral and RK3588 platforms — full tables and sources in §9.

Those tables are described on the site-wide methodology page.

13. What invalidates a result

• A new datasheet revision. Every result URL carries mv (method version) and dv (dataset version). When either differs from the current values the result page says the data has changed since the link was made.
• A codec profile the row does not cover. The counts are for 8-bit 4:2:0 main profiles. High-bit-depth 4:2:2, 4:4:4, or exotic profiles are outside the published row; the engine halves for 4:4:4 and otherwise reports what it assumed.
• Software stream limits. Datasheet counts are hardware limits. JetPack, DeepStream, GStreamer or Frigate may cap the number of concurrent decoder sessions below them; the engine does not model these caps in version 1.0.
• Contention. Simultaneous decode and encode on one module share memory bandwidth; the datasheet tables are measured for each in isolation. Expect real totals to land below the sum of the two rows.
• Inference inputs. A different runtime, TensorRT version, batch size or detection resolution than the benchmark row changes the inference figure; the assumptions list states exactly what was used.
• Preliminary rows. Anything from Jetson Thor T4000 is LOW confidence until NVIDIA finalises the datasheet.
• Non-Jetson platforms. The modelled ceilings are planning figures only.
• Host-side budget (Hailo, Coral, RK3588). A different mini-PC, an uncertified PCIe link, a different card firmware, or bus contention can move the host CPU, interface or preprocessing figures — see §9 for the full list.

14. Method changelog

Method changes bump the method version; datasheet or benchmark updates bump the dataset version. Both appear in the citation block under every result and in the provenance object of every API response.