WebRTC: transmisión / multidifusión de transmisión en vivo escalable

PROBLEMA:

WebRTC nos brinda conexiones de video / audio peer-to-peer. Es perfecto para llamadas p2p, hangouts. Pero, ¿qué pasa con la transmisión (uno a muchos, por ejemplo, 1 a 10000)?

Digamos que tenemos una emisora ​​"B" y dos asistentes "A1", "A2". Por supuesto, parece tener solución: simplemente conectamos B con A1 y luego B con A2. Entonces, B envía la transmisión de video / audio directamente a A1 y otra transmisión a A2. B envía transmisiones dos veces.

Ahora imaginemos que hay 10000 asistentes: A1, A2, ..., A10000. Significa que B debe enviar 10000 flujos. Cada transmisión es de ~ 40 KB / s, lo que significa que B necesita una velocidad de salida de Internet de 400 MB / s para mantener esta transmisión. Inaceptable.

PREGUNTA ORIGINAL (OBSOLETA)

¿Es posible de alguna manera resolver esto, entonces B envía solo una transmisión en algún servidor y los asistentes simplemente extraen esta transmisión de este servidor? Sí, esto significa que la velocidad de salida en este servidor debe ser alta, pero puedo mantenerla.

¿O quizás esto signifique arruinar la idea de WebRTC?

NOTAS

Flash no funciona para mis necesidades debido a la mala UX para los clientes finales.

SOLUCIÓN (NO REALMENTE)

26.05.2015 - No existe una solución de este tipo para la transmisión escalable para WebRTC en este momento, donde no usa servidores de medios en absoluto. Existen en el mercado soluciones tanto del lado del servidor como híbridas (p2p + del lado del servidor según las diferentes condiciones).

Sin embargo, hay algunas tecnologías prometedoras como https://github.com/muaz-khan/WebRTC-Scalable-Broadcast pero necesitan responder a esos posibles problemas: latencia, estabilidad general de la conexión de red, fórmula de escalabilidad (probablemente no sean escalables al infinito ).

SUGERENCIAS

1. Disminuya la CPU / el ancho de banda ajustando los códecs de audio y video;
2. Consiga un servidor de medios.

Como se cubrió prácticamente aquí, lo que está tratando de hacer aquí no es posible con WebRTC simple y pasado de moda (estrictamente de igual a igual). Porque, como se dijo anteriormente, las conexiones WebRTC renegocian las claves de cifrado para cifrar los datos, para cada sesión. Por lo tanto, su locutor (B) tendrá que cargar su transmisión tantas veces como asistentes haya.

Sin embargo, hay una solución bastante simple, que funciona muy bien: la he probado, se llama gateway WebRTC. Janus es un buen ejemplo. Es completamente de código abierto ( repositorio de github aquí ).

Esto funciona de la siguiente manera: su locutor contacta con la puerta de enlace (Janus) que habla WebRTC . Entonces, hay una negociación de clave: B transmite de forma segura (secuencias cifradas) a Janus.

Ahora, cuando los asistentes se conectan, se conectan a Janus, nuevamente: negociación de WebRTC, claves seguras, etc. A partir de ahora, Janus emitirá las transmisiones a cada asistente.

Esto funciona bien porque la emisora ​​(B) solo carga su transmisión una vez, a Janus. Ahora Janus decodifica los datos usando su propia clave y tiene acceso a los datos en bruto (eso, paquetes RTP) y puede devolver esos paquetes a cada asistente (Janus se encarga del cifrado por usted). Y dado que coloca Janus en un servidor, tiene un gran ancho de banda de carga, por lo que podrá transmitir a muchos pares.

Así que sí, hace involucrar a un servidor, pero ese servidor habla WebRTC, y que "propia": usted poner en práctica la parte Janus por lo que no tiene que preocuparse por la corrupción de datos o el hombre en el medio. Bueno, a menos que su servidor esté comprometido, por supuesto. Pero hay tanto que puedes hacer.

Para mostrarle lo fácil que es de usar, en Janus, tiene una función llamada incoming_rtp()(y incoming_rtcp()) que puede llamar, que le da un puntero a los paquetes rt (c) p. A continuación, puede enviarlo a cada asistente (están almacenados en el sessionsque Janus hace que sea muy fácil de usar). Busque aquí una implementación de la incoming_rtp()función , un par de líneas a continuación puede ver cómo transmitir los paquetes a todos los asistentes y aquí puede ver la función real para retransmitir un paquete rtp.

Todo funciona bastante bien, la documentación es bastante fácil de leer y comprender. Le sugiero que comience con el ejemplo "echotest", es el más simple y puede comprender el funcionamiento interno de Janus. Le sugiero que edite el archivo de prueba de eco para crear el suyo propio, porque hay mucho código redundante para escribir, por lo que también puede comenzar desde un archivo completo.

¡Que te diviertas! Espero haber ayudado.

Como @MuazKhan señaló anteriormente:

https://github.com/muaz-khan/WebRTC-Scalable-Broadcast

funciona en Chrome y aún no hay transmisión de audio, pero parece ser una primera solución.

Una demostración de transmisión de igual a igual de WebRTC escalable.

Este módulo simplemente inicializa socket.io y lo configura de manera que una transmisión única se pueda transmitir a usuarios ilimitados sin problemas de uso de ancho de banda / CPU. ¡Todo sucede peer-to-peer!

