El conserje está seguro: «la cámara lo agarró clarito». Abres la grabación y sí, ahí está: un tipo cruzando el portón con una bici al hombro, a plena luz del día. Haces zoom a la cara y la cara es una nube de doce píxeles con gorra. Se ve, pero no se reconoce — la frase más cara del CCTV, porque casi siempre se pronuncia después del robo, cuando ya no hay nada que zoomear. La buena noticia: que una cámara identifique o no a alguien no es suerte ni marketing del fabricante. Es una división. Y se puede hacer antes de comprar.
DORI: ponerle números a "se ve bien"
La norma EN 62676-4 le puso números a la nitidez con el criterio DORI: cuatro niveles de tarea visual, cada uno con una densidad mínima de píxeles sobre el objetivo, medida en píxeles por metro (px/m). No es cuántos megapíxeles tiene la cámara: es cuántos píxeles le tocan a cada metro de escena en el plano donde está tu sujeto.
| Nivel | px/m | Qué te permite | Máx. con 1080p y FOV 90° |
|---|---|---|---|
| Detectar | 25 | saber que hay alguien o algo ahí | 38,4 m |
| Observar | 63 | ropa, dirección, qué está haciendo | 15,2 m |
| Reconocer | 125 | confirmar a alguien que ya conoces | 7,7 m |
| Identificar | 250 | individualizar a un desconocido, con valor de evidencia | 3,8 m |
Ojo con la diferencia entre reconocer e identificar: reconocer sirve para alguien que ya conoces («es el guardia nocturno del edificio de al lado»); identificar es individualizar a un desconocido con calidad suficiente para una denuncia. Entre uno y otro hay exactamente el doble de píxeles — y como vas a ver, el doble de píxeles se paga caro en distancia.
De la cámara a los px/m: una división
La cuenta madre es esta: px/m = resolución horizontal ÷ ancho de escena. Una cámara 1080p tiene 1920 píxeles horizontales. Si su encuadre cubre un plano de 7,68 m de ancho, cada metro recibe 1920 ÷ 7,68 = 250 px/m: identificación plena en todo ese plano. Si la misma cámara abarca una cancha de 40 m, tocan 48 px/m: detectas bultos, y hasta ahí llegamos.
¿Y qué define el ancho de escena? La distancia y el lente. Un lente con campo de visión (FOV) horizontal θ abre, a distancia d, una escena de 2 · d · tan(θ/2) metros. Combinando ambas: px/m = res ÷ (2 · d · tan(θ/2)). Despeja con un FOV de 90° — tan 45° = 1, qué amable — y una 1080p: identificas hasta 1920 ÷ 500 = 3,84 m. Menos de cuatro metros del lente. Más allá el pasillo entero "se ve": reconoces hasta 7,7 m, observas hasta 15,2, detectas hasta 38,4… pero nada de eso individualiza a un desconocido.
¿Duplicar resolución? Una cámara 4K (3840 px) con el mismo FOV 90° corre la frontera de identificación de 3,84 a 7,68 m. El doble exacto — no un milagro — y lo cobra en bitrate y disco, como verás más abajo. Antes de pelear con la trigonometría, la calculadora de lente y FOV hace esta cuenta con el sensor y la focal reales de tu cámara, y te dibuja las cuatro zonas en el plano.
Lente fijo, varifocal y el peaje del gran angular
El lente fijo (2,8 o 4 mm en la mayoría de los domos) es barato y no se desajusta, pero su encuadre queda casado de fábrica: si la escena no encaja, la cámara queda mal para siempre. El varifocal (típicamente 2,8–12 mm) te deja ajustar el encuadre en sitio — y la versión motorizada, desde el escritorio. Cuesta más, pero cuando no puedes medir la escena antes de cotizar, es un seguro contra la segunda visita a terreno.
El trade-off central del CCTV vive aquí: el gran angular reparte los mismos 1920 píxeles sobre una escena enorme. Mucho campo, poca densidad. Y hay una forma elegante de verlo: con 1080p, la identificación siempre ocurre donde la escena mide 7,68 m de ancho — el lente solo decide a qué distancia queda ese plano. Con 2,8 mm (≈ 90°), a 3,8 m de la cámara. Con un tele de ≈ 10 mm (FOV 30°), a 14,3 m: la misma escena, casi cuatro veces más lejos, a cambio de ver un pasillo angosto y nada más.
Storage: bitrate × tiempo, sin magia
El almacenamiento de un NVR no tiene misterio: es bitrate total × tiempo de retención, con un ÷ 8 en el camino porque los bits viajan de a ocho en cada byte. Hagamos el proyecto canónico — 8 cámaras 1080p en H.264 a 4 Mbps, retención de 30 días — con todos los decimales a la vista:
- Bitrate agregado: 8 cámaras × 4 Mbps = 32 Mbps llegando al NVR, día y noche.
- De bits a bytes: 32 ÷ 8 = 4 MB/s de escritura sostenida en disco.
- Un día tiene 86 400 segundos: 4 × 86 400 = 345 600 MB = 345,6 GB/día (43,2 GB por cámara).
- Retención de 30 días: 345,6 × 30 = 10 368 GB ≈ 10,37 TB — en unidades decimales, las mismas con que los discos se venden, así que la comparación es directa.
- ¿Con H.265? El mismo período baja a ≈ 5,18 TB: el códec entrega calidad similar con más o menos la mitad del bitrate. Y si activas VBR con grabación por movimiento, el promedio real cae aún más — un estacionamiento a las 4 AM genera muchos menos bits que una caja de supermercado a mediodía.
La aritmética además se deja auditar en producción: un día de una cámara a 4 Mbps pesa lo que la fórmula dice que pesa.
$ du -sh /nvr/cam-porton/2026-07-09/
43,2G /nvr/cam-porton/2026-07-09/
# 4 Mbps × 86 400 s ÷ 8 = 43,2 GB — la fórmula no falla Al total súmale un 10–20 % de margen: los bitrates VBR tienen picos, los discos no deben llenarse al 100 % y el día del incidente siempre hay más movimiento que el promedio. La calculadora de almacenamiento CCTV hace esta cascada con resolución, FPS, códec y factor de actividad; y si tu proyecto mezcla perfiles distintos — cuatro domos, dos teles, una PTZ —, la calculadora de proyecto CCTV suma todo el mix de una vez.
El servidor VMS: el que nadie dimensiona
Todos cotizan cámaras; casi nadie dimensiona la máquina que las graba. Un servidor VMS tiene tres cuellos de botella, y ninguno es el procesador.
El primero es el ancho de banda de grabación: cuántos Mbps sostenidos puede escribir el software sin soltar frames. Un servidor típico de gama media se especifica en torno a los 300 Mbps — a 4 Mbps por cámara son 75 cámaras; nuestro proyecto de 32 Mbps va holgado, pero un casino con 120 cámaras 4K ya necesita más de un servidor. El segundo es la RAM: grabar es liviano, lo pesado es la analítica y transcodificar streams para los monitores; los fabricantes suelen pedir 8 GB de base y 16 o más con analítica activa. El tercero — el que más se olvida — son los discos.
La escritura de CCTV es continua, secuencial y eterna: 24/7, los 365 días. Nuestro ejemplo "chico" escribe 126 TB al año — 63 TB por disco si es un par en espejo. Un disco de escritorio típico está especificado para unos 55 TB/año de carga de trabajo y uso de oficina; lo estarías haciendo trabajar sobre su rating desde el día uno. Los discos de videovigilancia ("purple", SkyHawk y compañía) están especificados para 180 TB/año, operación 24/7 y firmware pensado para streams: fallan menos y fallan más tarde. La calculadora de servidor VMS cruza cámaras, bitrate, retención y límites por servidor para decirte cuántas máquinas y qué discos necesitas.
PoE: tus cámaras también almuerzan
Cada cámara IP come watts por el mismo cable de datos, y el switch tiene un presupuesto finito. Una domo fija consume 4–7 W: clase 802.3af de sobra (hasta 12,95 W entregados al equipo). Pero el IR de largo alcance, los motores de una PTZ o el calefactor de una cámara de intemperie cambian la liga: PoE+ (802.3at, 25,5 W) o incluso 802.3bt para las más golosas. Nuestras 8 cámaras a ~6 W suman 48 W — y un switch PoE de 8 puertos con presupuesto de 60 W queda con 12 W libres: la PTZ que alguien va a pedir el próximo año ya no cabe. Haz la suma con la calculadora de presupuesto PoE antes de cotizar el switch, y si el tema clases-watts-caída de tensión te resulta nuevo, la guía PoE sin sorpresas lo destripa completo.
La receta cabe en una servilleta: define el nivel DORI de cada punto, elige el lente con la calculadora, multiplica bitrate por tiempo antes de cotizar discos y verifica que servidor y switch aguanten la carga. Pasa el proyecto completo por la calculadora de proyecto CCTV y llega a la reunión con números — que "se ve, pero no se reconoce" lo diga la competencia.