Frigate Hardware & Detector Fit — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. Frigate's sizing rule
4. The checks
5. Verdict rule
6. Platform → detector table
7. Decode presets and the config snippet
8. Alternatives and remediation
9. Evidence classes and confidence
10. What invalidates a result
11. Method changelog

1. What it decides, and what it does not

The engine answers one procurement question: for this platform, this many cameras, this detect substream and this detect frame rate, does Frigate fit? It returns FIT, FIT WITH RISKS, NEEDS VALIDATION or NO FIT, together with the Frigate detector the platform runs, the image tag it needs, the detections per second the deployment demands against the detections per second the detector delivers, the camera ceiling, the decode budget, the ffmpeg hardware-acceleration preset and a config snippet.

It does not predict Frigate's frame rate, its recording throughput, its CPU load in your ffmpeg configuration, or the accuracy of a model on your scene. It does not model the go2rtc restream, birdseye, semantic search or the review pipeline. Detection load in the real world follows motion, not camera count; the engine sizes the worst case by default and lets you scale it with a motion share.

2. Inputs

The detect substream is the only stream the engine decodes. Frigate's recommended architecture records the high-resolution stream as a passthrough copy — no decode, no encode — and detects on a small substream, which is why detect resolution and detect fps, not the record stream, drive the budget. Frigate's recording documentation says so directly: “These recordings are written directly from your camera stream without re-encoding.” Choosing re-encode changes that: every camera's stream is encoded again, continuously, and the engine adds that load as the encode check (section 4). The record stream is sized at the camera stream the engine already models (cameras × detect resolution × source fps); a higher-resolution main stream costs proportionally more.

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 detect_fps above source_fps is capped to the source frame rate and the cap is disclosed: the decode and preprocessing stages composed from Camera Stream Capacity run at the source rate, an assumption names both figures and workload.detect_fps_cap carries them; the detector demand keeps the stated rate.

3. Frigate's sizing rule

The capacity rule is not ours. Frigate's recommended-hardware page states it directly:

“You can calculate the maximum performance of your Coral based on the inference speed reported by Frigate.”
“With an inference speed of 10, your Coral will top out at 1000/10=100, or 100 frames per second.” Frigate · Recommended hardware · docs.frigate.video/frigate/hardware

So available detections/s = 1000 / inference ms. Where Frigate publishes a band rather than a single figure — 20–40 ms for every Jetson module — the inference row's available uses the band midpoint (33.3 det/s for 20–40 ms) for PASS / NEAR LIMIT / FAIL utilisation; the slow edge (25 det/s) and fast edge (50 det/s) are published in the row detail, and the band itself still reads REQUIRES VALIDATION until a platform measurement replaces it. The load is required detections/s = cameras × detect fps × motion share, and the camera ceiling uses the midpoint capacity: floor(available / (detect fps × motion share)).

The detect frame rate default is also Frigate's:

“Optional: desired fps for your camera for the input with the detect role (default: shown below). NOTE: Recommended value of 5.” Frigate · Full Reference Config · docs.frigate.video/configuration/reference

A motion share of 1 means every camera is detecting at the detect fps at the same instant. That is the number a deployment has to survive, so it is the default; 50 % or 30 % model a site whose cameras are mostly still.

4. The checks

The checks always open with detector, inference, decode and close with decode_preset; the encode check follows decode only when the record stream is re-encoded, and the host checks appear between them only when an accelerator sits on a host board.

5. Verdict rule

• NO FIT — any check FAILs. Most often the detector cannot hold the detections per second.
• NEEDS VALIDATION — no FAIL, but a check is UNKNOWN or needs validation: the platform has no decode datasheet on record (Intel N100), or the documented Frigate image does not name this hardware generation (Jetson Thor).
• FIT WITH RISKS — no FAIL and nothing unknown, but a check is NEAR LIMIT (a detector close to its midpoint ceiling), or the platform is a Coral, which Frigate documents as “no longer recommended for new Frigate installations, except in deployments with particularly low power requirements.”
• FIT — every check passes.

The verdict never softens a FAIL and never hardens an UNKNOWN into a FAIL: a limit Frigate does not publish is reported as unknown, not guessed.

6. Platform → detector table

