Integración de camaras RTSP en directo con servicios WebRTC para administraciones públicas

Probablemente lo primero de lo que hay que preocuparse cuando integras una camara IP con una aplicación WebRTC es la compatibilidad de codecs entre el emisor y el receptor.

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

Pero en la realidad no todo es tan sencillo ya que aunque en teoría se podría conectar una camara 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 codec H264.

Contexto

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

Al final aunque OpenVidu y Kurento (asi 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 sutiles elementos (y no tan sutiles) que impiden un trasiego directo usando Kurento (u otros media server), como son el contenedor del ts, o el propio codec (H264/H265, level, profile, etc.)

El proyecto

Debido a esta variabilidad en los tipos de camaras y por tanto en los codecs  utiliza OpenVidu PRO para manejar la multiplexación de los flujos y la transcodificación por medio de Kurento pero con la simplicidad de un 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 relativo al trasiego de media esta compuesto por 3 fases:

1. Análisis de los flujos de video.
2. Desarrollo de una solución a medida.
3. Despligue, integración, test y ajustes de la solución a medida.

Fase 1.

Objetivo: Obtención de una información precisa sobre que parámetros de cada flujo de video hace que dicho flujo pueda visualizarse sin errores, con errores o no visualizarse en ningún caso.

Mediante un análisis intensivo de multiples flujos de video de camaras reales de la plataforma encontramos diversos parámetros que afectaban a su visualización adecuada. Casi todos relacionados con los codecs, ya que aunque la mayor parte de las camaras eran H264 los niveles utilizados y parámetros eran muy variables. Puedes consultar la información aquí.

Fase 2.

Objetivos:

  • Visualizar las camaras que no se veían
  • Corregir la calidad de imagen de camaras 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 video y comparalo con resultados anteriores y saber que debe suceder a dicho flujo de video. Además este componente debería tener la posibilidad de ser «harcodeado» de forma que el cliente pudiera forzar a que un flujo de video independientemente del resultado de la evaluación del discriminador un comportamiento u otro.

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

Fase 3.

Objetivos:

  • Desplegar la sulució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 carácterísticas principales de los videos 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 permite identificar  automáticamente si un flujo de video 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 video que se estime que no se van a ver o se van a ver con errores.
  • Dar soporte para la gestion de la arquitectura general de la aplicación y al desarrollo en el uso de OpenVidu PRO.

Tecnologias

Todo trasiego de media esta sujeto a multiples parámetros y variables (calidad de red, codecs, contenedores, resolución, fps, etc.) y cuando hablamos de miles de cámaras hablamos de cientos de combinaciones posibles, automatizar y preveer el comportamiento según estos parámetros es esencial para gestionar una plataforma de videovigilancia en tiempo real.

Conclusión y lecciones aprendidas

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

En un proyecto como este donde 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 auditar el código de estos componentes OpenSource.

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