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. Camera link budget (IP, MIPI CSI-2, USB, GMSL2)
11. Primary bottleneck and headroom ladder
12. Evidence classes and the confidence rule
13. Data tables and sources
14. What invalidates a result
15. 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, stream-capacity landmarks from an integer pipeline sweep (comfortable, maximum modeled fit, first failing count) and per-stage source confidence.

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.

Inputs (WP-01). A field that is not stated takes its documented default and is listed in provenance.defaulted; a field that is stated but invalid — a count of 0, a negative, a fraction or a non-number, true in place of a count, an unknown value of an enumerated input, or an empty string — is rejected with VALIDATION_ERROR naming the field, never replaced by a default.

Input keys (WP-02). The engine accepts one list of input keys — the inputs documented here and their declared backward-compatible aliases. Unknown input keys are rejected with VALIDATION_ERROR naming the key: an invented or misspelt key is never silently ignored, a __ test hook never reaches the engine, and an alias sent together with the key it stands for is rejected too (the engine would read only one of them). export_json.inputs echoes every input the engine honoured, so replaying it reproduces the result.

Detection above the source rate. A stated detection_fps above source_fps is capped to the source frame rate and the cap is disclosed: an assumption names both figures and requested_workload.detection_fps_cap carries the requested and applied rates. Detection cannot run on more frames than the camera delivers.

2. Constraint objects and status thresholds

Every stage returns the same shape. Utilization is required over available, rounded to four decimals. 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.

A stage over its limit is a FAIL only when its evidence can prove the miss (elimination authority): decode and encode against a vendor pixel rate, a measured inference figure or one scaled down for a larger input, memory whose weights alone exceed the module. A stage over its limit on planning-only evidence — inference through the multi-stream efficiency curve or a power-mode factor, the host CPU and preprocessing budgets, a modelled decode ceiling with no source record, the estimated camera bitrates behind the network stage, the memory overhead estimate — is REQUIRES_VALIDATION with the modelled shortfall stated, and the result reads INSUFFICIENT EVIDENCE (NEEDS VALIDATION), never NO FIT. VERSION_RISK is not emitted.

3. Decode stage

Decode starts from the vendor's published codec capacity. 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. Exact published operating points keep class A with the vendor source attached; unpublished profiles are modelled (class D) against the published throughput.

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-capacity 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-capacity research series; tracking overhead is listed as an assumption and not yet deducted.

Power mode. The inference is computed at the preset the result prints in resolved_configuration.power_mode: the one requested, else the module's registry default — the same mode Hardware Match plans at, so this engine called directly and through Hardware Match gives one figure for one configuration. A requested mode is a ceiling: the highest supported preset at or below it is used and the substitution is published in resolved_configuration.power_mode_request; when every preset draws more than the ceiling, a power_mode_ceiling row FAILs and the verdict is NO FIT. A value that names no preset, no wattage and not MAXN is a validation error. The calibration factor is relative to the mode the benchmark row was measured at, so more allowed power never lowers the modelled throughput of the same row.

Task and detection size. The benchmark row's task is compared with the workload's task (default detection), so a classifier row answering a classification workload is not a cross-task transform; a task with no model named uses that task's default model. With no precision named, the inference is computed at the task’s planning default — FP16 for segmentation and pose (the task stated, else the task the model registry files the named model under), INT8 for every other task — listed in defaulted and marked on requested_workload.precision_default as a DERIVED planning default (method 1.5.0). On a platform that runs only INT8 (Coral, Hailo) the FP16 task default falls back to INT8, the platform’s supported precision, and the record says why. With no detection_resolution the model's native input size is used (the model registry's, else the size its benchmark rows were measured at) and nothing is scaled. When a size is given and no row was measured at it, a detection, segmentation or pose network's figure for a larger size is scaled down by the pixel ratio, and for a smaller size keeps the measured figure — a smaller input is not credited with more throughput than was measured (fixed per-frame costs). The step publishes the pixel_ratio and the applied_ratio, and the assumption states which (class D); transformer models and classifiers are not scaled, so the inference is UNKNOWN with the reason.

Platform scaling. When the platform has no row for the model, the figure is anchored on the same model's rows on other platforms of the same family, ordered by the catalog capability figure (TOPS): between the nearest weaker and the nearest stronger anchor it is interpolated in log-fps over log-TOPS, and outside the anchored range it is scaled from the nearest anchor by the square root of the TOPS ratio. A stronger platform is therefore never given a lower scaled figure than a weaker platform's anchor, which the metamorphic suite checks for every model and precision whose measured anchors are themselves in capability order. The figure is class D and a modeled_estimate: it is planning evidence and cannot eliminate a platform. A catalog row that is itself derived — one task's measured figure multiplied by a published overhead ratio, as the segmentation and pose rows for some modules are — is a cross-task transform: class D, modeled_estimate, with a cross_task_ratio step in the transform chain, never a measured benchmark.

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.

Model-side parts match Model Memory Fit and Model Match (the same vision_memory module). The stage is class D with MEDIUM confidence: published splits are class C where measured, but your runtime, plugins and container overhead can still 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 (Raspberry Pi 5 + Hailo-8 / Coral USB3, 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; 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.

9A. Camera link budget (IP, MIPI CSI-2, USB, GMSL2)

Since dataset 2026-09-08 the engine also budgets the link the cameras arrive on. The camera_interface input selects it (default ip); an optional carrier id from the production-carrier registry supplies the Ethernet ports, CSI connectors and lanes and USB ports of the board actually in the enclosure, and an optional sensor id sets the bit depth from the sensor's published output format.

The result is one interface constraint tagged stage: camera_link (distinct from the accelerator host link of §9). For ip nothing is added: the network stage's ingress is replaced in place by the carrier's or module's figure. When a camera count exceeds a hard limit the constraint is re-expressed on the camera axis — required = cameras, available = the limit — so utilization and status follow the normal thresholds, and the bandwidth figures move to detail.bandwidth. MIPI packet overhead is not subtracted from the published lane rate; the comparison is therefore optimistic by a few percent. Uncompressed UVC is not a stream codec of this engine; the module models it for the interface only.

Data: datasets/camera-interfaces.json — per-module CSI-2 lanes, camera counts and PHY rates from the NVIDIA Jetson Orin / Thor datasheets, the Raspberry Pi 5 documentation, the Rockchip RK3588 datasheet and the Coral Dev Board datasheet; USB and Ethernet rates from the same datasheets; GMSL2 6 Gbit/s and four inputs per deserializer from the Analog Devices MAX96724 datasheet; sensor output formats from Raspberry Pi, OmniVision and Arducam pages (Arducam is class C). Every figure carries its source record; a field the document does not state is null and the engine reports UNKNOWN rather than guessing.

10. Primary bottleneck and stream capacity sweep

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. The capacity ceiling at the first failing stream count is separate: it is the highest-utilisation FAIL among kernel-eligible constraints at that count, with any co-failures listed alongside.

Stream capacity landmarks come from an integer sweep that re-evaluates the complete pipeline at each stream count 1 … 64 until the first required miss (or the sweep cap) — a FAIL, or an overload demoted to REQUIRES_VALIDATION because its evidence cannot eliminate: the ceiling is where the model runs out, a landmark, not an elimination. 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. Maximum confirmed fit requires no FAIL and no required INDETERMINATE. Validation-limited from is the first count at or below the modeled maximum where a required INDETERMINATE appears, when applicable.

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-capacity research series.
• Memory-budget registry 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.