Hardware Sizing - CPU, Memory, Storage
Size it before you buy it.
An undersized recorder does not fail loudly. Its decoders fall behind, the watchdog reads the lag as a stalled camera, and recordings quietly develop gaps. Work out what you need first. Everything on this page is an estimate until you run the 60 second check on the real machine and paste the result in, and the page says which it is.
Cameras
?
Each location gets its own recorder, because cameras are recorded where
they are. Enter the streams the recorder will decode for motion: a camera
with a usable sub stream is analysed on that, not on its main stream.
Recording
?
Mbps left blank is estimated from resolution and frame rate at
0.1124 bits per pixel, which is
what the reference fleet's H.265 cameras produce. H.264 usually runs 1.5x
to 2x higher, so type yours in if you know it.
Hardware
?
A core count without a clock is not an answer. The work is quoted in
GHz-cores and then divided by the clock you plan to buy, so a 2.0 GHz
server part and a 4.5 GHz desktop part give different core counts for the
same fleet. Sustained all-core clock, not the peak on the box.
Advanced: the CPU you would buy 3 GHz, with SMT
AI
?
Field estimate for a typical scene: about
0.09 of a modern core per AI camera on
average, because detection only runs while something moves.
What can a machine you already own run?
Describe a machine below.
The calculator above sizes a machine for a fleet. This part tells you what a
machine you already own can carry, and this banner compares the two.
?
Hyperthreading means each performance core runs two threads; for a
VM, tick it when the host has it. A blank efficiency clock is read as
0.75x the performance
clock. A hypervisor hands out host threads, not cores, so on a
hyperthreaded host 10 vCPU is five physical cores with both threads
busy. Reading 10 vCPU as 10 cores is how our own reference machine
came to be described as bigger than it is. On a host without
hyperthreading, untick the hyperthreading box and each vCPU counts as a core.
Advanced: describe a card by hand
?
Leave the measured figure blank unless you have actually run the probe.
A blank one means the card counts for nothing, which is the honest
answer: inside a hypervisor a listed adapter is usually unreachable,
and our own reference machine is exactly that shape.
Planned throughput
432 Mpx/s
Effective CPU
36.0 GHz-cores
Memory allows
24 cameras
4 GB base plus 0.5 GB a camera
Cameras like the ones above: 8 cameras averaging 18.4 Mpx/s each.
?
A planning figure: it leaves
20% of the
model's ceiling spare on purpose, which on the recorders we measured in the
field is about 70% of
the real processor or less. Past about
90% the recorder
analyses its busiest cameras at a lower resolution; recording is never cut.
Recording only is a stream copy, so it usually runs out of memory first.
| With | Cameras that fit | Limited by |
|---|---|---|
| AI on every camera | 18 cameras (18 AI) | cpu |
| AI on 50% of cameras | 20 cameras (10 AI) | cpu |
| Motion only | 22 cameras | cpu |
| Recording only | 24 cameras | memory |
What a graphics card actually changes
?
Three separate things, capped separately, because they fail separately. A card
can decode and be unable to run a detector. A card can be listed in Device
Manager and do neither. The only one that raises the throughput number is the
first, and only as far as a benchmark measured it or, for a card picked from the list, as far as its specs suggest after the same correction for real camera streams, labelled as an estimate.
1. Decode offload
No credit
2. Inference
yolox-s on the CPU
3. Card memory gate
No card
Replace the estimate with measurements
60 seconds
?
Everything above is arithmetic on numbers you typed. The probe measures the
machine instead: it counts physical cores and reads the clock, generates a
2560x1440 clip, decodes it in software and once per advertised hardware
decoder, times each, and checks the pictures match the software decoder's. On
this project's own development box it caught Quick Sync producing different
pictures, which a feature list reported as "supported".
pwsh verify-install.ps1 -HardwareOnly -Json
Nothing measured yet. Everything on this page is an estimate.
Nothing is uploaded. The JSON is parsed in your browser and thrown away when you close the tab.
Common Fleet Sizes
Starting points at 4 MP and 4 fps.
Rendered from the same formulas the calculator uses, for one recorder. 14 day
retention, bitrate derived from resolution and frame rate, a typical scene, cores
quoted at 3.0 GHz with
hyperthreading and no GPU.
| Cameras | Decode demand | Cores, motion only | Cores, AI on every camera | Memory | Storage, 14 days |
|---|---|---|---|---|---|
| 4 | 59 Mpx/s | 2 | 3 | 8 GB | 1.0 TB |
| 8 | 118 Mpx/s | 4 | 4 | 8 GB | 2.0 TB |
| 16 | 236 Mpx/s | 6 | 8 | 16 GB | 4.0 TB |
| 24 | 354 Mpx/s | 9 | 11 | 16 GB | 6.0 TB |
| 32 | 472 Mpx/s | 11 | 14 | 32 GB | 8.0 TB |
| 48 | 708 Mpx/s | 17 | 21 | 32 GB | 12.0 TB |
| 64 | 944 Mpx/s | 22 | 28 | 64 GB | 16.0 TB |
Every column is an estimate. The AI column adds the field figure of
0.09 of a modern core per camera for a typical
scene, and every recorder carries 1.5
GHz-cores of Windows and services. The core counts move with the clock you enter above.
Calibration
Calibrated on 3 measured machines.
Not a market survey. This is the complete list of machines the probe has measured
for this model, and it is short. A handful of points tell you what does not fit.
They do not draw a curve.
| Machine | CPU as modelled | GHz-cores | Card | Measured | What it pins down |
|---|---|---|---|---|---|
| The .14 reference fleet Proxmox guest, no GPU passthrough, 2026-09-20 |
5 performance cores at 3.7 GHz with hyperthreading (assumed) | 23.1 | none | 32 cameras, 735 Mpx/s, saturated | The upper bound on Mpx/s per GHz-core. 735 / 23.1 effective GHz-cores = 31.8, and that is a figure the machine cannot actually hold. The planning budget is set at under half of it. |
| Development workstation bare metal Windows, 2026-09-20 |
8 performance cores at 2.9 GHz with hyperthreading | 29.0 | GeForce GT 1030 (plus an Intel UHD 630 iGPU), 2 GB | best correct decoder 459 Mpx/s | The two inference costs, the 4 GB VRAM gate (a real NVIDIA card with a working video engine and 2 GB cannot run the accurate model), and the fact that a hardware decoder can be both slower than software on one stream and produce different pictures. |
| GPU desktop, Dell Precision 3650 bare metal Windows 11, LookoutNVR installed, 2026-10-03 |
8 performance cores at 3.6 GHz with hyperthreading (assumed) | 36.0 | GeForce RTX 5060 Ti 16 GB, 16 GB | best correct decoder 1834 Mpx/s | The gap between the probe's synthetic clip and real camera streams: 3595 Mpx/s of software decode here against 66 to 91 Mpx/s per core on production recorders, which is why probe decode rates are multiplied by 0.25 before they are credited. Also the first card in the table that clears the VRAM gate with a measured decoder. |
Add one. Run
pwsh verify-install.ps1 -HardwareOnly -Json
on a machine that is actually recording and send us the JSON. The number most in need
of a second opinion is 15 Mpx/s per
GHz-core, and every honest datapoint tightens it.
Measured in the Field
Two production recorders, read off while they ran.
Field observations, not probe runs: 30 seconds of process CPU on recorders doing
their real job. They set the AI cost per camera, the fixed load of Windows and
services, and the correction applied to the probe's decode figures. Neither box
has a GPU.
| Site | Cameras | Decode | Recording | AI | Whole box | Model says |
|---|---|---|---|---|---|---|
| Analog upgrade VM, 3 vCPU on a Xeon E-2324G (Dell R250), no hyperthreading on the host, no GPU, 2026-10-03 |
32, 33.6 Mpx/s main | all 32 motion feeds on 0.33 vCPU, about 91 Mpx/s a core | 32 cameras on 0.05 vCPU | 5 cameras, recorder 0.69 vCPU | 48% | 55% |
| Mixed site VM, 20 vCPU on a Xeon E5-2690 v3 (2014), hyperthreaded host, no GPU, 2026-10-03 |
71, 1,155 Mpx/s main | 225 Mpx/s of full-resolution feeds on 5.45 vCPU, about 66 Mpx/s a core | 71 cameras on 0.6 vCPU | 20 cameras, recorder 1.8 vCPU plus 1.6 vCPU of picture grabs | 52% | 67% |
The model reads both boxes as busier than they are, which is the side to be wrong on.
At the Mixed site only 225
of 1,155 Mpx/s is decoded,
because cameras with a sub stream are analysed on it: enter the streams the recorder
decodes, not every main stream, or the answer will be about five times too big. Per AI
camera the two sites work out to roughly 0.05 to 0.1 of
a modern core including picture grabs; the calculator uses
0.05 for a quiet scene,
0.09 for a typical one and
0.16 for a busy one. These are estimates.
Deployment Shapes
Four ways people run this, and what each costs you.
Bare metal, with a GPU
The straightforward option. Hardware decode works, GPU inference works, the
higher accuracy detector is affordable and crops can come from the full
resolution frame. Most cameras per pound spent.
Recommended
Bare metal, no GPU
Fine up to roughly 8 cores of demand. Past
that you are buying CPU to do a job silicon already on a graphics card does for
less. Detection runs yolox-s at a 640px feed, measured at
124 ms a frame.
Small fleets
VM, no passthrough
The common trap, and the shape of our own reference system. The host has an
iGPU, the guest cannot use it, and every frame is decoded on the CPU. Size this
as CPU only, and enter the vCPU count as vCPU rather than as cores.
Size as CPU only
VM, with passthrough
Gets you back to the GPU numbers, at the cost of a fiddly setup: IOMMU on, the
host must not claim the card, and some cards need a reset quirk after a guest
reboot. Worth it on a machine that already exists. Not worth building for.
Advanced
Assumptions
Where these numbers come from.
Calibrated on 3 measured machines. That is enough to tell you what will not fit.
It is not enough to promise you what will.
The reference measurement
A Proxmox VM with 10 vCPU of an i5-12600K,
19.6 GB of RAM and no GPU passthrough, running
32 cameras at 4 to 10 fps, mostly 2688x1520 up to
3840x2160. Total decode demand 735 Mpx/s,
82.6 Mbps configured. It runs at 100% CPU, its decoders
fall behind, and it drops recordings. Measured 2026-09-20.
15 Mpx/s per GHz-core
That budget covers the whole pipeline: decode, motion, the AI feed and writing
segments. It is not a raw decode figure, which is several times higher. Those
10 vCPU are 5 physical cores at
3.7 GHz with both threads busy, which is
23.1
GHz-cores. It carries 735 Mpx/s
on that and is over its limit, so the sustainable figure is below
31.8.
We budget 15, a shade under
half. Provisional: it describes today's pipeline and has to be
re-derived once the AI feed's JPEG round trip is gone.
A hyperthread is worth 25% of a core
Assumption, from Intel's published 15-30% hyper-threading gain on throughput
work; video decode is cache-heavy and sits at the low end. Efficiency cores get
65% of a performance core at the same clock, which is where
Gracemont-class cores land per clock, and they have no SMT so they take no
hyperthread bonus. Counting logical processors as cores, which this page used
to do, overstates a hyperthreaded machine by about 60%.
A GPU is three things, not a multiplier
Decode offload is capped at
4x and credited only up
to what a benchmark measured. Inference is a model choice: on CPU at a 640 input
we measured yolox-s at 124 ms a
frame and rt-detrv2-s at 462 ms,
so the accurate model is a card feature. The card memory gate is
4 GB: the probe found a real
NVIDIA card with a working video engine and 2 GB, which decodes and cannot
infer. A card the machine merely lists earns nothing at all. A card picked from the list earns an estimate scaled from the one we measured, an RTX 5060 Ti, and says so.
4 GB plus 0.5 GB a camera
Base covers Windows, the service, SQLite and the loaded model. Per camera
covers the decoder context, ring buffers and frame stores. For the reference
fleet that predicts 20 GB; the machine has 19.6 GB and
does not swap.
10.8 GB per Mbps per day
Not an estimate, just arithmetic: one Mbps for 86400 seconds is 10.8 decimal GB.
The reference fleet's 82.6 Mbps therefore works out at
892 GB a day configured, against 700 GB a day
actually written, because VBR cameras rarely sit at their cap. We size on the
configured figure, because a full disk is the worse mistake.
Planned to 80% load
A recorder at 100% CPU is exactly where the reference box sits while it loses
footage. The last 20%
of the model's ceiling is there for a reconnect storm, an overnight infrared
noise spike, a retune, and Windows Update. On the two field recorders that line
lands at about 70% of
the real processor or below, which is where we would size a box by hand.
AI is paid for per camera, while things move
Every motion makes an event; detection refines it, and only runs while
something moves. So an AI camera costs a duty-cycle average, not a detector on
every frame: 0.05,
0.09 or
0.16 of a modern core for a quiet, typical or
busy scene, from two production recorders. A typical camera's share is the CPU
of one yolox-s detection every
5.3
seconds.
What this page will not do. It will not tell you a 10 vCPU CPU-only
box runs 32 cameras at 5 MP, because we have measured that exact machine and it does
not. If your inputs produce that answer the banner turns red. It will not credit a
graphics card a machine merely lists, however expensive the card is, and it labels every
card it has not measured as estimated from specs. Sizing that
flatters the buyer is how recorders end up with gaps.
Questions
What people ask before they buy a recorder.
Every number below is worked out by the same model as the calculator above, so it
changes when the model does.
How many cameras can a server with no GPU run?
It depends on the processor's clock and core count as much as on the cameras. As a worked example, an 8 core 3.6 GHz processor with hyperthreading and 32 GB of memory runs about 21 cameras at 4 MP and 4 fps with AI object detection on every camera, or about 27 with motion detection only, planned to 80% of the model's ceiling. Enter your own processor and cameras in the calculator for your answer.
Does recording need a GPU?
No. Recording copies each camera's stream to disk without decoding it. On production recorders we measured 71 cameras recording on 0.6 vCPU and 32 cameras on 0.05 vCPU. A graphics card only helps with decoding video for motion detection and with running object detection.
How much storage do 32 cameras need for 30 days?
About 21 TB for 32 cameras at 4 MP and 5 fps on H.265, sized on the configured bitrate of about 66 Mbps; in practice variable bitrate cameras write closer to 17 TB. Our 32 camera reference fleet, mostly 5 MP at 82.6 Mbps, writes about 700 GB a day, about 21 TB in 30 days. H.264 cameras need roughly 1.5 to 2 times as much.
How much CPU does AI object detection add per camera?
Detection only runs while something moves, so an AI camera costs an average, not a detector on every frame. On two production recorders that average was about 0.09 of a modern processor core per camera, including picture grabs. The calculator uses 0.05 for quiet scenes and 0.16 for busy ones such as roads and car parks.
Do I need a separate recorder at each location?
Yes. Each location gets its own recorder, because cameras are recorded where they are: sending every stream to one building costs bandwidth and makes one box a single point of failure. The calculator sizes each location separately and adds them up.
Does hyperthreading count as extra cores?
Not as whole ones. A second thread on a busy core is worth about 25% of a core for video work, so 8 cores with hyperthreading are worth about 10 cores, not 16. A virtual machine's vCPUs on a hyperthreaded host count the same way.
Know what it needs.
Then run it.
Then run it.
LookoutNVR is free to download and has no camera limit. Check the box first with the
bundled probe, then install.