Búsqueda de sitios web

javascript - WebRTC - transmisión en vivo escalable/multicast


PROBLEMA:

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

Digamos que tenemos un transmisor "B" y dos asistentes "A1", "A2". Por supuesto, parece que es solucionable: simplemente conectamos B con A1 y luego B con A2. Así que B envía el flujo de video/audio directamente a A1 y otro flujo a A2. B envía los flujos dos veces.

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

PREGUNTA ORIGINAL (OBSOLETA)

¿Es posible de alguna manera resolver esto, para que B envíe solo un flujo en algún servidor y los asistentes simplemente obtengan este flujo de este servidor? Sí, esto significa que la velocidad de salida en este servidor debe ser alta, pero puedo mantenerla.

¿O tal vez esto significa arruinar la idea de WebRTC?

NOTAS

Flash no funciona para mis necesidades debido a la mala experiencia de usuario para los clientes finales.

SOLUCIÓN (NO REALMENTE)

26.05.2015 - No existe una solución de transmisión escalable para WebRTC en este momento, donde no se utilicen servidores de medios en absoluto. Hay soluciones del lado del servidor, así como híbridas (p2p + del lado del servidor dependiendo de diferentes condiciones) en el mercado.

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 infinitamente escalables).

SUGERENCIAS

  1. Disminuir la CPU/ancho de banda ajustando tanto los códecs de audio como de video;
  2. Consigue un servidor de medios.

Respuesta #1

Como se cubrió bastante aquí, lo que estás tratando de hacer aquí no es posible con WebRTC simple y tradicional (estrictamente de igual a igual). Porque, como se dijo antes, las conexiones WebRTC renegocian las claves de cifrado para cifrar los datos en cada sesión. Así que tu transmisor (B) efectivamente necesitará subir su transmisión tantas veces como haya asistentes.

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

Esto funciona de la siguiente manera: su transmisor se comunica con la puerta de enlace (Janus) que habla WebRTC. Por lo tanto, hay una negociación de claves: B transmite de forma segura (flujos encriptados) a Janus.

Ahora, cuando los asistentes se conecten, se conectarán a Janus, de nuevo: negociación WebRTC, claves seguras, etc. A partir de ahora, Janus emitirá de vuelta los streams a cada asistente.

Esto funciona bien porque el transmisor (B) solo sube su transmisión una vez, a Janus. Ahora Janus decodifica los datos usando su propia clave y tiene acceso a los datos en bruto (es decir, paquetes RTP) y puede emitir esos paquetes de nuevo a cada asistente (Janus se encarga de la encriptación por ti). Y como pusiste Janus en un servidor, tiene un gran ancho de banda de subida, así que podrás transmitir a muchos pares.

Así que sí, implica un servidor, pero ese servidor habla WebRTC, y tú lo "posees": implementas la parte de Janus para que no tengas que preocuparte por la corrupción de datos o un hombre en el medio. Bueno, a menos que tu servidor sea comprometido, por supuesto. Pero hay tanto que puedes hacer.

Para mostrarte lo fácil que es de usar, en Janus, tienes una función llamada incoming_rtp() (y incoming_rtcp()) que puedes llamar, la cual te da un puntero a los paquetes rt(c)p. Luego puedes enviarlo a cada participante (están almacenados en sessions que Janus hace muy fácil de usar). Mira aquí una implementación de la función incoming_rtp(), un par de líneas abajo puedes ver cómo transmitir los paquetes a todos los participantes y aquí puedes ver la función real para retransmitir un paquete rtp.

Todo funciona bastante bien, la documentación es bastante fácil de leer y entender. Te sugiero que comiences con el ejemplo "echotest", es el más simple y puedes entender el funcionamiento interno de Janus. Te sugiero que edites el archivo de prueba de eco para hacer el tuyo propio, porque hay mucho código redundante que escribir, así que más vale que comiences desde un archivo completo.

¡Diviértete! Espero que haya ayudado.

Respuesta #2

Como señaló @MuazKhan arriba:

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 peer-to-peer de WebRTC escalable.

Este módulo simplemente inicializa socket.io y lo configura de manera que una transmisión única pueda ser retransmitida a usuarios ilimitados sin problemas de uso de ancho de banda o CPU. ¡Todo sucede de igual a igual!

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

Artículos relacionados