javascript - multidifusion - WebRTC: transmisión de multidifusión en tiempo real escalable en vivo
multidifusion ip (7)
AFAIK la única implementación actual de esto que es relevante y madura es Adobe Flash Player, que ha sido compatible con la multidifusión p2p para la transmisión de video entre pares desde la versión 10.1.
[! ] La pregunta sigue abierta
PROBLEMA:
WebRTC nos brinda conexiones de audio / video punto a punto. Es perfecto para llamadas p2p, hangouts. Pero, ¿qué pasa con la radiodifusión (de uno a muchos, por ejemplo, de 1 a 10000)?
Digamos que tenemos una emisora "B" y dos asistentes "A1", "A2". Por supuesto, parece ser solucionable: simplemente conectamos B con A1 y luego B con A2. Así que 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 10.000 streams. Cada flujo es ~ 40KB / s lo que significa que B necesita una velocidad de salida de Internet de 400MB / s para mantener esta transmisión. Inaceptable.
PREGUNTA ORIGINAL (OBSOLETA)
¿Es posible de alguna manera resolver esto, por lo que 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 tal vez esto significa arruinar la idea de WebRTC?
[! ] PREGUNTA ACTUALIZADA
- Resuelva la CPU / ancho de banda: ¿hay una solución sin servidor (también conocido como multidifusión o algo similar)?
- Solución de CPU: ¿es posible codificar la transmisión solo una vez y enviarla a sus pares?
- Resuelva la CPU / ancho de banda: la multidifusión definitivamente es posible, pero ¿realmente funciona en la vida real (latencia, inestabilidad de red)?
NOTAS
Flash no está funcionando para mis necesidades según UX pobre para clientes finales.
SOLUCIÓN
26.05.2015 - No existe una solución para la retransmisión escalable para WebRTC en este momento, donde no se utilizan servidores multimedia. Existen soluciones del lado del servidor, así como híbridas (p2p + lado del servidor según las diferentes condiciones) en el mercado.
Aunque hay algunos técnicos prometedores como https://github.com/muaz-khan/WebRTC-Scalable-Broadcast pero necesitan responder a estos posibles problemas: latencia, estabilidad general de la conexión de red, fórmula de escalabilidad (no son infinitamente escalables, probablemente )
Como @MuazKhan señaló anteriormente:
https://github.com/muaz-khan/WebRTC-Scalable-Broadcast
funciona en cromo, y aún no hay transmisión de audio, pero parece ser una primera solución.
Una demostración de difusión de punto a punto escalable de WebRTC.
Este módulo simplemente inicializa socket.io y lo configura de una manera que la transmisión individual puede transmitirse a través de usuarios ilimitados sin problemas de uso de ancho de banda / CPU. ¡Todo sucede igual a igual!
Esto definitivamente debería ser posible de completar.
Otros también pueden lograr esto: http://www.streamroot.io/
Como prácticamente se cubrió aquí, lo que intenta hacer aquí no es posible con WebRTC simple y anticuado (estrictamente de igual a igual). Como se dijo anteriormente, las conexiones WebRTC renegocian las claves de cifrado para cifrar los datos, para cada sesión. Por lo tanto, su emisora (B) deberá cargar su transmisión tantas veces como asistentes.
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 github aquí ).
Esto funciona de la siguiente manera: su emisora se comunica con la puerta de enlace (Janus) que habla WebRTC . Entonces, hay una negociación clave: B transmite de manera segura (flujos encriptados) a Janus.
Ahora, cuando los asistentes se conectan, se conectan a Janus, de nuevo: negociación de WebRTC, claves seguras, etc. A partir de ahora, Janus emitirá nuevamente 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 brutos (que son, paquetes RTP) y puede emitir esos paquetes a cada asistente (Janus se encarga de la encriptación). Y puesto que pone a Janus en un servidor, tiene un gran ancho de banda de carga, por lo que podrá transmitir a muchos pares.
Así que sí, implica un servidor, pero ese servidor habla WebRTC, y usted lo "posee": implementa la parte de Janus para que no tenga que preocuparse por la corrupción de datos o por el hombre en el medio. Bueno, a menos que su servidor esté en peligro, por supuesto. Pero hay mucho que puedes hacer.
Para mostrarle lo fácil que es usar, en Janus, tiene una función llamada incoming_rtp() (y incoming_rtcp() ) a la que puede llamar, que le da un puntero a los paquetes rt (c) p. Luego puede enviarlo a cada asistente (se almacenan en sessions que Janus hace muy fáciles de usar). Busque aquí una implementación de la función incoming_rtp() , un par de líneas a continuación puede ver cómo transmitir los paquetes a todos los asistentes y here 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 entender. Sugiero que comiences con el ejemplo "echotest", es el más simple y puedes entender el funcionamiento interno de Janus. Le sugiero que edite el archivo de prueba de eco para que haga el suyo, porque hay un montón de código redundante para escribir, por lo que también podría comenzar desde un archivo completo.
¡Que te diviertas! Espero que haya ayudado.
Existe la solución de entrega asistida por pares, lo que significa que el enfoque es híbrido. Tanto el servidor como los compañeros ayudan a distribuir el recurso. Ese es el enfoque que peer5.com y peercdn.com han tomado.
Si hablamos específicamente de transmisión en vivo, se verá más o menos así:
- El locutor envía el video en vivo a un servidor.
- El servidor guarda el video (generalmente también lo transcodifica a todos los formatos relevantes).
- Se está creando un metadato sobre esta transmisión en vivo, compatible con HLS o HDS o MPEG_DASH
- Los consumidores buscan en la transmisión en vivo relevante allí donde el jugador obtiene los metadatos y sabe qué partes del video desea obtener después.
- Al mismo tiempo, el consumidor se está conectando con otros consumidores (a través de WebRTC)
- Luego, el jugador descarga el fragmento relevante directamente del servidor o de sus compañeros.
Seguir este modelo puede ahorrar hasta ~ 90% del ancho de banda del servidor dependiendo de la tasa de bits de la transmisión en vivo y del enlace ascendente colaborativo de los espectadores.
descargo de responsabilidad: el autor está trabajando en Peer5
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 las transmisiones B (emisora) 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 y tiempos de espera de conexión. Entonces teóricamente es correcto, pero no prácticamente.
Por el momento estoy usando la solución del lado del servidor.
La transmisión "escalable" no es posible en Internet, porque la multidifusión IP UDP no está permitida allí. 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 será permitido.
El problema con WebRTC es que los canales de datos usan 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.
Mi maestría se centra en el desarrollo de un protocolo híbrido de transmisión en vivo cdn / p2p utilizando WebRTC. Publiqué mis primeros resultados en http://bem.tv
¡Todo es de código abierto y estoy buscando colaboradores! :-)