Definitivamente, esto debería ser posible de completar.
Otros también pueden lograr esto: http://www.streamroot.io/

AFAIK, la única implementación actual de esto que es relevante y madura es Adobe Flash Player, que ha admitido multidifusión p2p para transmisión de video de igual a igual desde la versión 10.1.

http://tomkrcha.com/?p=1526 .

La difusión "escalable" no es posible en Internet, porque allí no se permite la multidifusión IP UDP. Pero, en teoría, es posible en una LAN.
El problema con Websockets es que no tiene acceso a RAW UDP por diseño y no estará permitido.
El problema con WebRTC es que sus canales de datos utilizan una forma de SRTP, donde cada sesión tiene su propia clave de cifrado . Entonces, a menos que alguien "invente" o una API permita una forma de compartir una clave de sesión entre todos los clientes, la multidifusión es inútil.

Existe la solución de la entrega asistida por pares, lo que significa que el enfoque es híbrido. Tanto el servidor como los pares ayudan a distribuir el recurso. Ese es el enfoque que han adoptado peer5.com y peercdn.com .

Si hablamos específicamente de la transmisión en vivo, se verá así:

1. La emisora ​​envía el video en vivo a un servidor.
2. El servidor guarda el video (generalmente también lo transcodifica a todos los formatos relevantes).
3. Se están creando metadatos sobre esta transmisión en vivo, compatible con HLS o HDS o MPEG_DASH
4. Los consumidores buscan la transmisión en vivo relevante, donde el reproductor obtiene los metadatos y sabe qué partes del video obtener a continuación.
5. Al mismo tiempo, el consumidor se conecta con otros consumidores (a través de WebRTC)
6. Luego, el reproductor descarga el fragmento relevante directamente desde el servidor o desde sus pares.

Seguir un modelo de este tipo puede ahorrar hasta ~ 90% del ancho de banda del servidor, dependiendo de la tasa de bits de la transmisión en vivo y el enlace ascendente colaborativo de los espectadores.

descargo de responsabilidad: el autor está trabajando en Peer5

Mi maestría se centra en el desarrollo de un protocolo de transmisión en vivo cdn / p2p híbrido utilizando WebRTC. He publicado mis primeros resultados en http://bem.tv

¡Todo es de código abierto y estoy buscando colaboradores! :-)

La respuesta de Angel Genchev parece ser correcta, sin embargo, existe una arquitectura teórica que permite la transmisión de baja latencia a través de WebRTC. Imagine B (locutor) transmite a A1 (asistente 1). Entonces A2 (asistente 2) se conecta. En lugar de transmitir de B a A2, A1 comienza a transmitir video que se recibe de B a A2. Si A1 se desconecta, A2 comienza a recibir de B.

Esta arquitectura podría funcionar si no hay latencias ni tiempos de espera de conexión. Entonces, teóricamente es correcto, pero no en la práctica.

En este momento estoy usando la solución del lado del servidor.

Hay algunas soluciones disponibles en el mercado para la solución escalable WebRTC. Proporcionan transmisión webrtc escalable y de baja latencia. A continuación se muestran algunos ejemplos. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Soy desarrollador de Ant Media Server , proporcionamos ediciones tanto para la comunidad como para empresas, incluido el SDK de Android e iOS también. Háganos saber si podemos ayudarlo de alguna manera.

Está describiendo el uso de WebRTC con un requisito de uno a muchos. WebRTC está diseñado para la transmisión de igual a igual, sin embargo, existen configuraciones que le permitirán beneficiarse de la baja latencia de WebRTC mientras entrega video a muchos espectadores.

El truco es no gravar al cliente de transmisión con cada espectador y, como mencionaste, tener un servidor de medios de "retransmisión". Puede crearlo usted mismo, pero, sinceramente, la mejor solución suele ser utilizar algo como el producto WebRTC Streaming de Wowza .

Para transmitir de manera eficiente desde un teléfono, puede usar el SDK GoCoder de Wowza, pero en mi experiencia, un SDK más avanzado como StreamGears funciona mejor.

Estoy desarrollando un sistema de transmisión WebRTC utilizando Kurento Media Server . Kurento Admite varios tipos de protocolos de transmisión, como RTSP, WebRTC, HLS. Funciona también en términos de tiempo real y escalado.

Por lo tanto, Kurento no es compatible con RTMP, que ahora se usa en Youtube o Twitch. Uno de los problemas conmigo es el número de usuarios concurrentes con esto.

Espero que te ayude.

Como peer1 es solo el peer que invoca getUserMedia (), es decir, peer1 crea una sala.

1. Por lo tanto, peer1 captura los medios y comienza el espacio.
2. peer2 se une a la sala y obtiene la transmisión (datos) de peer1 y también abre una conexión paralela denominada "peer2-connection"
3. Cuando peer3 se une a la sala y obtiene el flujo (datos) de peer2 y también abre la conexión paralela denominada 'peer3-connection' y así sucesivamente.

Este proceso es continuo ya que muchos pares se conectan entre sí.

Por lo tanto, con esto, se puede transferir una única transmisión a usuarios ilimitados sin problemas de uso de ancho de banda / CPU.

Finalmente, todo lo anterior es una referencia de Link .