The building manager is positive: "the camera caught him clean". You open the recording and sure enough, there he is: a guy walking out the gate with a bike over his shoulder, in broad daylight. You zoom into the face and the face is a twelve-pixel smudge under a baseball cap. You can see him, but you can't recognize him — CCTV's most expensive sentence, because it's almost always spoken after the theft, when there's nothing left to zoom. The good news: whether a camera can identify someone is not luck, and it's not marketing. It's a division. And you can do it before you buy.
DORI: putting numbers on "looks sharp"
The EN 62676-4 standard put numbers on sharpness with the DORI criteria: four levels of visual task, each with a minimum pixel density on the target, measured in pixels per meter (px/m). It's not how many megapixels the camera has — it's how many pixels land on each meter of scene in the plane where your subject is standing.
| Level | px/m | What it buys you | Max with 1080p and 90° FOV |
|---|---|---|---|
| Detect | 25 | knowing someone or something is there | 38.4 m |
| Observe | 63 | clothing, direction, what they're doing | 15.2 m |
| Recognize | 125 | confirming someone you already know | 7.7 m |
| Identify | 250 | singling out a stranger, with evidence-grade quality | 3.8 m |
Mind the gap between recognize and identify: recognize works for someone you already know ("that's the night guard from next door"); identify means singling out a stranger with enough quality to hand to the police. Between one and the other sits exactly a factor of two in pixels — and as you're about to see, doubling pixels gets expensive in distance.
From the camera to px/m: one division
The mother formula is this: px/m = horizontal resolution ÷ scene width. A 1080p camera has 1920 horizontal pixels. If its frame covers a plane 7.68 m wide, every meter gets 1920 ÷ 7.68 = 250 px/m: full identification across that entire plane. Point the same sensor at a 40 m parking lot and each meter gets 48 px/m: you'll detect shapes, and that's the end of the story.
So what sets the scene width? Distance and lens. A lens with horizontal field of view (FOV) θ opens, at distance d, a scene 2 · d · tan(θ/2) meters wide. Combine both: px/m = res ÷ (2 · d · tan(θ/2)). Solve it for a 90° FOV — tan 45° = 1, how considerate — on a 1080p camera: you identify out to 1920 ÷ 500 = 3.84 m. Less than four meters from the lens. Beyond that the whole hallway "looks fine": you recognize out to 7.7 m, observe to 15.2, detect to 38.4… but none of that will single out a stranger.
Double the resolution? A 4K camera (3840 px) with the same 90° FOV pushes the identification border from 3.84 to 7.68 m. Exactly double — no miracle — and it charges you double in bitrate and disk, as you'll see below. Before wrestling the trigonometry, the lens & FOV calculator runs this math with your camera's actual sensor and focal length, and draws all four zones on the plan.
Fixed lens, varifocal, and the wide-angle toll
The fixed lens (2.8 or 4 mm on most domes) is cheap and never drifts, but its framing is married at the factory: if the scene doesn't fit, the camera is wrong forever. The varifocal (typically 2.8–12 mm) lets you adjust the framing on site — and the motorized version, from your desk. It costs more, but when you can't measure the scene before quoting, it's insurance against a second site visit.
CCTV's central trade-off lives right here: a wide-angle lens spreads the same 1920 pixels over a huge scene. Lots of coverage, little density. There's an elegant way to see it: with 1080p, identification always happens where the scene is 7.68 m wide — the lens merely decides how far away that plane sits. With 2.8 mm (≈ 90°), it's 3.8 m from the camera. With a ≈ 10 mm telephoto (30° FOV), it's 14.3 m: the same scene, almost four times farther out, in exchange for seeing one narrow corridor and nothing else.
Storage: bitrate × time, no magic
NVR storage holds no mystery: it's total bitrate × retention time, with a ÷ 8 along the way because bits travel eight to a byte. Let's run the canonical project — 8 cameras at 1080p, H.264 at 4 Mbps, 30-day retention — with every decimal in plain sight:
- Aggregate bitrate: 8 cameras × 4 Mbps = 32 Mbps arriving at the NVR, day and night.
- Bits to bytes: 32 ÷ 8 = 4 MB/s of sustained disk writes.
- A day has 86,400 seconds: 4 × 86,400 = 345,600 MB = 345.6 GB/day (43.2 GB per camera).
- 30 days of retention: 345.6 × 30 = 10,368 GB ≈ 10.37 TB — in decimal units, the same ones disks are sold in, so the comparison is apples to apples.
- With H.265? The same period drops to ≈ 5.18 TB: the codec delivers similar quality at roughly half the bitrate. Turn on VBR with motion-based recording and the real average falls further still — a parking lot at 4 AM produces far fewer bits than a supermarket checkout at noon.
Better yet, the arithmetic audits itself in production: one day of one camera at 4 Mbps weighs exactly what the formula says it should.
$ du -sh /nvr/gate-cam/2026-07-09/
43.2G /nvr/gate-cam/2026-07-09/
# 4 Mbps × 86,400 s ÷ 8 = 43.2 GB — the formula doesn't miss Add 10–20 % of headroom on top: VBR bitrates spike, disks shouldn't run at 100 % full, and the day of the incident always has more motion than the average day. The CCTV storage calculator runs this cascade with resolution, FPS, codec and activity factor; and if your project mixes profiles — four domes, two telephotos, one PTZ — the CCTV project calculator adds up the whole mix at once.
The VMS server: the part nobody sizes
Everyone quotes cameras; almost nobody sizes the machine that records them. A VMS server has three bottlenecks, and none of them is the CPU.
The first is recording bandwidth: how many sustained Mbps the software can write without dropping frames. A typical mid-range server is specced around 300 Mbps — at 4 Mbps per camera that's 75 cameras; our 32 Mbps project has room to spare, but a casino with 120 4K cameras already needs more than one server. The second is RAM: recording is light, what's heavy is analytics and transcoding streams for the video wall; vendors usually ask for 8 GB as a floor and 16 or more with analytics running. The third — the one everybody forgets — is the disks.
CCTV writing is continuous, sequential and eternal: 24/7, 365 days a year. Our "small" example writes 126 TB per year — 63 TB per disk on a mirrored pair. A typical desktop drive is rated for about 55 TB/year of workload and office hours; you'd be running it above its rating from day one. Surveillance drives ("purple", SkyHawk and friends) are rated for 180 TB/year, 24/7 duty and firmware built for streams: they fail less and fail later. The VMS server calculator crosses cameras, bitrate, retention and per-server limits to tell you how many machines and which disks you need.
PoE: your cameras eat lunch too
Every IP camera eats watts through the same data cable, and the switch has a finite budget. A fixed dome draws 4–7 W: 802.3af covers it easily (up to 12.95 W delivered to the device). But long-range IR, PTZ motors or the heater on an outdoor housing change the league: PoE+ (802.3at, 25.5 W) or even 802.3bt for the hungriest. Our 8 cameras at ~6 W add up to 48 W — and an 8-port PoE switch with a 60 W budget is left with 12 W free: the PTZ somebody will request next year no longer fits. Run the sum through the PoE budget calculator before quoting the switch, and if classes, watts and voltage drop still ambush you, the PoE Without Surprises guide takes it all apart.
The recipe fits on a napkin: define the DORI level for each spot, pick the lens with the calculator, multiply bitrate by time before quoting disks, and check that the server and the switch can carry the load. Run the full project through the CCTV project calculator and walk into the meeting with numbers — let "you can see him, but you can't recognize him" be the other guy's install.