Comprenda cómo el bitrate afecta a la calidad de imagen, el ancho de banda y el almacenamiento en CFTV IP, cómo funcionan CBR, VBR, MBR y ABR y cómo dimensionar red y storage con criterios de ingeniería.
¡Descúbrelo!
El bitrate en CFTV es la cantidad de datos que genera un stream de vídeo por unidad de tiempo, normalmente expresada en Mbit/s o kbit/s. No es solo un parámetro de la cámara: es una variable de diseño que conecta calidad de imagen, capacidad de red, carga de los servidores y volumen de almacenamiento. Cuanto mayor sea la tasa de bits efectivamente producida, mayor tenderá a ser la demanda sobre uplinks, interfaces de red y storage; cuanto más agresivamente se limite, mayor puede ser la pérdida de detalle visual en escenas complejas.
Por ello, no existe un único “bitrate correcto” definido únicamente por la resolución de la cámara. Una cámara de 4 MP no tiene, por definición, una tasa fija; dos cámaras con la misma resolución y el mismo codec pueden generar flujos muy diferentes según movimiento, iluminación, ruido, tasa de fotogramas, GOP, estrategia de rate control e implementación del encoder. El dimensionamiento correcto parte del objetivo de supervisión y de la calidad de evidencia requerida, define los parámetros de captura y compresión y solo entonces verifica si la red y el almacenamiento soportan el comportamiento medio y de pico del conjunto.
¿Qué es el bitrate en CFTV IP?
En vídeo digital, el bitrate es el caudal de datos producido por el proceso de codificación. Si un stream opera a 4 Mbit/s, significa que, durante un intervalo determinado, el encoder produce aproximadamente cuatro millones de bits por segundo de vídeo codificado. Este número puede ser un valor medido, una media temporal, un objetivo de control o un límite máximo, según el modo de rate control implementado por el equipo.
No CFTV IP, el vídeo sale de la cámara como tráfico de red y atraviesa switches, uplinks e interfaces de servidores hasta llegar al VMS y al subsistema de grabación. El mismo parámetro que define cuánto tráfico atraviesa la red también determina, en una primera aproximación, cuántos bytes deben grabarse por unidad de tiempo.
La relación es directa:
bitrate → tráfico de red → tasa de escritura → capacidad de retención.
Pero esta relación no debe confundirse con una equivalencia absoluta. El bitrate indicado por la cámara representa el stream codificado; la red transporta ese stream con encapsulados y protocolos adicionales; el storage trabaja además con sistema de archivos, índices, bases de datos del VMS, metadatos, redundancia y políticas de retención. El cálculo básico es el punto de partida, no el resultado final del diseño.
¿Por qué no puede elegirse el bitrate únicamente por la resolución?
La resolución indica cuántos píxeles forman cada fotograma, pero no informa cuántos bits serán necesarios para representar la secuencia de fotogramas después de la compresión. El encoder busca redundancias espaciales y temporales. Una pared estática, bien iluminada y con poco ruido es altamente compresible; la misma cámara orientada hacia árboles con viento, lluvia, reflejos, tráfico intenso o una escena nocturna con ruido puede exigir muchos más datos para conservar una calidad equivalente.
Los factores que más modifican la tasa efectiva incluyen:
- resolución y relación de aspecto de la imagen;
- tasa de fotogramas por segundo;
- cantidad y velocidad del movimiento;
- nivel de detalle espacial de la escena;
- ruido electrónico, especialmente con baja iluminación;
- tiempo de exposición y motion blur;
- WDR y dinámica lumínica;
- codec e implementación del encoder;
- intervalo entre fotogramas I y estructura del GOP;
- política de calidad/compresión;
- modo de control de tasa;
- funciones de codificación orientadas a región de interés o contenido;
- existencia de audio y metadatos asociados.
Esto explica por qué las tablas genéricas del tipo “1080p = X Mbit/s” sirven solo como referencia preliminar. En diseño, el valor debe confirmarse con premisas explícitas y, cuando la criticidad lo justifique, mediante pruebas con escenas representativas.
¿Cómo influyen H.264 y H.265 en el bitrate?
H.264/AVC y H.265/HEVC utilizan compresión temporal para representar una secuencia de vídeo con menos datos de los necesarios para codificar íntegramente todos los fotogramas. La eficiencia se deriva de herramientas de predicción, transformación y codificación, pero la norma del codec no prescribe un único algoritmo de rate control ni garantiza que dos encoders distintos produzcan la misma relación entre calidad y bitrate.
Este punto es decisivo para la especificación. La recomendación ITU-T define la sintaxis y los mecanismos necesarios para producir y decodificar un bitstream compatible. La estrategia concreta empleada por el encoder para decidir cuánto detalle preservar, dónde utilizar bits y cómo reaccionar ante la complejidad de la escena puede variar entre implementaciones.
H.265 no significa automáticamente “la mitad del bitrate”
Es habitual encontrar porcentajes fijos de ahorro atribuidos a H.265 frente a H.264. Esto no debe convertirse en una premisa universal de diseño. La ganancia real depende de la resolución, movimiento, textura, ruido, GOP, perfil, nivel de calidad, capacidad del procesador e implementación del fabricante. En determinadas escenas la ganancia puede ser significativa; en otras, menor de lo esperado.
Para el dimensionamiento, el enfoque técnicamente defendible es comparar los codecs en condiciones equivalentes de calidad de imagen y escena, utilizando datos del equipo o mediciones representativas. El codec debe reducir la demanda sin comprometer el objetivo de supervisión.
También existe un coste operativo: los codecs más eficientes pueden exigir mayor capacidad de decodificación en clientes, servidores, GPU o estaciones de operación. Por tanto, el bitrate no puede optimizarse de forma aislada de la cadena de procesamiento.
GOP, I-frames, P-frames y su efecto sobre el bitrate
La compresión temporal trabaja con fotogramas que desempeñan funciones diferentes. Un I-frame es autocontenido: puede decodificarse sin depender de otro fotograma. Los fotogramas predictivos reutilizan información de fotogramas de referencia y, por ello, generalmente consumen menos bits.
El conjunto entre fotogramas clave forma un GOP, o Group of Pictures. Reducir la frecuencia de I-frames tiende a disminuir el bitrate medio porque los fotogramas completos se envían con menor frecuencia. Sin embargo, un GOP más largo aumenta la dependencia temporal y puede afectar al tiempo de recuperación tras pérdidas, al acceso aleatorio a las grabaciones y al comportamiento en determinadas aplicaciones forenses.
El dimensionamiento debe evitar dos simplificaciones opuestas: considerar irrelevante el intervalo de I-frame o maximizar el GOP únicamente para ahorrar ancho de banda. El parámetro debe ser compatible con la operación, grabación, reproducción, interoperabilidad y resiliencia del stream.
El pico de un I-frame importa para la red
Incluso cuando el bitrate medio parece holgado, los I-frames pueden generar ráfagas mayores. Si muchas cámaras están configuradas de forma similar y producen picos próximos en el tiempo, el tráfico instantáneo en uplinks o interfaces de grabación puede alejarse considerablemente de la media. Esta es una de las razones para no dimensionar la red únicamente dividiendo la capacidad nominal del enlace por el bitrate medio de cada cámara.
CBR, VBR, MBR y ABR: ¿cuál es la diferencia?
La nomenclatura de rate control varía entre fabricantes y plataformas. Por ello, la especificación debe describir el comportamiento previsto y no limitarse a exigir una sigla. En términos funcionales, los cuatro conceptos más habituales son los siguientes.
| Modo | Variable priorizada | Comportamiento típico | Principal riesgo de diseño |
| CBR | presupuesto/objetivo de bitrate | el encoder ajusta la calidad para mantenerse cerca del objetivo | degradar el detalle cuando la escena se vuelve compleja |
| VBR | calidad definida | el bitrate aumenta o disminuye según la complejidad de la escena | picos superiores a la media prevista |
| MBR | calidad con techo de bitrate | VBR hasta acercarse al límite; después el encoder restringe la calidad y/o otro parámetro | alcanzar el techo precisamente durante el evento crítico |
| ABR | presupuesto medio a lo largo del tiempo | el controlador compensa períodos de menor y mayor consumo buscando una media | confundir la media temporal con la capacidad instantánea necesaria |
CBR: Constant Bit Rate
CBR suele traducirse como tasa de bits constante, pero en implementaciones reales debe entenderse como control en torno a un bitrate objetivo. La complejidad del vídeo continúa variando. Para respetar el presupuesto, el encoder modifica parámetros de cuantización y calidad, y la tasa instantánea puede oscilar.
La principal ventaja es la previsibilidad. Cuando un enlace dispone de una capacidad contratada o restringida, trabajar con un objetivo conocido facilita la planificación. El coste es que, durante escenas difíciles, la limitación de bits puede manifestarse como pérdida de textura, bloques o reducción de calidad precisamente cuando existe más información visual.
VBR: Variable Bit Rate
En VBR, el sistema procura mantener una calidad determinada y permite que el bitrate acompañe la complejidad de la escena. Una zona vacía y estática puede consumir poco; la aparición repentina de personas, vehículos, lluvia o ruido puede elevar significativamente el caudal.
Es una estrategia coherente para aplicaciones en las que preservar la calidad es prioritario, siempre que la infraestructura se dimensione para picos plausibles y no únicamente para la media observada en condiciones favorables.
MBR: Maximum Bit Rate
MBR combina un comportamiento variable con un techo. Mientras la escena cabe dentro del presupuesto, el encoder conserva la calidad configurada. Al aproximarse al límite, debe modificar la codificación para impedir que el stream supere el caudal máximo.
Este mecanismo es útil cuando existe una restricción objetiva de ancho de banda. Sin embargo, el techo debe validarse en escenas críticas. Si el límite se elige únicamente para “caber en la red”, el sistema puede responder al evento más complejo degradando precisamente la imagen que debería preservar.
ABR: Average Bit Rate
ABR trabaja con un presupuesto medio a lo largo de un período. El principio consiste en permitir que los momentos de menor consumo generen margen para momentos más exigentes, buscando cumplir un volumen medio planificado. Resulta especialmente útil cuando la retención es la restricción dominante.
La existencia de una media controlada no elimina los picos instantáneos. La red y las interfaces siguen necesitando soportar los caudales transitorios permitidos por el encoder.
¿Qué modo elegir en el diseño?
No existe una respuesta universal. La elección depende de la restricción dominante.
Cuando la calidad forense es prioritaria y la red dispone de capacidad suficiente, VBR o estrategias equivalentes orientadas a la calidad tienden a preservar mejor las escenas complejas. En enlaces limitados, MBR puede establecer un techo necesario, pero ese techo debe probarse. CBR puede ser adecuado cuando la previsibilidad del ancho de banda es un requisito fuerte, siempre que se demuestre la calidad en el peor escenario. ABR tiene sentido cuando el problema principal es gestionar un presupuesto de almacenamiento a lo largo del tiempo.
El criterio de ingeniería es sencillo: no elegir el modo por la sigla; elegirlo por el comportamiento que debe tener el sistema cuando la escena se aleja de la condición media.
¿Cómo calcular el tráfico agregado de un sistema CFTV?
La primera aproximación consiste en sumar los bitrates de los streams que realmente atraviesan el enlace analizado.
Si Bᵢ es el bitrate del stream activo de la cámara i, entonces:
B_total = Σ Bᵢ
Para cámaras equivalentes:
B_total = N × B_câmera
donde N es el número de cámaras transportadas simultáneamente en ese segmento.
Este cálculo debe aplicarse por ruta de tráfico. El uplink de un switch de acceso puede transportar únicamente las cámaras de ese armario; la interfaz del recording server puede recibir cámaras de varios switches; un enlace WAN puede transportar solo streams seleccionados, substreams o eventos.
Ejemplo: 25, 50 y 100 cámaras a 4 Mbit/s
Considerando únicamente el payload nominal de un stream de grabación de 4 Mbit/s por cámara:
| Cámaras | Bitrate por cámara | Tráfico agregado nominal |
| 25 | 4 Mbit/s | 100 Mbit/s |
| 50 | 4 Mbit/s | 200 Mbit/s |
| 100 | 4 Mbit/s | 400 Mbit/s |
Estos valores no permiten concluir que un enlace de 100 Mbit/s sea adecuado para las 25 cámaras del primer escenario. La capacidad nominal de la interfaz no equivale a la capacidad de diseño disponible para vídeo. Deben considerarse overhead de protocolos, variaciones del encoder, otros servicios, ráfagas, contingencias y políticas de disponibilidad.
Para profundizar en la topología y localizar cuellos de botella entre acceso, uplinks, backbone, VMS y storage, el tema se aborda en detalle en el artículo sobre infraestructura de CFTV IP.
Media, pico, percentiles y peor caso
Un sistema VBR no debe caracterizarse mediante una única lectura de bitrate. Una medición corta en una escena vacía puede producir un valor aparentemente excelente y completamente inadecuado para el horario de mayor movimiento o para condiciones nocturnas.
Una campaña de medición útil debe registrar la serie temporal y evaluar, según la criticidad:
- media durante el período observado;
- máximos instantáneos o en ventanas cortas;
- percentiles como P95 y P99;
- comportamiento diurno y nocturno;
- presencia de lluvia, vegetación, sombras, faros y movimiento intenso;
- eventos de alarma y cambios de escena.
La media es útil para estimar el volumen de almacenamiento. El pico y los percentiles altos son relevantes para dimensionar la red y comprender el margen operativo. El peor escenario técnico también debe considerar condiciones que quizá no hayan ocurrido durante la prueba.
El bitrate medio no es lo mismo que la capacidad del enlace
Una interfaz Ethernet de 1 Gbit/s no debe tratarse como un “depósito” de exactamente 1.000 Mbit/s disponibles para vídeo. El diseño debe considerar el conjunto de tráfico que comparte el enlace y los requisitos de disponibilidad.
En una red de CFTV IP, los cuellos de botella más frecuentes aparecen en los puntos de concentración: uplinks, stacking, trunks, backbone, interfaces de servidores y rutas hacia el storage. Un puerto de cámara en Fast/Gigabit Ethernet rara vez constituye el limitante de todo el sistema; el problema aparece cuando convergen decenas o cientos de streams.
No existe un margen porcentual universal que sustituya el cálculo. El headroom debe reflejar picos, crecimiento previsto, failover, tráfico concurrente y comportamiento del equipo.
Múltiples streams: ¿cuándo deben sumarse?
Las cámaras IP normalmente permiten más de un stream con diferentes resoluciones, FPS, codec o calidad. Un stream principal puede destinarse a la grabación; otro, más ligero, a la visualización en mosaico; un tercero puede atender una integración específica.
Un error habitual consiste en sumar todos los streams configurados como si estuvieran permanentemente activos. El error opuesto es ignorar que varios consumidores pueden generar tráfico simultáneo.
El cálculo debe responder:
- qué streams se producen continuamente;
- cuáles se solicitan solo bajo demanda;
- si la cámara envía flujos unicast independientes a varios clientes;
- si el VMS recibe una vez y redistribuye el vídeo a los clientes;
- si se utiliza multicast y en qué tramos;
- cómo cambia el comportamiento durante alarmas, reproducción e investigación.
Este análisis es especialmente importante en centros de control con muchas pantallas, clientes remotos e integraciones.
Unicast, multicast y redistribución por el VMS
En unicast, cada sesión puede exigir una copia del flujo para el destinatario. Si varios clientes acceden directamente a la misma cámara, el tráfico de salida del dispositivo y de los segmentos implicados puede crecer con el número de consumidores. En arquitecturas en las que el VMS actúa como proxy o distribuidor, la cámara puede proporcionar un flujo al servidor mientras los clientes reciben copias desde la infraestructura de backend.
Multicast puede reducir duplicaciones en determinadas topologías de visualización en vivo, pero exige una red preparada para este comportamiento y no elimina la necesidad de dimensionar la grabación. El diseño debe mapear el origen, destino y dirección de cada flujo relevante.
¿Cómo calcular el almacenamiento a partir del bitrate?
Para un stream continuo, la conversión básica es directa. Utilizando unidades decimales:
GB por día ≈ bitrate en Mbit/s × 10,8
Esto se obtiene de:
Mbit/s × 1.000.000 × 86.400 s ÷ 8 ÷ 1.000.000.000
Por tanto, un stream medio de 4 Mbit/s genera aproximadamente:
4 × 10,8 = 43,2 GB/día
Para un período de 30 días:
43,2 × 30 = 1.296 GB ≈ 1,296 TB por cámara
Ejemplos de retención continua durante 30 días
| Cámaras | Bitrate medio | Payload/día | Payload/30 días |
| 25 | 4 Mbit/s | 1,08 TB | 32,4 TB |
| 50 | 4 Mbit/s | 2,16 TB | 64,8 TB |
| 100 | 4 Mbit/s | 4,32 TB | 129,6 TB |
Estos valores representan el payload nominal de vídeo. El volumen bruto de discos necesario será mayor al incluir filesystem, bases de datos e índices del VMS, metadatos, reserva operativa, RAID o erasure coding, hot spare, políticas de retención y demás requisitos de la plataforma.
El dimensionamiento completo del subsistema se aborda en el contenido específico sobre storage para CFTV y VMS corporativo.
¿Y cuando la grabación es por eventos?
Si la grabación no es continua, puede utilizarse un factor de actividad como estimación inicial:
Storage ≈ bitrate medio durante la grabación × tiempo efectivamente grabado.
Si una cámara graba, de media, el 40% de las 24 horas, la estimación preliminar puede aplicar un factor de 0,40 al volumen continuo. Sin embargo, este porcentaje debe tratarse con cautela. La sensibilidad del detector, pre-buffer, post-buffer, horarios, sombras, lluvia, vegetación y analytics modifican la duración real de los eventos.
En sistemas críticos, la retención por eventos debe validarse a partir de datos observados o premisas conservadoras. Un factor de actividad arbitrario puede subdimensionar silenciosamente el storage.
FPS y bitrate: ¿duplicar los fotogramas por segundo duplica el ancho de banda?
No necesariamente. La relación no es perfectamente lineal porque los codecs interframe explotan la redundancia temporal. Pasar de 15 a 30 fps aumenta la cantidad de información temporal que debe codificarse, pero el impacto depende del movimiento, GOP, codec y encoder.
La pregunta correcta no es “¿qué FPS ahorra más?”, sino qué tasa de fotogramas es necesaria para el objetivo de supervisión. Movimientos rápidos, cajas, líneas de producción, tráfico vehicular e investigación fotograma a fotograma pueden exigir tasas superiores a las de zonas de baja dinámica.
Reducir FPS únicamente para hacer que el sistema quepa en la red es una decisión de ingeniería solo si el requisito operativo sigue cumpliéndose.
La baja iluminación puede aumentar el bitrate
Una consecuencia poco intuitiva es que una escena aparentemente “estática” puede consumir más datos por la noche. Con baja iluminación, la ganancia electrónica tiende a aumentar y, con ella, el ruido de la imagen. Para el encoder, este ruido se parece a una variación espacial y temporal que debe representarse.
Por ello, una prueba realizada únicamente durante el día puede subestimar el bitrate nocturno. Iluminación, exposición, ganancia, reducción de ruido y configuración del codec interactúan directamente con el ancho de banda y el almacenamiento.
Esta relación muestra por qué la calidad de imagen y la infraestructura no pueden tratarse como disciplinas independientes.
Movimiento, vegetación, lluvia y escenas de alta complejidad
Árboles, agua, humo, partículas, lluvia intensa, multitudes y tráfico generan cambios continuos en gran parte del fotograma. En VBR, esto puede elevar considerablemente el consumo. En CBR/MBR, la misma complejidad puede presionar al controlador hasta el punto de sacrificar detalles.
Una cámara perimetral orientada hacia vegetación no debe recibir automáticamente el mismo presupuesto de bitrate que una cámara de pasillo interior simplemente porque ambas tengan la misma resolución.
El diseño debe clasificar las escenas según su comportamiento previsto y asignar parámetros compatibles con cada clase.
Resolución, densidad de píxeles y calidad forense
El bitrate no puede utilizarse como sustituto de un criterio de calidad. Una cámara puede transmitir 8 Mbit/s de una escena mal encuadrada y seguir siendo incapaz de identificar el objetivo. La calidad necesaria nace del requisito de imagen: campo de visión, densidad de píxeles sobre el objeto, iluminación, enfoque, movimiento y condiciones ambientales.
El artículo sobre puntos de supervisión y densidad de píxeles profundiza en esta etapa. Solo después de definir la imagen útil tiene sentido optimizar la compresión.
Cómo dimensionar uplinks de switches de acceso
El procedimiento consiste en calcular qué cámaras convergen en cada uplink y cuál es el perfil de bitrate de diseño de cada una. Si un switch tiene 20 cámaras y cada stream de grabación ha sido validado con un pico de diseño de 8 Mbit/s, la principal contribución de vídeo puede alcanzar 160 Mbit/s en ese trayecto, antes de otros flujos y overhead.
A continuación, se evalúan:
- capacidad efectiva del uplink;
- simultaneidad de los picos;
- tráfico de gestión y otros servicios;
- streams adicionales;
- crecimiento previsto;
- comportamiento ante el fallo de un enlace o equipo;
- agregación LACP, cuando corresponda;
- capacidad del siguiente nivel de concentración.
El cálculo debe continuar hasta el recording server y el storage. Resolver únicamente el primer uplink desplaza el cuello de botella hacia el core o las interfaces de los servidores.
Bitrate e interfaces del servidor de grabación
El servidor de grabación recibe una suma de streams, ejecuta procesamiento y escribe datos en el subsistema de almacenamiento. Según la arquitectura, también puede servir vídeo grabado, redistribuir live view y procesar metadatos.
Por tanto, la NIC del servidor debe analizarse en dos direcciones: entrada de grabación y salida hacia clientes o storage externo. En sistemas grandes, pueden ser necesarias múltiples interfaces, segregación de tráfico, bonding/teaming y distribución de recording servers.
La capacidad de red del servidor no debe confundirse con la capacidad de escritura del array. Un servidor puede recibir correctamente los paquetes y aun así perder grabaciones si el backend de storage no soporta los IOPS, throughput o latencia exigidos por la plataforma.
Rate control no sustituye a QoS
CBR o MBR controlan el comportamiento del encoder. QoS actúa sobre el tratamiento y la priorización del tráfico en la red. Son mecanismos diferentes.
Limitar cada cámara a un techo no garantiza que el vídeo crítico tenga prioridad cuando el enlace esté congestionado. Del mismo modo, marcar paquetes con prioridad no corrige un sistema cuya demanda permanente supera la capacidad física.
QoS es una capa de gobernanza del tráfico; el dimensionamiento sigue siendo necesario.
Cómo tratar enlaces WAN y sitios remotos
WAN introduce restricciones diferentes de LAN: ancho de banda contratado, asimetría, latencia, jitter, pérdidas, indisponibilidad y coste de transporte. En sitios remotos, puede ser inadecuado transmitir permanentemente el stream de grabación con máxima calidad hacia el centro.
Las arquitecturas posibles incluyen grabación local, edge storage, transmisión de substream para operación, recuperación posterior del vídeo de alta calidad y envío de streams principales únicamente durante eventos. La elección depende del requisito de continuidad y del tiempo máximo aceptable para recuperar evidencias.
En este contexto, el bitrate es una variable arquitectónica. La mejor solución puede no consistir simplemente en comprimir más, sino en cambiar dónde se graba el vídeo y por dónde necesita circular.
Edge storage y failover
El almacenamiento en el borde permite mantener la grabación cerca de la cámara durante la pérdida de conectividad con el servidor central. Cuando la plataforma admite recuperación posterior, el vídeo faltante puede reintegrarse al archivo central.
Esta función modifica el perfil de tráfico: durante el fallo, el stream deja de llegar al servidor; durante la recuperación, puede aparecer tráfico adicional para sincronizar el backlog mientras el vídeo actual continúa transmitiéndose. El enlace también debe evaluarse en este estado de recuperación.
Bitrate y analytics
Los analytics pueden ejecutarse en la cámara, en el servidor o en infraestructura especializada. Cuando el procesamiento se realiza en el borde, no siempre es necesario transportar un stream adicional únicamente para ejecutar el análisis. Cuando analytics recibe vídeo en otro servidor, puede existir un nuevo flujo o una redistribución del stream ya recibido por el VMS.
Los metadatos analíticos normalmente representan un volumen muy inferior al vídeo, pero forman parte del sistema y deben considerarse en las interfaces, el storage y las integraciones cuando la retención de estos datos sea un requisito.
Más importante aún: la compresión no puede degradar la imagen hasta perjudicar el algoritmo. Un límite de bitrate adecuado para visualización humana puede no ser adecuado para el análisis automatizado previsto.
Bitrate y ciberseguridad
La protección del vídeo mediante protocolos seguros añade procesamiento y cierto overhead, pero esto no justifica eliminar el cifrado para “ahorrar ancho de banda”. La ciberseguridad debe ser un requisito de arquitectura. El diseño debe garantizar que switches, cámaras, servidores y clientes dispongan de capacidad para operar los mecanismos de protección previstos sin comprometer el rendimiento.
El tema se desarrolla con mayor profundidad en el whitepaper sobre ciberseguridad en sistemas CFTV.
Una metodología de dimensionamiento en nueve etapas
Un dimensionamiento trazable puede seguir la secuencia siguiente.
- Definir el objetivo de supervisión. Establecer qué debe permitir observar, detectar, reconocer o identificar cada punto y en qué condiciones.
- Definir parámetros de captura. Resolución, campo de visión, FPS, exposición, WDR y demás parámetros que influyen en la imagen útil.
- Definir codec y estrategia de rate control. Elegir H.264/H.265 y el comportamiento esperado de VBR, CBR, MBR o equivalente.
- Clasificar las escenas. Separar escenarios estáticos, dinámicos, exteriores, nocturnos, con vegetación, tráfico u otras condiciones relevantes.
- Obtener bitrate de referencia. Utilizar herramientas de diseño, datos del fabricante o mediciones representativas con premisas documentadas.
- Definir media y pico de diseño. No utilizar un único valor para todas las verificaciones cuando el stream es variable.
- Mapear los flujos en la topología. Sumar únicamente los streams que recorren cada enlace, servidor o interfaz.
- Dimensionar la retención. Convertir el bitrate medio en volumen, añadir las capas de storage y validar la política de retención.
- Comisionar y medir. Confirmar en campo imagen, bitrate, tráfico, grabación y recuperación en los estados previstos.
Esta secuencia evita el error clásico de elegir primero las cámaras, completar después una hoja genérica de Mbps y descubrir el cuello de botella únicamente durante la implantación.
Matriz de diseño: parámetro, impacto y evidencia
| Parámetro | Impacto principal | Qué debe verificarse |
| resolución | detalle espacial y volumen de datos | cumplimiento del objetivo de imagen |
| FPS | continuidad temporal y consumo | movimiento crítico reproducido adecuadamente |
| codec | eficiencia y carga de procesamiento | compatibilidad y calidad equivalente |
| GOP/I-frame | bitrate, recuperación y acceso aleatorio | comportamiento durante grabación y pérdida |
| VBR/CBR/MBR/ABR | relación calidad × previsibilidad | escena crítica dentro del presupuesto |
| bitrate medio | volumen de almacenamiento | retención real alcanzada |
| bitrate de pico | capacidad de red | ausencia de saturación y pérdidas |
| múltiples streams | carga en cámara/red/VMS | simultaneidad efectiva |
| grabación por eventos | duty cycle y retención | duración real de los eventos |
| edge/failover | continuidad y recuperación | backlog reintegrado sin colapso de la red |
Ejemplo completo: 100 cámaras corporativas
Considere 100 cámaras cuyo stream principal ha sido validado con una media de 4 Mbit/s y picos de diseño de hasta 8 Mbit/s en escenas representativas.
Para almacenamiento continuo, la media agregada es:
100 × 4 = 400 Mbit/s.
El payload nominal diario es:
400 × 10,8 = 4.320 GB/día = 4,32 TB/día.
Para 30 días:
4,32 × 30 = 129,6 TB de vídeo nominal.
Este valor no es el tamaño final del array. Todavía deben aplicarse la arquitectura de storage, redundancia, reserva, filesystem, metadatos, política de retención y requisitos del VMS.
Para la red, no sería correcto dimensionar los trayectos únicamente por los 400 Mbit/s medios. Si todos los streams pueden alcanzar 8 Mbit/s, la ingeniería debe estudiar la simultaneidad y el comportamiento de pico en los puntos de concentración. El límite superior teórico de la contribución de los streams sería de 800 Mbit/s, antes de otros tráficos. La topología puede distribuir las cámaras entre varios uplinks y recording servers, reduciendo la concentración en una única ruta.
El ejemplo muestra por qué el storage está gobernado predominantemente por la media a lo largo del tiempo, mientras que la red debe sobrevivir a caudales altos plausibles.
Ejemplo de sitio remoto con enlace restringido
Considere una unidad remota con 20 cámaras y un uplink WAN limitado. Transmitir 20 streams principales a 4 Mbit/s exigiría 80 Mbit/s nominales únicamente para vídeo continuo, lo que puede ser incompatible con el enlace o con los demás servicios corporativos.
Existen al menos tres estrategias de ingeniería:
- reducir el bitrate del stream remoto preservando localmente la grabación principal;
- transmitir substreams para supervisión y solicitar el stream principal solo cuando sea necesario;
- mantener grabación local/edge y sincronizar evidencias durante eventos o ventanas controladas.
La mejor opción depende del requisito operativo. Reducir simplemente todos los streams a un bitrate arbitrario puede eliminar el problema de ancho de banda y crear un problema de evidencia.
Cómo especificar bitrate sin vincular el diseño a un fabricante
Una especificación independiente de marca debe evitar valores copiados de un datasheet sin relación con el requisito. En lugar de exigir un “bitrate fijo de X Mbit/s”, es más robusto establecer criterios de desempeño.
Ejemplos de requisitos verificables:
- permitir la configuración de resolución, FPS, codec y parámetros de rate control necesarios para la arquitectura;
- permitir limitar el bitrate cuando exista una restricción de enlace;
- preservar la calidad mínima definida para las escenas de referencia;
- soportar los streams simultáneos previstos en el diseño;
- proporcionar interoperabilidad con el VMS y el perfil de codificación adoptado;
- permitir consultar o medir el bitrate efectivo;
- mantener una operación estable en el escenario de mayor complejidad especificado.
La especificación puede indicar un presupuesto de red o un rango de diseño, pero la aceptación debe demostrar el resultado operativo, no solo la presencia de una opción en el menú de la cámara.
¿Qué debe probarse durante el comisionamiento?
El bitrate debe incluirse en el plan de pruebas cuando influya en la red, la retención o la calidad. El comisionamiento puede comparar la memoria de cálculo con el comportamiento real del sistema.
Una campaña mínima debe contemplar:
- streams y parámetros configurados conforme al diseño;
- mediciones de bitrate medio y de pico;
- verificación de uplinks e interfaces de grabación;
- reproducción simultánea y live view previstos;
- comportamiento durante alarmas;
- escenario nocturno y escenas de mayor movimiento;
- retención efectivamente obtenida;
- pérdida de conectividad y recuperación, cuando exista failover;
- calidad de imagen bajo el límite de bitrate especificado.
La aceptación no debe limitarse a confirmar que “la cámara graba”. Es necesario demostrar que el sistema graba la calidad prevista, durante el período previsto y sin superar la capacidad de la infraestructura.
Errores comunes al dimensionar bitrate en CFTV
Utilizar un único valor de Mbps para cualquier cámara
Ignora la escena, iluminación, FPS, codec, GOP y comportamiento del encoder.
Dimensionar la red por la media de VBR
La media puede ser adecuada para el storage y aun así ocultar picos que saturen los uplinks.
Utilizar el límite máximo como si fuera la media de storage
Esto puede sobredimensionar drásticamente la retención cuando el stream rara vez alcanza el techo. Lo contrario — utilizar una media optimista como garantía de máximo — también es incorrecto.
Asumir un ahorro fijo al cambiar de H.264 a H.265
La eficiencia depende de la implementación y de las condiciones del vídeo. Los porcentajes genéricos no sustituyen las pruebas ni los datos del equipo.
Ignorar el período nocturno
El ruido y la ganancia pueden elevar la demanda de bitrate y modificar la calidad bajo CBR/MBR.
Ignorar streams de visualización e integraciones
Mosaicos, operadores, analytics, clientes remotos e integraciones pueden generar tráfico adicional.
Sumar todos los streams configurados sin analizar simultaneidad
No todos los streams existentes están activos todo el tiempo. El mapa de flujos debe representar el comportamiento real.
Tratar RAID como capacidad nominal disponible
La suma de los discos no equivale a la capacidad útil. La redundancia, los spares y el filesystem reducen el espacio efectivamente disponible para vídeo.
El bitrate debe tratarse en el diseño de CFTV, no en la configuración final
Cuando el bitrate solo se analiza durante la implantación, las decisiones más importantes ya se han tomado: cantidad de cámaras, topología, uplinks, servidores, storage, retención y enlaces remotos. En esta etapa, “reducir el bitrate” pasa a ser un intento de hacer que el sistema quepa en la infraestructura contratada.
En el Diseño de CFTV IP y Videovigilancia, la tasa de bits debe formar parte de la memoria de dimensionamiento y de la arquitectura: las premisas por clase de cámara, la estimación media, los picos, flujos simultáneos, retención y márgenes deben ser coherentes entre sí.
Este enfoque también mejora el procurement y la supervisión. La contratista no recibe únicamente una cantidad de cámaras y días de retención; recibe criterios verificables para demostrar que la solución propuesta cumple los requisitos de red, procesamiento y almacenamiento.
Consideraciones finales
El bitrate es la variable de enlace entre imagen e infraestructura en un sistema CFTV IP. No debe elegirse mediante una tabla genérica, por el valor default de la cámara ni por un porcentaje de compresión supuesto. El diseño debe comenzar por el objetivo de supervisión, caracterizar las escenas, definir captura y codec, seleccionar la estrategia de rate control y, a continuación, calcular cómo se acumulan los flujos en cada tramo de la arquitectura.
Para el storage, la media temporal determina el volumen principal de grabación. Para la red, los picos, ráfagas y simultaneidad pasan a ser decisivos. Para la calidad, la prueba fundamental consiste en verificar qué ocurre cuando la escena se vuelve más difícil y el encoder debe trabajar dentro del presupuesto disponible.
Cuando estos tres ejes — imagen, red y retención — se tratan conjuntamente, el bitrate deja de ser una configuración de cámara y pasa a ser lo que realmente es: un parámetro de ingeniería del sistema de videovigilancia.
Referencias técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). IEC 62676-1-2:2013 — Video surveillance systems for use in security applications — Part 1-2: System requirements — Performance requirements for video transmission. 2013. Disponible en: https://webstore.iec.ch/en/publication/7348.
[2] INTERNATIONAL TELECOMMUNICATION UNION (ITU-T). Recommendation H.264 (06/2026) — Advanced video coding for generic audiovisual services. 2026. Disponible en: https://www.itu.int/rec/T-REC-H.264.
[3] INTERNATIONAL TELECOMMUNICATION UNION (ITU-T). Recommendation H.265 (01/2026) — High efficiency video coding. 2026. Disponible en: https://www.itu.int/rec/T-REC-H.265.
[4] AXIS COMMUNICATIONS. Technical Guide to Network Video. Disponible en: https://www.axis.com/forms/technical-guide-to-network-video.
Preguntas frecuentes
Es la cantidad de datos producida por el stream de vídeo por unidad de tiempo, normalmente en kbit/s o Mbit/s. En diseño, el bitrate relaciona calidad de imagen, capacidad de red, carga de grabación y volumen de almacenamiento.
No existe un valor universal. El bitrate depende de resolución, FPS, movimiento, iluminación, ruido, codec, GOP, calidad configurada y estrategia de rate control. El valor debe definirse a partir del objetivo de imagen y validarse para las escenas previstas.
CBR trabaja en torno a un bitrate objetivo y tiende a ajustar la calidad para mantenerse dentro del presupuesto. VBR prioriza una calidad definida y permite que la tasa varíe según la complejidad de la escena. El comportamiento exacto depende de la implementación del encoder.
MBR es una estrategia de bitrate máximo: el stream puede variar mientras permanezca por debajo del techo, pero al alcanzar el límite el encoder debe restringir la codificación, pudiendo reducir la calidad u otro parámetro según la implementación.
No. H.265 puede ser más eficiente, pero la ganancia real depende del encoder, la escena, la resolución, el movimiento, GOP y el criterio de calidad. Un porcentaje fijo no debe utilizarse como premisa universal de dimensionamiento.
Para grabación continua y unidades decimales, una aproximación es GB/día ≈ bitrate en Mbit/s × 10,8. Después deben considerarse retención, cantidad de cámaras, redundancia, filesystem, metadatos y requisitos del VMS.
El payload nominal continuo es de aproximadamente 129,6 TB durante 30 días. Este no es el tamaño final del array: redundancia, filesystem, metadatos, reserva operativa y arquitectura del storage aumentan la capacidad bruta necesaria.
Con baja iluminación, el aumento de ganancia y ruido puede hacer que la imagen sea menos compresible. El encoder necesita representar más variaciones, lo que puede elevar la tasa en VBR o presionar la calidad cuando existe un límite CBR/MBR.
No. La media es útil para estimar el volumen de grabación, pero la red también debe verificarse para picos, ráfagas, simultaneidad, streams adicionales y estados de contingencia.
Sí, cuando sea una premisa de red, calidad o retención. Deben verificarse los parámetros configurados, bitrate medio y de pico, ocupación de uplinks, grabación, retención y calidad de las escenas críticas.
Materiales técnicos complementarios
Servicios relacionados
- Diseño de CFTV IP y Videovigilancia: cobertura, VMS, almacenamiento e integración
- Diseño de Red Lógica y Redes Corporativas
Contenidos principales sobre el tema
- Guía Completa sobre Sistemas CFTV
- ¿Qué es CFTV IP? Cómo funciona, componentes y arquitectura del sistema
