He visto a demasiados integradores perder horas depurando problemas de metadatos, solo para descubrir que su perfil de cámara era el verdadero problema.
Sí, ONVIF Perfil T1 soporta completamente la transmisión de metadatos con codificación H.265 (HEVC). El Perfil T fue diseñado específicamente para manejar flujos de video H.264 y H.265 junto con metadatos estructurados, incluyendo datos de análisis de IA, eventos de alarma y resultados de detección de objetos, todo sincronizado con la transmisión de video.
ONVIF Perfil T H.265 transmisión de metadatos cámara PTZ
Si está construyendo un sistema que depende de H.265 para ahorrar ancho de banda y aún necesita que los datos de eventos de IA fluyan a su VMS, este artículo detalla exactamente cómo el Perfil T maneja eso. Recorreré preocupaciones del mundo real, desde la entrega de cuadros delimitadores hasta la sobrecarga de procesamiento, para que pueda tomar la decisión correcta para su próxima implementación.
Índice
¿Puedo enviar cuadros delimitadores de detección humana por IA sobre H.265 a través de ONVIF?
Esta es la primera pregunta que recibo de los integradores que desean funciones de IA pero también necesitan compresión H.265. Les preocupa que los dos no funcionen bien juntos.
Absolutamente puede enviar cuadros delimitadores de detección humana por IA sobre H.265 a través de ONVIF Perfil T. Los metadatos, incluidos el tipo de objeto, las coordenadas y las puntuaciones de confianza, viajan en un flujo RTP separado dentro de la misma sesión RTSP, por lo que no interfiere en absoluto con la codificación de video H.265.
Metadatos de cuadros delimitadores de IA H.265 ONVIF Perfil T
Cómo viajan realmente los metadatos
Permítame explicarle lo que sucede internamente. Cuando su cámara detecta una persona, hace dos cosas al mismo tiempo. Primero, codifica el cuadro de video en H.265. Segundo, genera un paquete de metadatos basado en XML que describe lo que encontró: un objeto “Persona”, las coordenadas del cuadro delimitador y una marca de tiempo.
Estas dos piezas de información viajan a través de canales diferentes, pero comparten la misma sesión RTSP2. Piénselo como una autopista con dos carriles. El video toma un carril. Los metadatos toman el otro. Llegan al mismo destino al mismo tiempo.
La estructura XML detrás del cuadro delimitador
En Servicio de Análisis ONVIF3 define un esquema XML claro para los resultados de detección. Aquí hay una vista simplificada de cómo se ve un evento de detección único:
| Campo | Valor de ejemplo | Descripción |
|---|---|---|
| Tipo de Objeto | Persona | Lo que la IA detectó |
| Cuadro Delimitador X | 0.35 | Posición horizontal (normalizada 0-1) |
| Cuadro Delimitador Y | 0.22 | Posición vertical (normalizada 0-1) |
| Ancho | 0.12 | Ancho de la caja (normalizado) |
| Alto | 0.30 | Alto de la caja (normalizado) |
| Marca de tiempo | 2025-01-15T14:32:07Z | Sincronización de tiempo a nivel de fotograma |
| Confianza | 0.92 | Puntuación de confianza de la detección |
Su VMS lee estos datos XML y dibuja el cuadro delimitador en la pantalla. La cámara no graba la caja en el video. Esto es importante. Significa que puede activar o desactivar las cajas a nivel de software. También puede buscar por tipo de objeto más tarde, sin reprocesar el video.
Por qué esto es importante para implementaciones solares 4G
En nuestros sistemas solares PTZ 4G en Loyalty-Secu, el ancho de banda es precioso. H.265 ya reduce la tasa de bits aproximadamente a la mitad en comparación con H.264. El flujo de metadatos añade muy poco, generalmente entre 10 kbps y 50 kbps para unos pocos objetos detectados. Así que obtienes inteligencia artificial entregada a tu VMS sin un aumento significativo en el uso de datos.
Pero aquí hay un detalle que muchos pasan por alto. Si tu cámara está rastreando 20 o 30 objetos a la vez, digamos, una intersección concurrida, el flujo de metadatos crece. En esos casos, recomiendo limitar el número máximo de objetos rastreados en la configuración del firmware para mantener el ancho de banda total predecible en un enlace 4G.
¿Podrá mi VMS de terceros buscar en los metadatos H.265 eventos específicos?
He tenido clientes que compran cámaras con excelentes funciones de IA, solo para descubrir que su VMS no podía leer los metadatos. Esa es una lección dolorosa y costosa.
Tu VMS de terceros puede buscar metadatos H.265 para eventos específicos, pero solo si el VMS también admite ONVIF Profile T. Si tu VMS solo admite Profile S, recibirá el flujo de video pero ignorará por completo los metadatos, dejándote sin capacidad de búsqueda inteligente.
Búsqueda inteligente VMS metadatos H.265 ONVIF Profile T
La comprobación de compatibilidad de Profile T
Este es el paso más importante antes de comprometerte con un proyecto. Debes verificar ambos extremos de la cadena. La cámara debe admitir Profile T. El VMS también debe admitir Profile T. Si falta alguno de los lados, el enlace de metadatos se rompe.
Aquí hay una matriz de compatibilidad rápida que utilizo al asesorar a nuestros socios B2B:
| Plataforma VMS | Soporte Profile S | Soporte Profile T | Búsqueda inteligente a través de metadatos |
|---|---|---|---|
| Milestone XProtect4 | ✅ | ✅ (2020+) | ✅ |
| Genetec Security Center5 | ✅ | ✅ (2021+) | ✅ |
| Lirio azul | ✅ | ⚠️ Limitado | ❌ Nativo (requiere plugin) |
| Nx Witness (Network Optix)6 | ✅ | ✅ (v5.0+) | ✅ |
| Digifort | ✅ | ✅ (v7.4+) | ✅ |
| iSpy / Agent DVR | ✅ | ❌ | ❌ |
Si su VMS está en la columna “limitado” o “no”, tiene dos opciones. Puede actualizar el software VMS. O puede usar la interfaz web integrada de la cámara para acceder directamente a los eventos de IA; la mayoría de las cámaras PTZ profesionales, incluidas las nuestras, ofrecen esto como respaldo.
Cómo se ve realmente la “Búsqueda Inteligente”
Cuando los metadatos fluyen correctamente, su VMS puede hacer cosas como esta:
- Muéstrame todas las detecciones de “Persona” entre las 2:00 PM y las 4:00 PM.
- Muéstrame todas las detecciones de “Vehículo” en la Zona B.
- Muéstrame todos los eventos en los que una persona entró en un área restringida.
El VMS no necesita volver a analizar el video. Simplemente consulta los metadatos almacenados. Esto es mucho más rápido. En un sistema con 50 cámaras grabando 24/7, la diferencia entre volver a analizar el video y consultar metadatos es la diferencia entre horas y segundos.
Una dificultad del mundo real: la versión del firmware importa
Quiero señalar algo que sorprende a la gente. Incluso si un modelo de cámara dice “Perfil T” en la hoja de datos, la versión real del firmware importa. Las primeras versiones de firmware a veces tenían implementaciones incompletas del Perfil T. Los campos de metadatos podrían estar parcialmente poblados, o la sincronización de la marca de tiempo podría desviarse.
En Loyalty-Secu, realizamos una prueba de validación completa del Perfil T en cada versión de firmware antes de que se envíe. Verificamos que cada campo XML esté correctamente poblado, que las marcas de tiempo se alineen dentro de un fotograma y que los metadatos sobrevivan a la pérdida de paquetes en una conexión 4G. Si está evaluando alguna cámara, la nuestra o la de cualquier otra persona, solicite un informe de prueba de conformidad del Perfil T. Le ahorrará muchos problemas más adelante.
¿Está el flujo de metadatos perfectamente sincronizado con el video 4K de alta resolución?
Los problemas de sincronización son una pesadilla. He visto casos en los que el cuadro delimitador aparece dos segundos después de que la persona ya ha salido del fotograma. Eso hace que toda la función de IA sea inútil.
Según el Perfil T de ONVIF, el flujo de metadatos se sincroniza con el video H.265 utilizando marcas de tiempo NTP compartidas a nivel de fotograma. Esto significa que los datos del cuadro delimitador y el fotograma de video correspondiente llevan la misma referencia de tiempo, lo que garantiza una alineación precisa incluso en redes inestables como 4G LTE.
sincronización de metadatos flujo de video 4K H.265
Cómo funciona la sincronización a nivel de protocolo
La clave de la sincronización es la marca de tiempo RTP. Tanto el flujo de video como el flujo de metadatos utilizan RTP como su capa de transporte. Cada paquete RTP lleva una marca de tiempo derivada del reloj interno de la cámara. Cuando la cámara genera un fotograma de video y un paquete de metadatos para el mismo momento, ambos paquetes obtienen el mismo valor de marca de tiempo.
En el extremo receptor, el VMS compara estas marcas de tiempo. Sabe que el paquete de metadatos #4521 pertenece al fotograma de video #4521. Por lo tanto, dibuja el cuadro delimitador en el fotograma correcto.
¿Qué puede romper la sincronización?
En un entorno de laboratorio perfecto, la sincronización es impecable. Pero en el campo, varias cosas pueden causar desviaciones:
- Mala configuración de NTP. Si el reloj de la cámara no está sincronizado con un servidor NTP confiable, las marcas de tiempo pueden desviarse durante horas o días. Configure siempre NTP, incluso en implementaciones 4G. La mayoría de las redes celulares proporcionan acceso NTP.
- Jitter de red. En un enlace 4G, los paquetes pueden llegar desordenados. El VMS necesita un búfer de jitter7 para volver a ordenarlos. Si el búfer es demasiado pequeño, los metadatos y el video pueden aparecer desincronizados en la pantalla.
- Carga alta de CPU. Si el procesador de la cámara está sobrecargado —por ejemplo, ejecutando múltiples algoritmos de IA a resolución 4K— la generación de metadatos puede retrasarse con respecto al pipeline de codificación de video.
Consejos prácticos para sistemas PTZ solares 4G
Para nuestros clientes que implementan cámaras PTZ solares 4G en ubicaciones remotas, siempre recomiendo tres cosas para proteger la calidad de la sincronización:
Primero, configure el servidor NTP de la cámara en un grupo público como pool.ntp.org8 o la dirección NTP de su operador. Esto mantiene el reloj preciso.
Segundo, configure el búfer de jitter del VMS en al menos 200 ms. Esto le da al sistema suficiente espacio para reordenar los paquetes sin demora visible.
Tercero, si está ejecutando 4K a 25 fps con múltiples reglas de IA activas, considere reducir a 15 fps para la transmisión de análisis. La transmisión de video puede permanecer a 25 fps. Esto reduce la carga de la CPU y mantiene el pipeline de metadatos funcionando sin problemas.
El factor 4K
La resolución 4K hace que la sincronización sea más desafiante porque el volumen de datos es mucho mayor. Un solo fotograma H.265 4K puede tener 200 KB o más. El paquete de metadatos para ese fotograma puede tener solo 500 bytes. Si la red descarta el paquete de video y el VMS solicita una retransmisión, el paquete de metadatos ya está esperando en el búfer. El VMS necesita retener esos metadatos hasta que el video se ponga al día.
Es por eso que siempre les digo a nuestros socios: prueben su pipeline completo de extremo a extremo antes de implementarlo. Configure la cámara, conéctela a través de 4G, transmita H.265 4K con metadatos habilitados y observe la salida en su VMS durante al menos 24 horas. Si la sincronización se mantiene durante un día completo, se mantendrá en producción.
¿El uso de metadatos H.265 consume más potencia de procesamiento que H.264?
Cada integrador con el que hablo pregunta sobre la sobrecarga de procesamiento. Quieren IA y H.265, pero no quieren que la cámara se sobrecaliente o se congele en el campo.
La codificación H.265 requiere más potencia de procesamiento que H.264 —típicamente entre un 30% y un 50% más de carga de CPU para la misma resolución y velocidad de fotogramas—. Sin embargo, la generación de metadatos en sí misma agrega una sobrecarga mínima independientemente del códec. El costo real del procesamiento proviene del análisis de IA, no de empaquetar los resultados en metadatos ONVIF.
Potencia de procesamiento H.265 vs H.264 sobrecarga de metadatos
Desglose de la carga de procesamiento
Permítanme separar las tres tareas principales que ocurren dentro de la cámara:
- Codificación de video — convirtiendo datos brutos del sensor en H.264 o H.265 comprimidos.
- Análisis de IA — ejecutando modelos de redes neuronales para detectar personas, vehículos u otros objetos.
- Empaquetado de metadatos — encapsulando los resultados de IA en XML compatible con ONVIF y enviándolos a través de RTP.
La Tarea 1 es donde H.265 cuesta más que H.264. El algoritmo HEVC es más complejo. Utiliza unidades de árbol de codificación más grandes, más modos de predicción y codificación de entropía más avanzada. Todo esto requiere más ciclos de cómputo.
La Tarea 2 es la misma, independientemente de si usa H.264 o H.265. El modelo de IA se ejecuta en los fotogramas de video brutos o decodificados, no en la transmisión comprimida.
La Tarea 3 es trivial. Generar un pequeño paquete XML no consume casi tiempo de CPU.
Una comparación lado a lado
Aquí hay una comparación aproximada basada en nuestras pruebas internas en Loyalty-Secu, utilizando una cámara PTZ 4K típica con un chipset de IA integrado:
| Métrica | H.264 + Metadatos | H.265 + Metadatos | Diferencia |
|---|---|---|---|
| Uso de CPU de codificación de video | ~35% | ~50% | +15% |
| Uso de CPU de detección de IA | ~25% | ~25% | 0% |
| Uso de CPU de empaquetado de metadatos | ~1% | ~1% | 0% |
| Uso total de CPU | ~61% | ~76% | +15% |
| Tasa de bits (4K, 25 fps) | ~8 Mbps | ~4 Mbps | -50% |
| Ancho de banda de metadatos | ~50 kbps | ~50 kbps | 0% |
La conclusión es clara. H.265 cuesta más CPU pero ahorra mucho ancho de banda. La capa de metadatos es la misma en ambos casos.
¿Cuándo se convierte esto en un problema?
Para la mayoría de las cámaras modernas con codificadores de hardware dedicados (como Hi3559 o SoCs similares), la carga adicional de H.265 es manejada por el codificador de hardware, no por la CPU principal. Por lo tanto, en la práctica, el impacto en la CPU es mucho menor de lo que sugieren los números brutos.
Pero los problemas pueden aparecer en dos escenarios:
- Codificación de doble flujo. Si ejecuta tanto un flujo principal de 4K como un subflujo de 720p, ambos en H.265, el codificador de hardware está haciendo un doble trabajo. Agregue IA encima y podría alcanzar el límite.
- Alto recuento de objetos. Si la escena tiene más de 30 objetos en movimiento y la IA los está rastreando a todos, el motor de análisis, no el codificador, se convierte en el cuello de botella.
Mi recomendación para integradores de sistemas
Si está implementando en un entorno con ancho de banda limitado, como un sitio solar 4G, use H.265 para el flujo principal y H.264 para el subflujo. Esto equilibra la carga de procesamiento y al mismo tiempo le brinda el ahorro de ancho de banda en el flujo de grabación principal. Mantenga la detección de IA limitada a los objetos que realmente le importan, generalmente personas y vehículos. No habilite el seguimiento de “todos los objetos” a menos que realmente lo necesite.
Y siempre verifique la temperatura de funcionamiento de la cámara bajo carga completa. En Loyalty-Secu, cada unidad pasa por una prueba de resistencia de 48 horas a resolución máxima, velocidad de fotogramas máxima y IA completa habilitada. Si sobrevive a eso, sobrevivirá en el campo.
Conclusión
ONVIF Profile T admite completamente la transmisión de metadatos H.265. Verifique que tanto su cámara como su VMS admitan Profile T, y sus datos de IA fluirán de manera confiable, incluso a través de 4G.
1. Página oficial de ONVIF para Profile T, que define el soporte para H.265 y transmisión de metadatos. ︎↩︎ 2. Especificación del Protocolo de Transmisión en Tiempo Real (RTSP): se utiliza para transportar flujos de video y metadatos. ︎↩︎ 3. Especificación ONVIF para servicios de análisis, que define el esquema XML para metadatos de detección. ︎↩︎ 4. Milestone XProtect VMS: confirmado para admitir Profile T para búsqueda inteligente a través de metadatos. ︎↩︎ 5. Genetec Security Center VMS: admite Profile T para búsqueda de eventos basada en metadatos. ︎↩︎ 6. Nx Witness VMS: admite el Perfil T a partir de la v5.0 para la búsqueda inteligente de metadatos. ︎↩︎ 7. Explicación de Wikipedia sobre el búfer de fluctuación (jitter buffering): esencial para reordenar paquetes retrasados en enlaces 4G. ︎↩︎ 8. Se recomienda el grupo público de NTP para la sincronización del reloj de la cámara en implementaciones remotas. ︎↩︎