VideoWall de vigilancia con OpenVidu (parte 2)

Hablamos de los ultimos retos que se presentaron en el proyecto de Renacen del VideoWall. Hasta ahora hemos resuelto los retos de concurrencia y parcialmente la transcodificación pero… Puedes leer la primera parte aquí

Retos resueltos con OpenVidu PRO:
  • Concurrencia de usuarios
  • Transcodificación
Nuevos retos:
  • Persistencia de camaras con errores o sin video.
  • Pantallas grises
  • Codecs incompatibles

Persistencia de camaras con errores o sin video

Después de la inclusión de OpenVidu PRO pasamos de tener muchas cámaras (>60%) con errores o que no se visualizan a unas cuantas (~30%). Obviamente en un sistema de videovigilancia este porcentaje es todavía muy alto. De estas cámaras aproximadamente un tercio no se visualizan y el resto se visualizan con errores. Puesto que ya tenemos un sistema de transcodificación (Kurento) tenemos que revisar los flujos de video para detectar sus características concretas y compararlas con las definiciones de compatibilidad de codecs de Kurento. Y encontramos que las cámaras que no se ven tienen muchas estas características (obtenidas con un ffprobe)

Codec H264

index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=Main
codec_type=video
codec_time_base=1/20
[...]

o

index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=High
codec_type=video
codec_time_base=1/20
[...]

Buscando un poco vemos que Kurento, al igual que los browsers más utilizados son compatibles con H264, pero si rebuscamos un poco más vemos que el codec H264 tienen muchas propiedades entre ellas el profile que indica unos tipos de compresión y propiedades adicionales. Además también encontraremos que H264 no es un codec libre (es decir tiene royalties) y portanto la mayoria de browsers, proyectos OpenSource y otros tipos de software disponen solo de compatibilidad con los profiles más básicos. Así que cuando pasamos a Medium o High es posible que Kurento o el propio browser no sean capaces de entender todos los frames dando como resultado una mala calidad, pixelado, cuadros verdes o incluso que no se visualice nada.

Solución

De forma que para poder visualizar estos flujos correctamente necesitamos una paso de transcodificación extra. Pero que solo se aplique a los flujos para los que realmente sea necesario.

Para ello diseñamos un componente que discrimina los flujos según sus características y decide cual es la transcodificación adecuada para un flujo de video (si es necesario). El objetivo de este discriminador/transcodificador es proporcionar flujos de video compatibles con Kurento pero intentando encontrar el proceso más ligero posible.

 

Pantallas grises

Estas imagenes grises generalmente se dan al inicio de una conexión y pueden ser una molestia para el usuario pero no son un problema multimedia realmente. Se deben a la compresión de datos dentro de los flujos de video.

En la imagen vemos que existen frames/cuadros de tipo I, B y P. Simplificando al máximo los cuadros I disponen de toda la información es decir son una «foto» una imagen completa, mientras que los cuadros P y B son diferencias entre cuadros. Es decir contienen solo los pixeles que han cambiado. De esta forma limitamos la cantidad de información emitida.

¿Que pasa cuando reproducimos el flujo?

También de forma muy simplificadada,  cuando recibimos un cuadro I «se pinta» y despues se van pintando las diferencias, hasta que llega de nuevo un cuadro I que se vuelve a pintar entero (corrigiendo los posibles errores que se hubieran acumulado). Pero si el primer cuadro que llega no es un cuadro I los diferentes reproductores pueden o bien esperar al siguiente cuadro I, lo que añade latencia en la conexión, o pintar la información que tiene que generalmente será una imagen gris con unos pocos pixeles distintos, esta pantalla gris desaparecerá cuando haya muchas diferencias o cuando llegue un cuadro I.

¿Se puede resolver el problema?

En este caso transcodificar no va a mejorar la solución ni ningún componente intermedio. La forma de solucionarlo podría aplicarse en la raíz forzando a la camara (al codec) a enviar frames I mucho más frecuentemente, pero esto tiene implicaciones ya que la compresión del video será mucho menor y requerirá mucho más ancho de banda.

Codecs incompatibles

Además de los retos anteriormente comentados tambien se encontró un % muy bajo de camaras con codecs completamente incompatibles y que requerirían una transcodificación bastante potente. Todas estas cámaras incompatibles son H265 que además emitían con muy alta resolución.

El codec H265 no se encuentra dentro de la lista de compatibilidades actual de WebRTC y por tanto la mayor parte de los browsers y Kurento no son compatibles. Es más hemos detectado que Kurento en el caso de recibir un flujo H265 es capaz de procesarlo, pero al parar el flujo Kurento entra en un estado inconsistente y deja de funcionar correctamente para dicho flujo y todos los demás. Esto supone un caso de fallo crítico (aunque poco frecuente).

La solución

La solución es simple, no permitir que ningún flujo con codec H265 llege a Kurento interceptandolo y bien o transcodificando o dando error. Ya que estos flujos en nuestro caso son flujos con muy altas resoluciones la transcodificación de este mínimo % de flujos podría afectar a la visualización correcta del resto. Por lo tanto utilizando el componente discriminador se han interceptado los flujos indicando un error específico, de forma que los flujos nunca serán enviados a Kurento.

Conclusión

El mundo del delivery de multimedia es muy complejo existen muchas variables que van a afectar al trasiego del media. En este proyecto que estamos hablando de un conjunto de más de 1000 camaras y donde no es posible en muchos casos conocer sus configuraciones y capacidades antes de su integración en producción. El análisis de flujos de muestra y el desarrollo de una solución configurable y extensible «en caliente» ha sido nuestro objetivo.

Puedes leer más de nuestro proyecto con Renacen en Integración de camaras RTSP en directo con servicios WebRTC para administraciones públicas