example - live streaming html5

¿Soluciones HTML5 de transmisión de video en vivo de baja latencia(<2s)? (4)

Con Chrome deshabilitando Flash por defecto muy pronto, necesito comenzar a buscar soluciones de reemplazo flash / rtmp html5.

Actualmente con Flash + RTMP tengo una transmisión de video en vivo con <1-2 segundos de retraso.

Experimenté con MPEG-DASH, que parece ser el nuevo estándar de la industria para la transmisión, pero se quedó corto con un retraso de 5 segundos que fue lo mejor que pude sacar de él.

Por contexto, estoy tratando de permitir que los usuarios controlen los objetos físicos que pueden ver en la transmisión, por lo que cualquier cosa por encima de un par de segundos de retraso conduce a una experiencia frustrante.

¿Existen otras técnicas o realmente no hay soluciones html5 de baja latencia para la transmisión en vivo?

Tecnologías y requisitos

El único conjunto de tecnología basada en la web realmente orientado hacia la baja latencia es WebRTC. Está diseñado para videoconferencias. Los códecs están ajustados para una baja latencia sobre la calidad. Las tasas de bits suelen ser variables, optando por una conexión estable sobre la calidad.

Sin embargo, no necesariamente necesita esta optimización de baja latencia para todos sus usuarios. De hecho, por lo que puedo deducir sobre sus requisitos, la baja latencia para todos afectará la experiencia del usuario. Si bien los usuarios que controlan el robot definitivamente necesitan video de baja latencia para poder controlarlo razonablemente, los usuarios que no tienen el control no tienen este requisito y pueden optar por un video confiable de mayor calidad.

Cómo configurarlo

Conexión de usuarios en control a robot

Los usuarios que controlan el robot cargarán una página que utiliza algunos componentes de WebRTC para conectarse a la cámara y al servidor de control. Para facilitar las conexiones WebRTC, necesita algún tipo de servidor STUN. Para sortear NAT y otras restricciones de firewall, es posible que necesite un servidor TURN. Ambos están generalmente integrados en los marcos WebRTC basados en Node.js.

El servidor de control / cámara también deberá conectarse a través de WebRTC. Honestamente, la forma más fácil de hacer esto es hacer que su aplicación de control esté basada en la web. Como ya está utilizando Node.js, consulte NW.js o Electron . Ambos pueden aprovechar las capacidades de WebRTC ya integradas en WebKit, al tiempo que le brindan la flexibilidad de hacer lo que quiera con Node.js.

Los usuarios bajo control y el servidor de control / cámara establecerán una conexión punto a punto a través de WebRTC (o servidor TURN si es necesario). A partir de ahí, querrás abrir un canal de medios y un canal de datos. El lado de datos se puede usar para enviar sus comandos de robot. El canal de medios, por supuesto, se utilizará para la transmisión de video de baja latencia que se enviará de vuelta a los usuarios bajo control.

Nuevamente, es importante tener en cuenta que el video que se enviará de vuelta estará optimizado para la latencia, no para la calidad. Este tipo de conexión también garantiza una respuesta rápida a sus comandos.

Video para ver usuarios

Los usuarios que simplemente están viendo la transmisión y no controlan el robot pueden usar métodos de distribución de video normales. En realidad, es muy importante para usted usar un CDN existente y servicios de transcodificación, ya que tendrá 10k-15k personas viendo la transmisión. Con tantos usuarios, probablemente querrás tu video en un par de códecs diferentes, y ciertamente en una gran variedad de velocidades de bits. La distribución con DASH o HLS es más fácil de trabajar en este momento, y lo libera de los requisitos de Flash.

Probablemente también desee enviar su transmisión a los servicios de redes sociales. Esta es otra razón por la cual es importante comenzar con una transmisión HD de alta calidad. Esos servicios volverán a codificar su video, reduciendo la calidad. Si comienza con buena calidad primero, terminará con una mejor calidad al final.

