WebRTC: trasmissione / multicasting in streaming live scalabile


114

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.

3
"L'unico modo per creare un'app scalabile è utilizzare una soluzione lato server". Sembra abbastanza chiaro ... Per quanto riguarda WebRTC, non è mai stato inteso per trasmissioni su larga scala. Usa qualcosa che supporti il ​​multicast per questo, o se devi andare su Internet, una connessione uno-a-uno basata su server, poiché gli ISP non instradano il multicast.
Dark Falcon

1
Perché non utilizzare WebRTC da client a server? Il problema è nella distribuzione, in quanto la connessione del client non può gestirlo, quindi invia uno steam al server e trasmette ai client da lì. La larghezza di banda sarà costosa, ma non puoi aggirare né l'invio di un singolo flusso a ciascun utente né l'invio di un flusso da parte dell'utente ad altri utenti.
Dark Falcon

1
Ci sono almeno due società di cui sono a conoscenza che stanno cercando di fornire video p2p basati su webrtc : affovi.com/rtcplayer.html - principalmente per video live; e peer5.com - principalmente per VOD.
Svetlin Mladenov

1
@igorpavlov Potresti voler controllare: github.com/muaz-khan/WebRTC-Scalable-Broadcast Anche se funziona solo in Chrome e non è ancora stata trasmessa l'audio.
Muaz Khan

4
Non c'è modo di raggiungere quella scalabilità senza un MCU di qualche tipo. WebRTC è progettato per essere peer-to-peer. Non puoi trasmettere da esso senza assolutamente sbattere la tua emittente (con una connessione peer unica per ogni streaming, che stagista, è un altro flusso che viene codificato). Per quanto riguarda l'inoltro dei media da peer-to-peer, potrebbe essere possibile, ma ovviamente ciò comporterebbe una latenza aggiuntiva per ogni peer aggiunto allo stream in un secondo momento. Per qualità e scalabilità, avere un server MCU webrtc è l'unica soluzione realistica.
Benjamin Trent

Risposte:


66

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.


1
È vero che al momento non funziona in Safari (o in qualsiasi browser che non supporta WebRTC?). Qualcuno sa di una soluzione ibrida in cui trasmetti dal browser al server utilizzando WebRTC, quindi transcodifica il video in HLS / HDS (o anche RTMP) per adattarlo a un sistema di trasmissione tradizionale?
Ben

1
@ Ben sì, non funziona con i browser che non supportano WebRTC. Ai tempi (quando scrivo questo) Safari chiaramente non lo supportava. Oggi invece non ho controllato. Ma penso ancora che non supportino WebRTC (da confermare, però). Per quanto riguarda l'utilizzo in un sistema ibrido, questo è totalmente possibile, in realtà è quello che ho fatto per l'azienda in cui ho lavorato; come hai detto, ho trasmesso dal browser al server e da lì ho costruito e collegato una pipeline GStreamer per transcodificare il feed. Puoi farlo anche tu!
nschoe

qualche idea sul jitsi? anche jitisi è lo stesso?
ishandutta2007

@nschoe È meglio che usare websocket per fare lo stesso?
Navigateur

In realtà stai spiegando come funziona una SFU (Selective Forwarding Unit). Puoi fare lo stesso con mediasoup
Dirk V

11

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!

inserisci qui la descrizione dell'immagine

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


1
Questa roba mi sembra un po 'datata. Eventuali aggiornamenti o pensieri su questa idea?
igorpavlov

Inoltre, risolve comunque i problemi di latenza? Ad esempio, Peer1 comunica con Peer5 e Peer2 alla fine perde la connessione. O questa architettura è valida solo per la LAN?
igorpavlov

Inoltre, Streamroot è simile a Peer5?
igorpavlov

7

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 .


1
Le persone non uccidono la tecnologia. La tecnologia si sta uccidendo fornendo una UX molto scarsa, specialmente quando si consente il microfono / la fotocamera. È qui che vince getusermedia.
igorpavlov

Non potrei essere più d'accordo.
Tom

A parte il cattivo ux, sarebbe questa la soluzione? Server di meno?
rubo77

