Integración de cámaras RTSP en directo con servicios WebRTC para administraciones públicas

Por ello la especificación de WebRTC es muy clara al respecto y define que cualquier implementación de WebRTC debe ser compatible con VP8 y H264. Así que visualizar cualquier flujo de una cámara IP, que en su mayoría implementan el protocolo H264, no debería suponer ningún problema…

Pero en la realidad no todo es tan sencillo, ya que aunque en teoría se podría conectar una cámara RTSP directamente con un navegador, existen bastantes cosas que tener en cuenta. En este post de Kurento se explica muy bien: https://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras

Y además de todo lo explicado en dicho post, existen otros problemas que se pueden dar relativos al soporte real del códec H264.

Contexto

El proyecto de Renacen consiste en crear una plataforma web para visualizar más de mil cámaras IP de vigilancia en tiempo real. Estas cámaras son de diversos modelos, con diferentes propiedades, y sus capacidades de red son también muy dispares. Estas cámaras son propiedad principalmente del usuario final, aunque existe un porcentaje no despreciable de cámaras propiedad de terceros que hacen accesible sus flujos de media al usuario final.

Al final, aunque OpenVidu y Kurento (así como los navegadores web) ofrecen compatibilidad con H264, la realidad es que existe un alto porcentaje de cámaras que no se logran ver adecuadamente. Algunas cámaras no llegan a reproducirse y otras se reproducen con muchos errores, ya que hay elementos sutiles (y no tan sutiles) que impiden un trasiego directo usando Kurento (u otros media servers), como son el contenedor, o el propio códec (H264/H265, level, profile, etc.).

El proyecto

Debido a esta variabilidad en los tipos de cámaras y, por tanto, en los códecs, se utiliza OpenVidu PRO para manejar la multiplexación de los flujos y la transcodificación por medio de Kurento, pero con la simplicidad de una API REST.

Pero para esos flujos de media con errores o que no se visualizan es necesario crear unos componentes adicionales que transformen los flujos incompatibles en flujos que Kurento/OpenVidu puedan renderizar.

La parte del proyecto relativa al trasiego de media está compuesta por 3 fases:

1. Análisis de los flujos de vídeo.
2. Desarrollo de una solución a medida.
3. Despliegue, integración, test y ajustes de la solución a medida.

Fase 1

Objetivo: Obtención de una información precisa sobre qué parámetros de cada flujo de vídeo hacen que dicho flujo pueda visualizarse sin errores, con errores, o no visualizarse en ningún caso.

Mediante un análisis intensivo de múltiples flujos de vídeo de cámaras reales de la plataforma, encontramos diversos parámetros que afectaban a su visualización adecuada. Casi todos relacionados con los códecs, ya que, aunque la mayor parte de las cámaras eran H264, los niveles utilizados y parámetros eran muy variables. Puedes consultar la información aquí.

Fase 2

Objetivos:

• Visualizar las cámaras que no se veían.
• Corregir la calidad de imagen de cámaras cuya visualización tenía errores (pantallas verdes, grises, pixelado excesivo, etc.).
• No hacer nada sobre los flujos que se visualizan adecuadamente.

Para conseguir estos objetivos es necesario pensar en 2 funcionalidades principales:

1. Discriminar los flujos que necesitan alguna actuación.
2. Realizar las transformaciones (transcodificación, reencapsulación, etc.) sobre los flujos incorrectos (no visualizables o visualizables con errores).

El discriminador de flujos debe ser capaz de obtener los datos de los flujos de vídeo y compararlos con resultados anteriores, sabiendo qué debe suceder con dicho flujo de vídeo. Además, este componente debería tener la posibilidad de ser "hardcodeado" de forma que el cliente pudiera forzar, independientemente del resultado de la evaluación del discriminador, un comportamiento u otro para un flujo de vídeo concreto.

El componente de transformación debería recibir el flujo original y la acción a realizar, y proveer un nuevo flujo transformado, es decir, ser un proxy del flujo original.

Fase 3

Objetivos:

• Desplegar la solución a medida para que soporte la carga de trabajo esperada.
• Validar la integración de la solución con la plataforma del cliente.
• Crear las reglas para que el discriminador tome la decisión adecuada dependiendo de cada tipo de flujo.

Nuestro papel

Nuestra labor dentro del proyecto como especialistas en media ha sido principalmente:

• Encontrar las características principales de los vídeos que no se visualizaban o se visualizaban con errores, y encontrar la transformación adecuada.
• Hacer un estudio de las tecnologías y las herramientas disponibles para realizar la transformación de los flujos.
• Desarrollar un componente con un impacto mínimo sobre la solución existente que permita identificar automáticamente si un flujo de vídeo se va a ver correctamente en la plataforma o si hay que realizar una transformación previa.
• Realizar un transformador en tiempo real solo para los flujos de vídeo que se estime que no se van a ver o se van a ver con errores.
• Dar soporte para la gestión de la arquitectura general de la aplicación y para el desarrollo en el uso de OpenVidu PRO.

Tecnologías

Todo trasiego de media está sujeto a múltiples parámetros y variables (calidad de red, códecs, contenedores, resolución, fps, etc.), y cuando hablamos de miles de cámaras hablamos de cientos de combinaciones posibles. Automatizar y prever el comportamiento según estos parámetros es esencial para gestionar una plataforma de videovigilancia en tiempo real a gran escala.

Conclusión y lecciones aprendidas

Este proyecto nos ha obligado a aplicar todo nuestro conocimiento de media delivery y transcodificación al detalle, teniendo que analizar decenas de vídeos para encontrar los parámetros que hacían que un flujo de vídeo se pudiera visualizar correctamente y otros no. Y utilizando nuestras conclusiones para inferir el comportamiento de flujos de vídeo que no entraban dentro del análisis inicial. Y más allá de eso, encontrar para cada grupo de comportamientos y parámetros cuál era la transformación necesaria para que cada tipo de vídeo se renderizara adecuadamente. Esto ha supuesto muchas horas de prueba y error, y de ajustar pequeños parámetros para encontrar la mejor visualización posible.

En un proyecto como este, en el que se ha trabajado a contrarreloj, ha sido clave encontrar tecnologías y componentes OpenSource que nos permitieran avanzar rápido, pero con la garantía de conocer los detalles del código y la seguridad de poder auditarlo.

Trabajar en equipo con una compañía como Renacen, que tiene una gran experiencia en desarrollos innovadores, ha sido un placer. Su conocimiento de un gran espectro de tecnologías y la estupenda arquitectura de la plataforma web han hecho muy fácil la integración. Y el trabajo mano a mano con su equipo de desarrollo nos ha facilitado mucho las cosas.