Every inference figure is a verbatim quote from a Frigate documentation page, at most 25 words, with the URL and retrieval date, in datasets/frigate-fit.json. Frigate publishes one band for every Jetson module and no figure for datacentre GPUs; the four server GPUs are mapped to the nearest published consumer row and marked class D so a reader can see the substitution rather than inherit it silently. The registry also holds detector types the catalog has no platform for yet (cpu, memryx) and inference rows for hardware outside the catalog (RK3566, Intel Arc A750, Intel NPU, AMD 780M, GTX 1070, MemryX MX3).

7. Decode presets and the config snippet

An accelerator card has no decoder of its own, so it inherits the preset of the host it sits on: a Hailo or Coral on a Raspberry Pi 5 gets the Pi preset, on a mini-PC the Intel presets. The Pi 5 has no H.264 hardware decoder, so an H.264 detect stream on that host falls back to software decode: the preset check passes when the host CPU and decode checks pass, the software decode is reported as a risk, and when they miss the preset check takes their outcome: FAIL only when a decode path fails on evidence that can prove it, REQUIRES VALIDATION when the miss rests on planning-only evidence. The host CPU budget is such an estimate (a software-decode cost per megapixel against a class E budget share), so on the Pi 5 an H.264 load over it is REQUIRES VALIDATION, not NO FIT. The CPU cost shows in the host CPU check — Frigate's Video Decoding page documents Raspberry Pi 3/4 presets and does not state the Pi 5 case, so the engine says so rather than inventing a preset. Frigate's own default is hwaccel_args “(default: auto detect)”.

The config snippet names the detector block, the device line where the detector needs one (edgetpu, openvino), the preset chosen for the codec, and the detect frame rate and size. It names a preset only when one decodes the stream codec on the resolved host; with software decode (Raspberry Pi 5 + H.264) it omits hwaccel_args and says so in a comment. The record output args follow the recording choice: passthrough records with preset-record-generic (the stream copied as-is, no audio); re-encode writes the same segment arguments with -c:v libx264 -preset veryfast — Frigate has no preset that re-encodes video, and it notes that browsers other than Chrome 108+, Edge and Safari “require recordings to be encoded with H264”. It is a starting point, not a complete config.yml: cameras, go2rtc, retention and object filters are yours.

8. Alternatives and remediation

Every result lists every mapped platform with its detector, published inference milliseconds, the cameras it holds at your detect fps and motion share, whether it holds this load, and its evidence class — sorted by camera ceiling, so the substitution is visible at a glance. A failing or near-limit check names the change that flips it: a lower detect fps, a smaller camera count on this node, a faster detector, or a lower-resolution detect substream when decode is the binding constraint. A detector that needs validation names the documented fallback.

The headroom ladder re-runs both the detector capacity and the decode budget across camera counts and reports where the node is comfortable, where it is likely viable, and where it fails.

9. Evidence classes and confidence

• A — Frigate's software documentation: detector types, supported hardware and models, image tags, the ffmpeg presets, the recommended detect fps, the capacity rule and the Coral status statement; and the vendor decode datasheets Camera Stream Capacity uses.
• C — the inference-speed rows the Frigate project publishes for each hardware family. These are measurements by the project, not by a vendor and not by EdgeAIStack.
• D — a server GPU mapped to the nearest published consumer GPU row, and modelled decode where Camera Stream Capacity has no datasheet row.
• E — an UNKNOWN decode or an undocumented preset: reported as unknown, never as a number.

Confidence: HIGH on the detector and preset checks (Frigate documentation); MEDIUM on a class C inference check; LOW on a class D mapping or any UNKNOWN. The overall confidence is the lowest of the checks.

10. What invalidates a result

• A different detection model from the one Frigate benchmarked — a larger YOLO variant runs slower than the published row, so the capacity falls with it.
• Re-encoding the record stream instead of passing it through: that is an encode budget this engine does not size.
• Running detection on the full-resolution stream rather than a substream — the decode check is sized on the detect stream you entered.
• A Jetson at a lower power mode: Frigate publishes one 20–40 ms band for every Jetson module with no per-module or per-power-mode figure, so a capped module sits at the slow end or below it.
• A motion share entered below what the site actually produces — detection load follows motion, and a busy scene runs at the worst case.
• Anything Frigate runs beyond detection: semantic search, face and licence-plate recognition, birdseye and the go2rtc restream all take resources this engine does not budget.
• Wi-Fi cameras, which Frigate's own hardware page advises against.

11. Method changelog

Method changes bump the method version; new or re-verified Frigate documentation bumps the dataset version. Both are in every result and in the citation block.