Metadatos (chat, señales de control, etc.)

Según sus requisitos, no está claro qué tipo de metadatos necesita, pero para datos pequeños basados en mensajes, puede usar una biblioteca de sockets web, como Socket.IO. A medida que escala esto a unas pocas instancias, puede usar pub / sub, como Redis , para distribuir mensajes en todos los servidores.

Para sincronizar los metadatos con el video depende un poco de lo que hay en esos metadatos y cuál es el requisito de sincronización, específicamente. En términos generales, puede suponer que habrá un retraso razonable pero impredecible entre el video fuente y los clientes. Después de todo, no puede controlar cuánto tiempo se almacenará en el búfer. Cada dispositivo es diferente, cada variable de conexión. Lo que puede suponer es que la reproducción comenzará con el primer segmento que descargue el cliente. En otras palabras, si un cliente comienza a almacenar un video en el búfer y comienza a reproducirlo 2 segundos después, el video está a 2 segundos de cuando se realizó la primera solicitud.

Es posible detectar cuándo comienza realmente la reproducción en el lado del cliente. Como el servidor conoce la marca de tiempo para la cual se envió el video al cliente, puede informar al cliente de su desplazamiento en relación con el comienzo de la reproducción del video. Dado que probablemente usará DASH o HLS y necesitará usar MCE con AJAX para obtener los datos de todos modos, puede usar los encabezados de respuesta en la respuesta del segmento para indicar la marca de tiempo para el comienzo del segmento. El cliente puede entonces sincronizarse. Déjame desglosar esto paso a paso:

El cliente comienza a recibir mensajes de metadatos del servidor de aplicaciones.
El cliente solicita el primer segmento de video de la CDN.
El servidor CDN responde con un segmento de video. En los encabezados de respuesta, el encabezado Date: puede indicar la fecha / hora exactas para el inicio del segmento.
El cliente lee la Date: respuesta Date: encabezado (digamos 2016-06-01 20:31:00 ). El cliente continúa almacenando en búfer los segmentos.
El cliente inicia el almacenamiento en búfer / reproducción de manera normal.
Comienza la reproducción. El cliente puede detectar este cambio de estado en el reproductor y sabe que 00:00:00 en el reproductor de video es en realidad 2016-06-01 20:31:00 .
El cliente muestra los metadatos sincronizados con el video, eliminando cualquier mensaje de tiempos anteriores y almacenando en el búfer para tiempos futuros.

Esto debería satisfacer sus necesidades y darle la flexibilidad de hacer lo que necesite con su video en el futuro.

¿Por qué no [tecnología-mágica-aquí]?

Cuando elige baja latencia, pierde calidad. La calidad proviene del ancho de banda disponible. La eficiencia del ancho de banda proviene de poder almacenar en búfer y optimizar secuencias completas de imágenes al codificar. Si desea una calidad perfecta (sin pérdidas para cada imagen) necesitaría una tonelada (gigabites por espectador) de ancho de banda. Es por eso que tenemos estos códecs con pérdidas para empezar.
Dado que en realidad no necesita baja latencia para la mayoría de sus espectadores, es mejor optimizar la calidad para ellos.
Para los 2 usuarios de 15,000 que necesitan baja latencia, podemos optimizar la baja latencia para ellos. Obtendrán una calidad de video deficiente, pero podrán controlar activamente un robot, ¡lo cual es increíble!
Recuerde siempre que Internet es un lugar hostil donde nada funciona tan bien como debería. Los recursos del sistema y el ancho de banda son constantemente variables. Es por eso que WebRTC se ajusta automáticamente (lo mejor que sea razonable) a las condiciones cambiantes.
No todas las conexiones pueden cumplir con los requisitos de baja latencia. Es por eso que cada conexión de baja latencia experimentará interrupciones. Internet está conmutado por paquetes, no por conmutación de circuitos. No hay ancho de banda dedicado real disponible.
Tener un búfer grande (un par de segundos) permite a los clientes sobrevivir a pérdidas momentáneas de conexiones. Es por eso que los reproductores de CD con amortiguadores antideslizantes se crearon y se vendieron muy bien. Es una experiencia de usuario mucho mejor para esos 15,000 usuarios si el video funciona correctamente. No tienen que saber que están a 5-10 segundos detrás de la transmisión principal, pero definitivamente sabrán si el video desaparece cada dos segundos.

