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

114

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.
igorpavlov
fuente
3
"La única forma de crear una aplicación escalable es utilizar una solución del lado del servidor". Eso parece bastante claro ... En cuanto a WebRTC, nunca fue diseñado para transmisiones a gran escala. Use algo que admita multidifusión para eso, o si tiene que ir a través de Internet, una conexión uno a uno basada en servidor, ya que los ISP no enrutan la multidifusión.
Dark Falcon
1
¿Por qué no utilizar WebRTC de cliente a servidor? El problema está en la distribución, ya que la conexión del cliente no puede manejarlo, así que envíe un vapor al servidor y transmita a los clientes desde allí. El ancho de banda será costoso, pero no puede evitar enviar una sola transmisión a cada usuario o hacer que el usuario envíe una transmisión a otros usuarios.
Dark Falcon
1
Tengo conocimiento de que hay al menos dos empresas que están tratando de realizar entregas de video p2p basadas en webrtc : affovi.com/rtcplayer.html , principalmente para video en vivo; y peer5.com , principalmente para VOD.
Svetlin Mladenov
1
@igorpavlov Es posible que desee consultar: github.com/muaz-khan/WebRTC-Scalable-Broadcast Aunque solo funciona en Chrome y aún no hay transmisión de audio.
Muaz Khan
4
No hay forma de alcanzar esa escalabilidad sin un MCU de algún tipo. WebRTC está diseñado para ser Peer-to-Peer. No puede transmitir desde él sin criticar absolutamente a su locutor (con una conexión de pares única para cada transmisión, que pasa a ser otra transmisión que se codifica). En cuanto a la retransmisión de los medios de igual a igual, eso podría ser posible, pero, por supuesto, esto generaría una latencia adicional para cada par que se agregue a la transmisión más adelante. Por calidad y escalabilidad, tener un servidor MCU webrtc es la única solución realista.
Benjamin Trent

Respuestas:

66

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.

nschoe
fuente
1
¿Es cierto que esto no funciona en Safari actualmente (o en cualquier navegador que no admita WebRTC?). ¿Alguien sabe de una solución híbrida en la que se transmite desde el navegador al servidor utilizando WebRTC y luego se transcodifica el video a HLS / HDS (o incluso RTMP) para que encaje en un sistema de transmisión tradicional?
Ben
1
@Ben sí, no funciona con navegadores que no son compatibles con WebRTC. En los días (cuando escribo esto) Safari claramente no apoyaba esto. Hoy, sin embargo, no lo he comprobado. Pero sigo pensando que no son compatibles con WebRTC (aunque por confirmar). En cuanto a usarlo en un sistema híbrido, esto es totalmente posible, en realidad esto es lo que hice para la empresa en la que trabajaba; como dijiste, transmití desde el navegador al servidor y, desde allí, construí y conecté un canal de GStreamer para transcodificar el feed. ¡Tú también puedes hacer esto!
nschoe
¿Alguna idea sobre jitsi? ¿Jitisi también es lo mismo?
ishandutta2007
@nschoe ¿Es esto mejor que usar websocket para hacer lo mismo?
Navigateur
En realidad, está explicando cómo funciona una SFU (Unidad de reenvío selectivo). Puedes hacer lo mismo con mediasoup
Dirk V
11

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!

ingrese la descripción de la imagen aquí

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

rubo77
fuente
1
Esto me parece un poco anticuado. ¿Alguna actualización o comentario sobre esta idea?
igorpavlov
Además, ¿resuelve los problemas de latencia de todos modos? Por ejemplo, Peer1 habla con Peer5 y Peer2 finalmente pierde la conexión. ¿O esta arquitectura es buena solo para LAN?
igorpavlov
Además, ¿Streamroot es similar a Peer5?
igorpavlov
7

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 .

Tom
fuente
1
La gente no mata la tecnología. La tecnología se está matando al proporcionar una UX muy pobre, especialmente cuando se permite micrófono / cámara. Ahí es donde gana getusermedia.
igorpavlov
No podría estar más de acuerdo.
Tom
Aparte del mal ux, ¿sería esta la solución? ¿Servidor menos?
rubo77
6

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.

