Desde los primeros días de trabajo en un sistema de videovigilancia basado en la nube, encontramos un problema sin el cual era posible poner fin a Ivideon: era nuestro Everest, escalarlo tomó mucha energía, pero ahora finalmente clavamos un piolet en la corona del rebus multiplataforma.
El sistema para transmitir sonido y video a través de Internet no debe depender de los equipos, los clientes web y los estándares que admiten, y también debe funcionar correctamente con los traductores de dirección de red y los firewalls. El usuario de videovigilancia en la nube quiere acceder al servicio, incluso si usa cámaras analógicas, y prefiere ver transmisiones de video en vivo en el dispositivo más moderno.
Es muy significativo que el usuario quiera ver el video con un retraso mínimo. Casi la única forma de mostrar videos de baja latencia en un navegador es usar WebRTC (comunicaciones web en tiempo real). WebRTC es un conjunto de tecnologías para la transmisión de video y audio entre pares en navegadores, originalmente diseñado para transmitir y reproducir una transmisión de video con baja latencia. Para esto, entre otras cosas, se utiliza el protocolo UDP.
Antes de decirle lo que el nuevo motor le da al usuario, le recordaremos por qué y por qué apoyamos las tecnologías HLS, y para qué decidimos seguir adelante.
Motor HLS: pros y contras
(
c )
La tecnología HLS (HTTP Live Streaming) fue desarrollada por Apple, por lo que no sorprende que por primera vez su soporte apareciera en dispositivos de esta marca en particular. Hasta la fecha, casi todos los decodificadores de televisión y muchos dispositivos que se ejecutan en el sistema operativo Android también pueden reproducir imágenes en formato HLS.
El motor HLS utiliza el conocido códec de video H264 en combinación con transmisiones de audio AAC o MP3 para la transmisión de video. Todo el flujo de audio y video está empaquetado en un contenedor de transporte MPEG-TS. Para la transmisión a través de HTTP, la información contenida en la transmisión se divide en fragmentos descritos en las listas de reproducción m3u8. Y solo entonces, estos fragmentos, junto con las listas de reproducción, se transmiten a través de HTTP. Dividir en fragmentos automáticamente significa un retraso en segundos. Tal característica del contenedor MPEG-TS.
El motor HLS también admite transmisiones multibit, Live / VOD.
Las principales ventajas de HLS:- soporte integrado en todos los principales navegadores;
- facilidad de implementación (en comparación con WebRTC);
- Es muy conveniente y eficiente organizar todo tipo de transmisiones para una gran audiencia debido al hecho de que los segmentos se pueden cargar en una CDN una vez.
Por toda la simplicidad del motor, no todo es tan suave como parece. El principal problema es que los desarrolladores de reproductores de terceros se han alejado de las recomendaciones de Apple, por ejemplo, en términos de formatos de audio compatibles. En particular, muchos desarrolladores comenzaron a agregar la capacidad de trabajar con transmisiones de audio populares: video mpeg2, audio mpeg2, etc. Como resultado, tuvimos que crear diferentes formatos de listas de reproducción para diferentes reproductores.
Pero uno de los mayores problemas con el motor HLS es la alta latencia en la transferencia de datos.
Los orígenes de los "frenos"
La razón principal del alto retraso en HLS radica en el hecho de que los programadores crearon un motor para obtener la mejor calidad de imagen. Por lo tanto, los parámetros del intervalo de cuadro utilizado y el tamaño del búfer de reproducción simplemente no son adecuados para realizar transmisiones de video en vivo. Debido a esto, se produce un retraso bastante alto en la transmisión de la secuencia de video, que puede ser de 5 a 7 segundos.
Por un lado, esto es un poco, por ejemplo, para aquellos que miran una película desde un servidor de alojamiento de video. Pero para los sistemas de videovigilancia, la demora en la transmisión de imágenes puede ser muy importante.
Si está observando una oficina donde los empleados salen de los monitores una vez por hora, no importa un retraso de 5 segundos. Pero la gente comenzó a quejarse de que, por ejemplo, cuando transmitía un partido de fútbol, GOOOOOOL ya estaba escrito en el chat, pero esto no está en el video :). Ya tenemos varios casos personalizados en los que Ivideon casi debería reemplazar a Skype.
¿Es posible vencer el retraso en HLS? La respuesta a esta pregunta suena como un discurso de un luchador de ratas experimentado en una conferencia ante disruptores novatos: "Las ratas no pueden ser exterminadas, pero su número puede reducirse a un mínimo razonable". Entonces, con un retraso en HLS, eliminarlo a cero no funcionará, pero hay soluciones en el mercado que pueden reducir significativamente el retraso.
Corte superficial
Otra desventaja del motor es el uso de archivos de pequeño tamaño para la transferencia de datos. Parece que esto es malo?
Cualquiera que haya intentado copiar una gran cantidad de archivos pequeños de un medio a otro, probablemente notó que la velocidad de escritura de un conjunto de este tipo es mucho menor que un archivo grande del mismo tamaño. Sí, y la intensidad de acceso al disco duro aumenta significativamente, lo que generalmente afecta negativamente el rendimiento de toda la computadora. Por lo tanto, la transmisión de datos de video en forma de pequeños fragmentos de 10 segundos también contribuye al aumento del retraso del motor.
Resuma brevemente todos los pros y los contras de la tecnología HLS.
Ventajas de HLS:- Posibilidad de trabajar con cualquier dispositivo. Puede ver videos en cualquier dispositivo moderno, ya sea un teléfono inteligente, tableta, computadora portátil o PC de escritorio. Lo principal es que el navegador web está actualizado y es compatible con HTML5 y las extensiones de fuente de medios.
- Gran calidad de imagen. La función de transferencia de datos adaptativa utilizada le permite cambiar dinámicamente la calidad de la secuencia de video transmitida dependiendo del ancho de banda de la conexión a Internet, mientras que el algoritmo busca mantener la máxima calidad.
- No hay necesidad de configuraciones complejas de equipos de usuario.
Desventajas- Soporte limitado para trabajar con el motor en algunos dispositivos.
- Altos retrasos en la transmisión de imágenes.
- Fuerte aumento de los gastos generales y la complejidad de la optimización debido al uso de archivos pequeños. Debido a la naturaleza del contenedor, nunca podemos obtener un retraso menor que el tamaño del segmento.
Las desventajas de HLS superaron sus ventajas para nosotros y nos obligaron a buscar opciones alternativas.
¿Qué es WebRTC?
(
c )
WebRTC fue desarrollado por Google en 2011 para transmitir video y audio entre navegadores y aplicaciones móviles con latencia mínima. Para esto, se utilizan el protocolo UDP estándar y algoritmos especiales de control de flujo. Hoy es un proyecto de código abierto, está activamente respaldado por Google y se está desarrollando.
WebRTC es un conjunto de tecnologías para la transmisión punto a punto de video y sonido. Es decir, por ejemplo, los navegadores de usuarios que usan WebRTC pueden transferir datos entre ellos directamente, sin usar servidores remotos para almacenar y procesar datos. Toda la información también es procesada por navegadores y aplicaciones móviles de usuarios finales.
Los desarrolladores de todos los navegadores populares apreciaron la conveniencia y las excelentes capacidades de esta tecnología. Actualmente, el soporte WebRTC se implementa en Mozilla Firefox, Opera, Google Chrome (y todos los navegadores basados en Chromium), así como en aplicaciones móviles para Android e iOS.
Con todas sus ventajas indudables, WebRTC tiene varias desventajas significativas.
Dificultad para elegir
WebRTC es mucho más complejo en términos de redes porque se trata de P2P. Es difícil de depurar, probar, puede comportarse de manera impredecible. En este caso, necesitamos superar NAT y firewall, necesitamos proporcionar trabajo en redes donde UDP está bloqueado.
La implementación de WebRTC de Google es muy difícil de usar. Incluso hay una compañía completa que brinda servicios de ensamblaje de SDK. Además, la implementación de Google fue muy difícil de integrar con nuestro sistema, por lo que no transcodificó todos los videos.
Sin embargo, durante mucho tiempo hemos querido dar a los usuarios la oportunidad de trabajar con una secuencia de video "en vivo" completa y minimizar el retraso de la imagen en la pantalla de los eventos mismos. Además, teníamos el deseo de hacer que el uso de cámaras PTZ fuera más cómodo, donde los retrasos son críticos.
Dado que otras implementaciones de la lucha contra los retrasos hasta ahora tienen una funcionalidad limitada y funcionan notablemente peor, decidimos usar WebRTC.
Que hemos hecho
Implementar adecuadamente la plataforma WebRTC no es una tarea fácil. Cualquier error de cálculo o inexactitud puede llevar al hecho de que los retrasos en la transmisión de secuencias de video no solo disminuyen en comparación con otras plataformas, sino que también aumentan.
Para que WebRTC funcione correctamente, en primer lugar, es necesario llevar a cabo una modernización tecnológica de la pila para trabajar con video web. Lo cual hicimos.
Primero, implementamos el servidor de protocolo de señalización WebRTC en la parte superior de Websocket, y también implementamos el servidor par WebRTC en la nube basado en el SDK webrtc.org. Su tarea es distribuir transmisiones de video a los pares del cliente WebRTC en el formato H.264 + Opus / G.711 sin transcodificación de video.
Elegimos Websocket como protocolo de señalización porque ya tiene soporte de calidad en todos los navegadores web populares. Debido a esto, es posible reducir significativamente no solo la sobrecarga de desarrollo, sino también no perder tiempo y recursos en el protocolo de enlace TCP y TLS repetido en comparación con AJAX.
El hecho es que, por defecto, WebRTC no proporciona el protocolo de señalización necesario para la configuración, el soporte y la interrupción adecuados de las comunicaciones de video en tiempo real entre las aplicaciones de origen y de cliente.
Y para implementar de manera independiente la tecnología de señalización, necesitábamos desarrollar nuestro propio servidor de señal con soporte para varios protocolos web (Websocet, WebRTC). Y también con la capacidad de gestionar de forma segura las sesiones y notificaciones en tiempo real, la gestión de video y muchos otros parámetros.
Superamos las limitaciones de P2P al reducir el retraso no debido a P2P, sino debido a UDP y al control de flujo destinado a reducir el retraso. Esto también está integrado en WebRTC, ya que el caso de uso principal son las conversaciones p2p a través del navegador.
En el cliente móvil, implementamos el reproductor usando el SDK de webrtc.org, porque solo en él el control de flujo se implementa correctamente, hay todos los esquemas conocidos de Corrección de errores de reenvío (FEC), y el mecanismo para reenviar paquetes para todos los navegadores se implementa correctamente. También es importante que el SDK webrtc.org sea desarrollado activamente por Google.
¿Cuál es el resultado de implementar WebRTC?
Para ver videos en vivo desde cámaras, agregamos un nuevo reproductor optimizado basado en WebRTC a nuestra cuenta. Proporciona secuencias de video de alta velocidad y elimina por completo el problema de la acumulación de retraso a medida que aumenta el tiempo de visualización.
Después de implementar el soporte WebRTC en el servicio en la nube Ivideon, podemos decir con confianza que ahora nuestros clientes pueden ver videos en vivo completos. ¡Ahora el retraso en la transmisión de imágenes no excede un segundo! A modo de comparación, el motor HLS anterior proporcionó la entrega de video con un retraso de 5-7 segundos. La diferencia en la velocidad de la demostración de video es muy significativa, y el usuario lo notará inmediatamente después de comenzar a trabajar con nuestro servicio de video.
Como esperábamos, la implementación del nuevo reproductor mejoró la capacidad de respuesta de PTZ y la comunicación de voz con la cámara.
Solo hay un punto sutil sobre el que queremos llamar la atención. El nuevo reproductor WebRTC todavía está en modo de prueba. Y es por eso que no lo conectamos a todos nuestros clientes por defecto. Pero puede activarlo usted mismo habilitando el elemento correspondiente en la configuración de la cámara (para esto debe ir a su
cuenta personal ).
Características de la implementación de WebRTC en el servicio Ivideon
Actualmente, WebRTC sigue siendo una tecnología experimental. Su soporte aún no se ha implementado correctamente en todos los navegadores y dispositivos de usuario, y tampoco en todas las cámaras.
Esto explica el hecho de que todavía no hemos hecho que el reproductor WebRTC sea el predeterminado por defecto para todos los usuarios.
Por ahora, recomendamos usar WebRTC solo en los navegadores Google Chrome. Las versiones recientes de Firefox y Safari también son compatibles con esta tecnología, pero, desafortunadamente, aún son inestables.
Todavía no hemos implementado el soporte WebRTC para navegadores en dispositivos móviles. Ahora, si inicia sesión desde un dispositivo móvil y activa WebRTC, este modo no funcionará. Sin embargo, WebRTC está en nuestras aplicaciones móviles para
Android e
iOS .
Y al concluir la historia sobre las características de la implementación de WebRTC en nuestro servicio, observamos dos puntos más sutiles.
En primer lugar, la tecnología se centra en transmitir video en vivo en tiempo real. Por lo tanto, si el ancho de banda de su canal no es suficiente para la transmisión de video, notará una caída en los cuadros (con HLS, notará un desvanecimiento de video y un aumento en el retraso, mientras que los cuadros no se caerán), pero el video aún se transmitirá en tiempo real.
En segundo lugar, dado que la tecnología está diseñada para trabajar con video en vivo en tiempo real, no la usamos para trabajar con datos de video archivados.
Otros cambios de servicio
Flash ya no participa en el mecanismo de selección automática del motor. Todavía puede usar dicho reproductor, pero para esto debe seleccionarlo manualmente en la configuración de la cuenta o la cámara. Esto no es una moda, solo según las estadísticas de nuestro servicio de usuarios que trabajan con Flash, prácticamente no hay más. Y en un intento por determinar si el navegador del usuario lo admite, perdemos unos 2 segundos de tiempo precioso.
Aquí hay un breve resumen de los cambios que le esperan en nuestro sistema de videovigilancia basado en la nube y en nuestra cuenta personal. ¡Estén atentos y estén atentos!