Hay compensaciones en cada enfoque. Creo que lo que he esbozado aquí separa las preocupaciones y le brinda las mejores compensaciones en cada área. No dude en pedir aclaraciones o hacer preguntas de seguimiento en los comentarios.

¿Revisó la solución de transmisión de medios de baja latencia de Ant Media Server? Están utilizando WebRTC Tech en productos. Además, AMS es un servidor de medios de código abierto.

Ant Media Server es capaz de transmisión de latencia ultra baja con tecnología WebRTC que proporciona el valor típico de 0.5 segundos

Cualquier tipo de transmisión en vivo podría entregarse a una amplia gama de clientes a través de una infraestructura de clúster escalable en la nube. Los SDK de Android, iOS y JavaScript están disponibles.

Además, puede probar los enlaces a continuación;

WebRTC Publisher: https://test.antmedia.io:5443/WebRTCAppEE/

WebRTC Play: https://test.antmedia.io:5443/WebRTCAppEE/player.html

WebRTC Live Demo: https://antmedia.io/livedemo/

Página de Github del Ant Media Server: https://github.com/ant-media/Ant-Media-Server

Grupo de Google Ant Media Server: https://groups.google.com/forum/m/#!forum/ant-media-server

También revise el sitio web: https://antmedia.io

Ir a WebRTC, porque:

WebRTC es un estándar que admite la comunicación en tiempo real basada en navegador. Originalmente desarrollado por Google, el estándar ahora es administrado por el W3C. WebRTC permite aplicaciones de navegador a navegador para llamadas de voz, video chat y uso compartido de archivos sin la necesidad de ningún complemento externo, que no sea un navegador compatible.

Beneficios :

Las soluciones WebRTC pueden ayudar a extender las comunicaciones unificadas (UC) en tiempo real más allá de los límites de una empresa, a cualquier cliente, socio o proveedor con un navegador habilitado para WebRTC.
Las tecnologías habilitadas para WebRTC permiten a los operadores de redes móviles crear una experiencia de cliente más atractiva en dispositivos móviles. Por ejemplo, agregar capacidad de voz o video a una aplicación proporcionada por un operador móvil permitiría a un suscriptor comunicarse con un representante de servicio al cliente para obtener un soporte más personalizado.
WebRTC reduce la implementación de TI empresarial y los costos de soporte al eliminar la necesidad del usuario de abrir clientes de Comunicaciones Unificadas. Al mismo tiempo, WebRTC permite a las empresas de telecomunicaciones y desarrolladores crear aplicaciones de comunicación y colaboración habilitadas para WebRTC con recursos de desarrollo básicos / limitados.
Mediante el uso de estándares abiertos y navegadores, WebRTC elimina la necesidad de sistemas complejos para extender a los usuarios a través de firewalls para la colaboración y el intercambio de videos. En algunos casos, WebRTC puede realmente reducir el ciclo general de ventas al ayudar rápidamente a los clientes y posibles clientes a obtener la información que necesitan.

Testing. WebRTC Testing.

Todavía no está listo (esperemos que la segunda mitad de este año), pero DASH sobre protocolos basados en HTTP Full Duplex le permitirá usar MPEG DASH sobre sockets web, proporcionando los beneficios de DASH (código abierto, ABR, compatibilidad ...) , así como la baja latencia de otros formatos (por ejemplo, WebRTC, que no funciona en safari por cierto ).

Entonces, cualquiera que esté considerando un formato de video de baja latencia dentro de unos meses, trate de buscar esto.