WebRTC: trasmissione / multicasting in streaming live scalabile

PROBLEMA:

WebRTC ci offre connessioni video / audio peer-to-peer. È perfetto per chiamate p2p, hangout. Ma per quanto riguarda la trasmissione (uno-a-molti, ad esempio, da 1 a 10000)?

Diciamo che abbiamo un'emittente "B" e due partecipanti "A1", "A2". Ovviamente sembra risolvibile: colleghiamo semplicemente B con A1 e poi B con A2. Quindi B invia il flusso video / audio direttamente ad A1 e un altro flusso ad A2. B invia flussi due volte.

Ora immaginiamo che ci siano 10000 partecipanti: A1, A2, ..., A10000. Significa che B deve inviare 10000 flussi. Ogni flusso è di ~ 40 KB / s, il che significa che B richiede una velocità Internet in uscita di 400 MB / s per mantenere questa trasmissione. Inaccettabile.

DOMANDA ORIGINALE (OBSOLETA)

È possibile in qualche modo risolverlo, quindi B invia solo un flusso su alcuni server ei partecipanti estraggono questo flusso da questo server? Sì, questo significa che la velocità in uscita su questo server deve essere alta, ma posso mantenerla.

O forse questo significa rovinare l'idea di WebRTC?

APPUNTI

Flash non funziona per le mie esigenze come da scarsa UX per i clienti finali.

SOLUZIONE (NON DAVVERO)

26.05.2015 - Al momento non esiste una soluzione del genere per la trasmissione scalabile per WebRTC, in cui non si utilizzano affatto server multimediali. Sul mercato sono disponibili sia soluzioni lato server che ibride (p2p + lato server a seconda delle diverse condizioni).

Ci sono alcune tecnologie promettenti anche se come https://github.com/muaz-khan/WebRTC-Scalable-Broadcast ma devono rispondere a questi possibili problemi: latenza, stabilità complessiva della connessione di rete, formula di scalabilità (probabilmente non sono scalabili all'infinito ).

SUGGERIMENTI

1. Diminuisci CPU / larghezza di banda modificando sia i codec audio che video;
2. Procurati un media server.

Dato che è stato praticamente trattato qui, quello che stai cercando di fare qui non è possibile con un semplice WebRTC vecchio stile (rigorosamente peer-to-peer). Perché come è stato detto in precedenza, le connessioni WebRTC rinegoziano le chiavi di crittografia per crittografare i dati, per ogni sessione. Quindi la tua emittente (B) dovrà effettivamente caricare il suo flusso tante volte quanti sono i partecipanti.

Tuttavia, esiste una soluzione abbastanza semplice, che funziona molto bene: l'ho testata, si chiama gateway WebRTC. Janus è un buon esempio. È completamente open source ( github repo qui ).

Funziona come segue: la tua emittente contatta il gateway (Janus) che parla WebRTC . Quindi c'è una negoziazione chiave: B trasmette in modo sicuro (flussi crittografati) a Janus.

Ora, quando i partecipanti si connettono, si connettono a Janus, di nuovo: negoziazione WebRTC, chiavi protette, ecc. D'ora in poi, Janus restituirà i flussi a ciascun partecipante.

Funziona bene perché l'emittente (B) carica il suo flusso solo una volta, su Janus. Ora Janus decodifica i dati utilizzando la propria chiave e ha accesso ai dati grezzi (ovvero i pacchetti RTP) e può restituire quei pacchetti a ciascun partecipante (Janus si occupa della crittografia per te). E poiché metti Janus su un server, ha una grande larghezza di banda di upload, quindi sarai in grado di trasmettere in streaming a molti peer.

Quindi sì, fa coinvolgere un server, ma quel server parla WebRTC, e "proprio" esso: si implementa la parte Giano in modo da non dovete preoccuparvi di corruzione dei dati o l'uomo nel mezzo. A meno che il tuo server non sia compromesso, ovviamente. Ma puoi fare così tanto.

Per mostrarti quanto sia facile da usare, in Janus, hai una funzione chiamata incoming_rtp()(e incoming_rtcp()) che puoi chiamare, che ti dà un puntatore ai pacchetti rt (c) p. Puoi quindi inviarlo a ciascun partecipante (sono memorizzati in sessionsquel Janus rende molto facile da usare). Cerca qui un'implementazione della incoming_rtp()funzione , un paio di righe sotto puoi vedere come trasmettere i pacchetti a tutti i partecipanti e qui puoi vedere la funzione effettiva per ritrasmettere un pacchetto rtp.

Funziona tutto abbastanza bene, la documentazione è abbastanza facile da leggere e capire. Ti suggerisco di iniziare con l'esempio "echotest", è il più semplice e puoi capire il funzionamento interno di Janus. Ti suggerisco di modificare il file echo test per crearne uno tuo, perché c'è molto codice ridondante da scrivere, quindi potresti anche iniziare da un file completo.

Divertiti! Spero di aver aiutato.

Come @MuazKhan ha notato sopra:

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

funziona in Chrome e non è ancora stata trasmessa l'audio, ma sembra essere una prima soluzione.

Una demo di trasmissione peer-to-peer WebRTC scalabile.

Questo modulo inizializza semplicemente socket.io e lo configura in modo che una singola trasmissione possa essere inoltrata su un numero illimitato di utenti senza problemi di larghezza di banda / utilizzo della CPU. Tutto avviene peer-to-peer!