Ángel Genchev
fuente
1
pero los chats ya funcionan con WebRTC, por lo que todos ven todos los mensajes, por lo que uno a muchos también debería funcionar para el video de alguna manera
rubo77
@ rubo77 Los datos enviados con mensajes de texto no son nada comparados con la tasa y la cantidad de datos enviados con secuencias de video. Así que los chats pueden contener fácilmente a muchos más usuarios a la vez
Dirk V
5

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

Shacharz
fuente
Gracias. Sé sobre peer5 y lo encuentro una solución bastante atractiva. Sin embargo, el propósito de esta pregunta era encontrar una solución absolutamente sin servidor (solo se permite STUN / TURN).
igorpavlov
5

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! :-)

flavioribeiro
fuente
¿Utiliza algún tipo de software del lado del servidor como MCU?
igorpavlov
De hecho, estoy usando algunos componentes del lado del servidor de rtcio people: github.com/rtc-io
flavioribeiro
1
Parece que usa sus componentes para la señalización. ¿Qué hay de la transmisión de video del lado del servidor? ¿O tu solución es absolutamente P2P?
igorpavlov
perdón por la larga demora en responderte @igorpavlov, estoy usando EvoStream para segmentar los videos y estoy haciendo un bucle en una fuente de video y apuntando a EvoStream usando el codificador elemental.
flavioribeiro
Es un proveedor de servidores de medios. ¿Más eficiente? Probablemente. ¿Es lo que estoy buscando? No.
igorpavlov
2

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.

igorpavlov
fuente
¿Qué pasa con la velocidad de transmisión en la solución del lado del servidor? Por favor comparte.
user2003356
¿Medios de solución del lado del servidor? ¿Qué usaste? Sería útil para mi investigación. Por favor comparte. Gracias.
user2003356
La solución del lado del servidor significa Opentok por Tokbox. No los publicito, hay toneladas de soluciones de este tipo en el mercado, pero me quedo con esta. Funciona como un servidor de medios. PD: ¿A qué te refieres con comunicación multipartita? No lo entiendo.
igorpavlov
@igorpavlov ¿podría dar una lista de empresas que ofrecen webrtc del lado del servidor? Solo conozco a Flashphoner y Opentok. Gracias
Ramil Amerzyanov
Tendría curiosidad por ver si esto realmente escalaría. Es seguro que habrá problemas de escalado con la latencia en grupos ENORMES (1000+) pero si solo hay 5-10, me imagino que funcionaría bastante bien, pero se necesitaría un trabajo elegante si alguien en el medio de la cadena de pares " "se va y volver a conectar a todos los pares subsiguientes si es solo una sola cadena sería un ENORME sobrecarga. Puede ser mejor utilizar una estructura de árbol binaria / ternaria.
Benjamin Trent
2

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.

muy lejos
fuente
1

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.

videocámara
fuente
1

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.

imalice
fuente
0

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 .

susan097
fuente
1
Este enfoque ya se mencionó, pero es posible que no funcione en el mundo real. Como Peer3, ¿por qué debería preocuparme por el rendimiento del ancho de banda de Peer2? Por supuesto, Peer3 puede recurrir a Peer1 si Peer2 abandona la cadena, pero eso provocará toneladas de interrupciones en la transmisión, reconexiones, etc. Cuanto más esté en la cadena, más sufriré. Entonces, sí, puede funcionar en LAN, pero probablemente sea eso.
igorpavlov
La transmisión en paralelo no se ocupa del ancho de banda y si una vez que se establece la conexión de peer3 a peer1 a través de peer2 y de tal manera que peer2 se recupera, peer3 permanece conectado a peer1.
susan097
No estoy seguro de haber entendido. En realidad, no me estaba refiriendo al enlace, ahora permítanme referirme. Este enlace github.com/muaz-khan/WebRTC-Scalable-Broadcast tiene una imagen en la sección "¿Cómo funciona?" sección. Esta imagen le dice claramente que una vez, digamos que Peer5 se desconecta, Peer8,9 y 10 se desconectan de la transmisión. Necesitarán conectarse a Peer2 o Peer6, pero eso provocará retrasos. Además, este proyecto no tiene colaboradores ni actividad.
igorpavlov