VideoWall de vigilancia con OpenVidu (parte 2)

Hablamos de los últimos 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 cámaras con errores o sin vídeo.
• Pantallas grises.
• Códecs incompatibles.

Persistencia de cámaras con errores o sin vídeo

Después de la inclusión de OpenVidu PRO pasamos de tener muchas cámaras (>60%) con errores o que no se visualizaban 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 vídeo para detectar sus características concretas y compararlas con las definiciones de compatibilidad de códecs de Kurento. Y encontramos que las cámaras que no se ven tienen muchas veces estas características (obtenidas con ffprobe):

Códec 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 navegadores más utilizados, es compatible con H264, pero si rebuscamos un poco más vemos que el códec H264 tiene muchas propiedades, entre ellas el "profile", que indica tipos de compresión y propiedades adicionales. Además, también encontraremos que H264 no es un códec libre (es decir, tiene royalties) y por tanto la mayoría de navegadores, proyectos OpenSource y otros tipos de software solo disponen de compatibilidad con los perfiles más básicos. Así que cuando pasamos a Medium o High es posible que Kurento o el propio navegador 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 un 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 cuál es la transcodificación adecuada para un flujo de vídeo (si es necesario). El objetivo de este discriminador/transcodificador es proporcionar flujos de vídeo compatibles con Kurento pero intentando encontrar el proceso más ligero posible.

Pantallas grises

Estas imágenes 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 vídeo.

En la imagen vemos que existen fotogramas 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 píxeles que han cambiado. De esta forma limitamos la cantidad de información emitida.

¿Qué pasa cuando reproducimos el flujo?

También de forma muy simplificada: cuando recibimos un cuadro I "se pinta", y después 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 tienen, que generalmente será una imagen gris con unos pocos píxeles distintos; esta pantalla gris desaparecerá cuando haya muchas diferencias acumuladas 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 cámara (al códec) a enviar frames I mucho más frecuentemente, pero esto tiene implicaciones, ya que la compresión del vídeo será mucho menor y requerirá mucho más ancho de banda.

Códecs incompatibles

Además de los retos anteriormente comentados, también se encontró un porcentaje muy bajo de cámaras con códecs completamente incompatibles y que requerirían una transcodificación bastante potente. Todas estas cámaras incompatibles emitían en H265, además con muy alta resolución.

El códec H265 no se encuentra dentro de la lista de compatibilidades actual de WebRTC y, por tanto, la mayor parte de los navegadores y Kurento no son compatibles con él. 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, sin poder recuperarse. 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 códec H265 llegue a Kurento, interceptándolo y bien transcodificando o dando error. Ya que estos flujos, en nuestro caso, son flujos con muy altas resoluciones, la transcodificación de este mínimo porcentaje 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 tránsito del media. En este proyecto estamos hablando de un conjunto de más de 1000 cámaras 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 cámaras RTSP en directo con servicios WebRTC para administraciones públicas.