6

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.


1
ma le chat funzionano già con WebRTC, quindi tutti vedono ogni messaggio, quindi uno a molti dovrebbe funzionare anche per i video in qualche modo
rubo77

@ rubo77 I dati inviati con il messaggio di testo non sono niente in confronto alla velocità e alla quantità di dati inviati con i flussi video. Quindi le chat possono facilmente contenere più utenti contemporaneamente
Dirk V

5

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


Grazie. Conosco peer5 e trovo che sia una soluzione piuttosto interessante. Tuttavia, lo scopo di questa domanda era trovare una soluzione assolutamente senza server (solo STUN / TURN consentito).
igorpavlov

5

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


Usi qualche tipo di MCU software lato server?
igorpavlov

In realtà sto usando alcuni componenti lato server di persone rtcio: github.com/rtc-io
flavioribeiro

1
Sembra che tu usi i loro componenti per la segnalazione. Che ne dici dello streaming video lato server? O la tua soluzione è assolutamente P2P?
igorpavlov

scusa per il lungo ritardo nel risponderti @igorpavlov, sto usando EvoStream per segmentare i video e sto riproducendo in loop una sorgente video e puntando a EvoStream usando l'encoder Elemental.
flavioribeiro

È un fornitore di server multimediali. Più efficiente? Probabilmente. È quello che sto cercando? No.
igorpavlov

2

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.


E la velocità del flusso nella soluzione lato server? Si prega di condividere.
user2003356

Soluzione lato server significa? Cosa hai usato? Sarebbe utile per la mia ricerca. Si prega di condividere. Grazie.
user2003356

Soluzione lato server significa Opentok di Tokbox. Non li pubblicizzo, ci sono tantissime soluzioni di questo tipo sul mercato, ma rimango fedele a questa. Funziona come un server multimediale. PS Cosa intendi per comunicazione multipartitica? Non lo capisco.
igorpavlov

@igorpavlov potresti fornire un elenco di aziende che forniscono webrtc lato server? Conosco solo Flashphoner e Opentok. Grazie
Ramil Amerzyanov

Sarei curioso di vedere se questo sarebbe effettivamente in scala. Ci saranno sicuramente problemi di ridimensionamento con la latenza su gruppi ENORMI (1000+) ma se ce ne sono solo 5-10 immagino che funzionerebbe abbastanza bene, ma sarebbe necessario un po 'di lavoro con i piedi se qualcuno nel mezzo della catena "peer" "lascia e ricollegare tutti i coetanei successivi se si tratta di una singola catena sarebbe un enorme overhead. Potrebbe essere meglio usare una struttura ad albero binaria / ternaria.
Benjamin Trent

2

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.


1

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.


1

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.


0

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 .


1
Questo approccio è già stato menzionato, ma potrebbe non funzionare nel mondo reale. Come Peer3, perché dovrei preoccuparmi delle prestazioni di larghezza di banda del Peer2? Ovviamente, Peer3 potrebbe ripiegare su Peer1 se Peer2 lascia la catena, ma ciò causerà tonnellate di interruzioni del flusso, ricollegamenti, ecc. Più mi trovo nella catena, più soffrirò. Quindi, sì, potrebbe funzionare su LAN, ma probabilmente è così.
igorpavlov

La trasmissione parallela non si occupa della larghezza di banda e se una volta stabilita la connessione da peer3 a peer1 tramite peer2 e tale che peer2 fallback, peer3 rimane connesso a peer1.
susan097

Non sono sicuro di aver capito. In realtà non mi riferivo al collegamento, ora lasciatemi fare riferimento. Questo link github.com/muaz-khan/WebRTC-Scalable-Broadcast ha un'immagine nella sezione "Come funziona?" sezione. Questa immagine ti dice chiaramente che una volta, diciamo che Peer5 si disconnette, Peer8,9 e 10 vengono disconnessi dalla trasmissione. Dovranno connettersi a Peer2 o Peer6, ma ciò causerà ritardi. Inoltre, questo progetto non ha né collaboratori né attività.
igorpavlov
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.