Questo dovrebbe essere sicuramente possibile completare.
Anche altri sono in grado di farlo: http://www.streamroot.io/

Per quanto ne so, l'unica implementazione attuale di questo che è rilevante e matura è Adobe Flash Player, che ha supportato il multicast p2p per la trasmissione video peer to peer dalla versione 10.1.

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

La trasmissione "scalabile" non è possibile su Internet, perché il multicasting IP UDP non è consentito lì. Ma in teoria è possibile su una LAN.
Il problema con Websocket è che non hai accesso a RAW UDP per impostazione predefinita e non sarà consentito.
Il problema con WebRTC è che i suoi canali di dati utilizzano una forma di SRTP, in cui ogni sessione ha la propria chiave di crittografia . Quindi, a meno che qualcuno "inventa" o un'API non consenta un modo per condividere una chiave di sessione tra tutti i client, il multicast è inutile.

Esiste la soluzione della consegna assistita da pari, il che significa che l'approccio è ibrido. Sia il server che i peer aiutano a distribuire la risorsa. Questo è l'approccio adottato da peer5.com e peercdn.com .

Se parliamo specificamente di trasmissione in diretta, sarà simile a questo:

1. L'emittente invia il video in diretta a un server.
2. Il server salva il video (di solito lo transcodifica anche in tutti i formati pertinenti).
3. È in corso la creazione di metadati su questo live streaming, compatibile con HLS o HDS o MPEG_DASH
4. I consumatori accedono al live streaming pertinente e il giocatore riceve i metadati e sa quali parti del video devono ricevere.
5. Allo stesso tempo il consumatore viene connesso ad altri consumatori (tramite WebRTC)
6. Quindi il giocatore scarica il pezzo pertinente direttamente dal server o dai peer.

Seguendo un tale modello è possibile risparmiare fino al ~ 90% della larghezza di banda del server a seconda del bitrate del live streaming e dell'uplink collaborativo degli spettatori.

disclaimer: l'autore sta lavorando a Peer5

Il mio master è focalizzato sullo sviluppo di un protocollo di live streaming ibrido cdn / p2p utilizzando WebRTC. Ho pubblicato i miei primi risultati su http://bem.tv

Tutto è open source e sto cercando collaboratori! :-)

La risposta di Angel Genchev sembra essere corretta, tuttavia esiste un'architettura teorica, che consente la trasmissione a bassa latenza tramite WebRTC. Immagina che B (emittente) trasmetta in streaming ad A1 (partecipante 1). Quindi A2 (partecipante 2) si connette. Invece di eseguire lo streaming da B ad A2, A1 avvia lo streaming video ricevuto da B ad A2. Se A1 si disconnette, A2 inizia a ricevere da B.

Questa architettura potrebbe funzionare se non ci sono latenze e timeout di connessione. Quindi in teoria è giusto, ma non praticamente.

Al momento sto utilizzando una soluzione lato server.

Ci sono alcune soluzioni disponibili sul mercato per la soluzione scalabile WebRTC. Forniscono streaming webrtc scalabile a bassa latenza. Ecco alcuni esempi. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Sono sviluppatore per Ant Media Server , forniamo sia community che enterprise edition, inclusi Android e iOS SDK. Facci sapere se possiamo aiutarti in qualche modo.

Stai descrivendo l'utilizzo di WebRTC con un requisito uno-a-molti. WebRTC è progettato per lo streaming peer-to-peer, tuttavia esistono configurazioni che ti consentiranno di beneficiare della bassa latenza di WebRTC mentre fornisci video a molti spettatori.

Il trucco è non tassare il client di streaming con ogni visualizzatore e, come hai detto, avere un server multimediale "relay". Puoi costruirlo da solo, ma onestamente la soluzione migliore è spesso usare qualcosa come il prodotto di streaming WebRTC di Wowza .

Per eseguire lo streaming in modo efficiente da un telefono puoi utilizzare GoCoder SDK di Wowza, ma nella mia esperienza un SDK più avanzato come StreamGears funziona meglio.

Sto sviluppando un sistema di trasmissione WebRTC utilizzando Kurento Media Server . Kurento Supporta diversi tipi di protocollo di streaming come RTSP, WebRTC, HLS. Funziona anche in termini di tempo reale e ridimensionamento.

Quindi, Kurento non supporta RTMP che viene utilizzato su Youtube o Twitch ora. Uno dei problemi con me è il numero di utenti simultanei a questo.

Spero che aiuti.

Poiché peer1 è solo il peer che invoca getUserMedia (), ovvero peer1 crea una stanza.

1. Quindi, peer1 acquisisce i media e avvia la stanza.
2. peer2 si unisce alla stanza e riceve il flusso (dati) da peer1 e apre anche la connessione parallela denominata "connessione peer2"
3. Quando peer3 si unisce alla stanza e ottiene il flusso (dati) da peer2 e apre anche la connessione parallela denominata "connessione peer3" e così via.

Questo processo continua man mano che molti peer si connettono tra loro.

Quindi, in questo modo una singola trasmissione può essere trasferita su utenti illimitati senza problemi di larghezza di banda / utilizzo della CPU.

Infine, tutto quanto sopra contenuto è un riferimento da Link .