VideoWall de vigilancia con OpenVidu (parte 1)
Hoy hablamos de un proyecto que conceptualmente era bueno y «sencillo», pero que una vez en producción nos supone varios retos.
Si disponemos de un montón de cámaras de vigilancia IP en una ciudad, y sabemos su localización GPS, es en principio «fácil» desarrollar una aplicación web que nos muestre las N cámaras más cercanas a una posición GPS. Pero cuando hablamos de media delivery siempre hay pequeños detalles que pueden complicarnos la vida.
Las cámaras
Este proyecto se basa en un pool de más de mil cámaras IP desplegadas a lo largo y ancho de una ciudad. Estas cámaras son de la propia ciudad y de ciudadanos y negocios que han dado permiso al usuario final para que pueda consumir sus flujos. Estas cámaras, por ende, son de muy diversa naturaleza (modelo, marca, códecs, ancho de banda disponible…). Para más inri, estos parámetros en muchas de las cámaras son completamente desconocidos a priori.
El proyecto tendrá que soportar el máximo de cámaras disponibles en el mercado, y para el resto debe definirse bien la incompatibilidad, para que por ejemplo un códec incompatible no tire la plataforma.
Los retos de distribución multimedia
Nos centraremos en los retos de la distribución de media, ya que el resto de los retos que puede suponer manejar cámaras públicas (seguridad, volumen, privacidad, etc.), así como los retos de crear una buena interfaz, estaban bajo control y perfectamente abordados por nuestro cliente.
- Acceso concurrente a flujos de media
- Compatibilidad de códecs
Acceso concurrente a los flujos de media
Algo que muchas veces se nos pasa por alto es que para transmitir media desde una cámara se debe abrir al menos un túnel de comunicaciones para cada cliente/usuario conectado a dicha cámara. Esto implica que, en caso de que haya 10 clientes/usuarios intentando obtener el flujo de una cámara, esta cámara tendrá que ser capaz de tener 10 túneles abiertos y de enviar el media por esos 10 túneles. Esto de por sí ya es complejo, y la mayor parte de las cámaras del mercado no soportan tantos flujos concurrentes. Pero, lo que es más, estos 10 túneles están utilizando el mismo ancho de banda, por lo que la probabilidad de pérdidas de paquetes, retardos, etc. se multiplica por 10. Lo que supone un serio problema, por ejemplo, si hablamos de cámaras wifi sobre redes domésticas, o GPRS.
Uno de los principales problemas con este tipo de fallos es que muchas veces se detectan una vez el software se pone en producción, ya que funcionalmente no tiene grandes implicaciones hasta que no existen varios usuarios concurrentes. (Porque cuando no tienes en cuenta que la concurrencia puede ser un problema en media tampoco vas a pensar en añadirlo a las pruebas).
Solución
La solución es relativamente sencilla: utilizar un servidor multimedia que sea capaz de multiplexar las señales de las cámaras. Este servidor multimedia deberá estar ubicado en una máquina que ofrezca buena capacidad de proceso, pero sobre todo un buen ancho de banda. De esta forma la cámara solo emitirá un flujo de media, y será nuestro servidor quien haga la multiplexación para cada cliente, es decir, mantenga los diferentes túneles por los que hará llegar el media a cada cliente.
Compatibilidad de códecs
Como hemos dicho, las cámaras de este proyecto son muchas y muy diversas, y soportar absolutamente todas las configuraciones es muy complicado y costoso. Para empezar, sabemos que la aplicación es una aplicación web. Los navegadores tienen una compatibilidad limitada para códecs de vídeo. Y por tanto, en muchos casos, no se puede mostrar directamente el flujo de una cámara en el navegador, sino que tenemos que transcodificarlo ("traducirlo") a un códec que entienda el navegador. Este proceso de transcodificación es caro a nivel de CPU, por lo que la mayoría de las cámaras no son capaces de realizarlo, y simplemente son capaces de enviar los flujos con un códec preestablecido (algunas veces configurable dentro de un rango de códecs).
Solución
En este caso, la solución también pasa por utilizar un servidor o proxy que sea capaz de realizar la transcodificación para que el cliente/usuario reciba en su navegador un flujo de vídeo que pueda visualizar. Debido a que el proceso de transcodificación es "caro", como se ha explicado anteriormente, la máquina que aloje el servidor deberá disponer de una capacidad de procesamiento adecuada al número de flujos simultáneos que puedan existir.
LA SOLUCIÓN
Kurento fue la primera elección para abarcar este proyecto, ya que encaja al 100% con el caso de uso (multiplexación de flujos y transcodificación transparente). Aunque tiene unas desventajas:
- No es fácil de escalar (manejar un clúster de Kurento no es sencillo).
- Requiere un conocimiento de los componentes de Kurento bastante profundo para optimizar su funcionamiento, y desarrollo Java específico para gestionar los pipelines de Kurento (para añadir en caliente webrtc-endpoints cada vez que se conecte un usuario).
Desde Naeva Tec se propuso el uso de OpenVidu PRO, ya que este corre sobre Kurento pero (i) es capaz de manejar clústeres de Kurento de forma transparente para la aplicación cliente y (ii) simplifica el manejo de los flujos de media, ya que proporciona un API sencilla por la que se pueden gestionar todos los parámetros necesarios de Kurento para este caso de uso.
De forma que, al final, lo que se tenía era una sesión de OpenVidu para cada cámara, y los usuarios que querían visualizar una cámara lo que realmente estaban haciendo (de forma transparente) era unirse a la sesión de OpenVidu que estaba sirviendo esa cámara. Con la introducción de OpenVidu PRO, las modificaciones necesarias del código original fueron mínimas, pero el impacto en el uso fue muy grande.
Aunque no todo lo que reluce es oro, ya que surgieron nuevos retos relacionados con la calidad del vídeo mostrado. Ver la parte 2.