es muy conveniente y efectivo organizar todo tipo de transmisiones para una gran audiencia gracias a la posibilidad de cargar segmentos una vez en el CDN.<\/li>\n<\/ul>\n\nA pesar de la sencillez del motor, no todo es tan fluido como parece. El principal problema es que los desarrolladores de reproductores de terceros se han desviado de las recomendaciones de Apple, por ejemplo, en lo que respecta a los formatos de audio admitidos. En particular, muchos desarrolladores han comenzado a agregar la capacidad de trabajar con flujos de audio populares: mpeg2 video, mpeg2 audio, etc. Como resultado, se tuvieron que crear diferentes formatos de listas de reproducci\u00f3n para diferentes reproductores.<\/p>\n
Pero uno de los mayores problemas del motor HLS es la alta latencia en la transmisi\u00f3n de datos.<\/p>\n
Or\u00edgenes de los \"retardos\"<\/h2>\n \nLa principal raz\u00f3n de la alta latencia de HLS radica en que los programadores dise\u00f1aron el motor para obtener la mejor calidad de imagen posible. Por lo tanto, los par\u00e1metros del intervalo de fotogramas y el tama\u00f1o del b\u00fafer de reproducci\u00f3n simplemente no son adecuados para la transmisi\u00f3n de video en vivo. Debido a esto, se produce una latencia considerable en la transmisi\u00f3n del video, que puede ser de 5 a 7 segundos.<\/p>\n
Por un lado, esto es poco, por ejemplo, para quienes ven una pel\u00edcula desde un servidor de videohospedaje. Pero para los sistemas de videovigilancia, la latencia en la transmisi\u00f3n del video puede tener una gran importancia.<\/p>\n
Si est\u00e1 observando una oficina donde los empleados se distraen cada hora de las pantallas, entonces una latencia de 5 segundos no tiene importancia. Pero la gente ha comenzado a quejarse de que, por ejemplo, durante la transmisi\u00f3n de un partido de f\u00fatbol, en el chat ya han escrito GOOOOL, pero en el video a\u00fan no se ha visto :). Ya tenemos varios casos de usuarios donde Ivideon pr\u00e1cticamente debe reemplazar a Skype.<\/p>\n
\u00bfSe puede eliminar la latencia en HLS? La respuesta a esta pregunta suena como la declaraci\u00f3n de un experimentado exterminador de ratas en una conferencia ante j\u00f3venes desratizadores: \u00abNo se pueden eliminar las ratas, pero se puede reducir su poblaci\u00f3n a un m\u00ednimo razonable\u00bb. As\u00ed es con la latencia en HLS, no se puede eliminar por completo, pero en el mercado hay soluciones que permiten reducirla considerablemente.<\/p>\n
Segmentaci\u00f3n peque\u00f1a<\/h2>\n \nOtro inconveniente del motor es el uso de archivos peque\u00f1os para la transmisi\u00f3n de datos. A primera vista, \u00bfqu\u00e9 hay de malo en eso?<\/p>\n
Cualquiera que haya intentado copiar una gran cantidad de archivos peque\u00f1os de un dispositivo a otro seguramente habr\u00e1 notado que la velocidad de escritura de un conjunto as\u00ed es mucho m\u00e1s baja que la de un solo archivo grande del mismo tama\u00f1o. Adem\u00e1s, la intensidad de las solicitudes al disco duro aumenta significativamente, lo que afecta negativamente el rendimiento de toda la computadora. Por lo tanto, la transmisi\u00f3n de datos de video en forma de peque\u00f1os fragmentos de 10 segundos tambi\u00e9n contribuye a un aumento en la latencia del motor.<\/p>\n
Resumamos brevemente todos los pros y contras de la tecnolog\u00eda HLS.<\/p>\n
Ventajas de HLS:<\/b><\/p>\n\nPosibilidad de funcionar en cualquier dispositivo. Puedes ver videos en cualquier dispositivo moderno, ya sea un tel\u00e9fono inteligente, una tableta, una laptop o una PC de escritorio. Lo principal es que el navegador web sea una versi\u00f3n moderna y sea compatible con HTML5 y Media Source Extensions.<\/li>\n Excelente calidad de imagen. La funci\u00f3n de transmisi\u00f3n adaptativa utilizada permite cambiar din\u00e1micamente la calidad del video transmitido seg\u00fan el ancho de banda de la conexi\u00f3n a Internet, mientras que el algoritmo se esfuerza por mantener la calidad en su nivel m\u00e1ximo.<\/li>\n No es necesario configurar complicadamente el hardware del usuario.<\/li>\n<\/ol>\n\nDesventajas:<\/b><\/p>\n\nSoporte limitado para funcionar con el motor en algunos dispositivos.<\/li>\n Altas latencias en la transmisi\u00f3n de la imagen.<\/li>\n Aumento significativo de la sobrecarga y complejidad de optimizaci\u00f3n debido al uso de archivos de peque\u00f1o tama\u00f1o. Debido a las caracter\u00edsticas del contenedor, nunca podremos obtener una latencia menor que el tama\u00f1o del segmento.<\/li>\n<\/ol>\n\nLas desventajas de HLS han superado sus ventajas para nosotros y nos han llevado a buscar alternativas.<\/p>\n
\u00bfQu\u00e9 es WebRTC?<\/h2>\n \nc<\/noindex>)<\/p>\nLa plataforma WebRTC fue desarrollada por Google en 2011 para transmitir datos de video y audio en tiempo real entre navegadores y aplicaciones m\u00f3viles con m\u00ednima latencia. Para ello se utiliza el protocolo est\u00e1ndar UDP y algoritmos especiales de control de flujo. Hoy en d\u00eda es un proyecto de c\u00f3digo abierto, que es activamente soportado y desarrollado por Google.<\/p>\n
WebRTC es un conjunto de tecnolog\u00edas para la transmisi\u00f3n de video y audio de peer a peer. Es decir, por ejemplo, los navegadores de los usuarios pueden transmitir datos entre s\u00ed directamente mediante WebRTC, sin utilizar servidores remotos para almacenar y procesar datos. Toda la informaci\u00f3n tambi\u00e9n es procesada por los navegadores y aplicaciones m\u00f3viles de los usuarios finales.<\/p>\n
Los desarrolladores de todos los navegadores populares han valorado las comodidades y grandes capacidades de esta tecnolog\u00eda. Hoy en d\u00eda, el soporte para WebRTC est\u00e1 implementado en Mozilla Firefox, Opera, Google Chrome (y todos los navegadores basados en Chromium), as\u00ed como en aplicaciones m\u00f3viles para Android e iOS.<\/p>\n
A pesar de sus indudables ventajas, WebRTC tiene algunas desventajas importantes. <\/p>\n
Dificultades de elecci\u00f3n<\/h2>\n \nLa tecnolog\u00eda WebRTC es mucho m\u00e1s compleja en t\u00e9rminos de interacciones de red debido a que se basa en P2P. Es dif\u00edcil de depurar y probar, y puede comportarse de manera impredecible. Adem\u00e1s, necesitamos superar NAT y firewalls, y asegurar su funcionamiento en redes donde se bloquea UDP.<\/p>\n
La implementaci\u00f3n de WebRTC de Google es muy dif\u00edcil de utilizar. Incluso hay una empresa que ofrece servicios para compilar SDKs. Adem\u00e1s, fue muy complicado integrar la implementaci\u00f3n de Google en nuestro sistema sin tener que recodificar todo el video.<\/p>\n
Sin embargo, siempre hemos querido dar a los usuarios la posibilidad de trabajar con un video 'en vivo' completo y minimizar la latencia de la imagen en pantalla respecto a los propios eventos. Adem\u00e1s, ten\u00edamos el deseo de hacer m\u00e1s c\u00f3modo el uso de c\u00e1maras PTZ, donde las retardos son de vital importancia.<\/p>\n
Dado que otras implementaciones para combatir el lag a\u00fan tienen funcionalidad limitada y funcionan notablemente peor, decidimos utilizar WebRTC. <\/p>\n
Lo que hicimos<\/h2>\n \n
Para el correcto funcionamiento de WebRTC, primero es necesario llevar a cabo una modernizaci\u00f3n tecnol\u00f3gica del stack para trabajar con video web. Lo que hemos hecho.<\/p>\n
Primero implementamos un servidor de protocolo de se\u00f1alizaci\u00f3n WebRTC sobre Websocket, y tambi\u00e9n desplegamos un servidor peer de WebRTC en la nube basado en el SDK webrtc.org. Su funci\u00f3n es distribuir flujos de video a los peers clientes de WebRTC en formato H.264 + Opus\/G.711 sin recodificar el video.<\/p>\n
Elegimos Websocket como protocolo de se\u00f1alizaci\u00f3n porque ya cuenta con un buen soporte en todos los navegadores web populares. Esto permite reducir significativamente no solo los costos de desarrollo, sino tambi\u00e9n evitar la p\u00e9rdida de tiempo y recursos en rehandshakes de TCP y TLS en comparaci\u00f3n con AJAX.<\/p>\n
El hecho es que por defecto WebRTC no proporciona un protocolo de se\u00f1alizaci\u00f3n necesario para la correcta configuraci\u00f3n, mantenimiento y ruptura de la videoconferencia en tiempo real entre las aplicaciones de origen y cliente.<\/p>\n
Y para implementar la tecnolog\u00eda de se\u00f1alizaci\u00f3n por nuestra cuenta, necesitamos desarrollar nuestro propio servidor de se\u00f1alizaci\u00f3n con soporte para varios protocolos web (Websocket, WebRTC). Tambi\u00e9n debe tener la capacidad de gestionar sesiones y notificaciones de manera segura en tiempo real, as\u00ed como la gesti\u00f3n de video y muchos otros par\u00e1metros.<\/p>\n
Superamos las limitaciones de P2P reduciendo la latencia no a trav\u00e9s de P2P, sino mediante UDP y un control de flujo orientado a disminuir la latencia. Esto tambi\u00e9n est\u00e1 incorporado en WebRTC, ya que el caso de uso principal son las conversaciones P2P a trav\u00e9s del navegador.<\/p>\n
En el cliente m\u00f3vil implementamos un reproductor utilizando el SDK webrtc.org, ya que solo este ofrece un correcto control de flujo, incluye todos los esquemas conocidos de Correcci\u00f3n de Errores Adelantados (FEC) y su mecanismo de retransmisi\u00f3n de paquetes est\u00e1 bien implementado para todos los navegadores. Tambi\u00e9n es importante destacar que el SDK webrtc.org es activamente desarrollado por Google.<\/p>\n
\u00bfCu\u00e1l es el resultado de implementar WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")