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.

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 engine sizes on the slow end (ms_max) and reports the fast end beside it as the best case. The load is required detections/s = cameras × detect fps × motion share, and the camera ceiling is 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 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 Raspberry Pi 5 host decoding H.264 in software, a detector close to its 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 is flagged NEAR LIMIT and 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 is a starting point, not a complete config.yml: cameras, go2rtc, record 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.