2015-04-24 28 views
8

Qualcuno sa quali sono i requisiti minimi della larghezza di banda WebRTC? Sono interessato a quali sono i valori con o senza video e per diverse risoluzioni video. Sono particolarmente interessato a una conferenza di due parti, ma se conosci i valori per partito è anche un bene.Requisiti di larghezza di banda WebRTC

Se si dispone di metriche effettive è bello, ma anche se si sa come posso teoricamente calcolare questo è anche un bene.

Inoltre, diversi browser hanno requisiti di larghezza di banda diversi?

risposta

14

I requisiti di larghezza di banda sono quasi gli stessi del requisito di larghezza di banda per opus e vp8. L'audio in tempo reale ha in genere un bitrate di 40-200kbit/s. Il video richiede almeno 200 kbit/s (500 kbit/s se vuoi vedere i volti delle persone).

Secondo webrtc-experiment la larghezza di banda minima per opus è 6kbit/se per vp8 100kbits/s. Quindi, in totale, ciò rende 106kbit/s, ma quando si tiene conto del sovraccarico dello stack di protocolli webrtc e delle condizioni di rete costantemente variabili indicherei che 200kbit/s è il minimo se si vogliono video e audio stabili.

Chrome e Firefox utilizzano entrambi opus e vp8, quindi i requisiti di larghezza di banda dovrebbero essere gli stessi. Anche se non ho dati rigidi per dimostrarlo.

È possibile visualizzare il traffico corrente generato da webrtc passando a chrome: // webrtc-internals e ispezionando tutti i grafici.

+0

Sai se l'esperimento webrtc fa riferimento solo a Chrome o riguarda anche altri browser? –

+0

opus e vp8 sono separati non collegati ai progetti di webrtc quindi i risultati negli esperimenti di webrtc relativi a queste due tecnologie dovrebbero essere indipendenti dal browser. Non so del resto dei risultati. Immagino che si riferiscano sia a Chrome sia a Firefox. Dopo che tutte le due implementazioni hanno condiviso un po 'di codice e il test sembra abbastanza completo. –

1

Per le conferenze a due parti, 500 kbit/s per una buona qualità della conferenza dovrebbero essere sufficienti (per flusso, quindi 1 Mbit/s carico sulla linea di un utente). Sono in linea con l'altra risposta a riguardo.

Tuttavia, per la larghezza di banda WebRTC di più parti possono essere colli di bottiglia non solo a causa della larghezza di banda Internet dei partecipanti, ma anche a causa dei potenziali limiti di larghezza di banda di un server di inoltro dei media TURN, se ne si utilizza uno - che è necessario in assenza di connessioni P2P sono possibili a causa di configurazioni NAT difficili. (All the details here.)

ho tentato un calcolo approssimativo del numero di utenti che un server sua volta può servire prima di maxing sua larghezza di banda:

  • Diciamo che abbiamo 100 Mbit/s di larghezza di banda del server in totale (in + out), e vogliamo che al massimo 60 Mbit/s siano utilizzabili per il traffico WebRTC.

  • Così, ad esempio, durante la configurazione del server TURBO coturn, avremmo impostato il flusso di input e di output ciascuno a 30 Mbit/s (3.750.000 byte/s, utilizzando bps-capacity=3750000).

  • Il flusso in uscita si verificherà il carico maggiore, perché data n partecipanti, ci saranno flusso di ingresso video e n-1 flussi di uscita video per partecipante per il server TURN da gestire. Significa che il collo di bottiglia sarà il flusso di output combinato a 30 Mbit/s.

  • Nel caso peggiore (dove non sono possibili connessioni P2P negoziate STUN), questa larghezza di banda è sufficiente per: 30 Mbit/s/500 kbit/(s * stream) = 60 flussi video.

  • Dato n partecipanti, ci saranno n-1 flussi di uscita per partecipante, il che significa un totale di n * (n-1) = n^2 - n flussi. Il nostro massimo 60 flussi sono quindi sufficienti per: n^2 - n = 60 < => n = 8,26 = ~ 8 partecipanti (calculation).

Non sono ancora sicuro di quanto sia accurato - lo proverò in pratica e riferirò.

Problemi correlati