WebRTC - skalierbares Live-Stream-Broadcasting / Multicasting

PROBLEM:

WebRTC bietet Peer-to-Peer-Video- / Audioverbindungen. Es ist perfekt für P2P-Anrufe, Hangouts. Aber was ist mit Rundfunk (eins zu viele, zum Beispiel 1 zu 10000)?

Nehmen wir an, wir haben einen Sender "B" und zwei Teilnehmer "A1", "A2". Natürlich scheint es lösbar zu sein: Wir verbinden einfach B mit A1 und dann B mit A2. Also sendet B einen Video- / Audiostream direkt an A1 und einen weiteren Stream an A2. B sendet Streams zweimal.

Stellen wir uns nun vor, es gibt 10000 Teilnehmer: A1, A2, ..., A10000. Dies bedeutet, dass B 10000 Streams senden muss. Jeder Stream hat eine Geschwindigkeit von ~ 40 KB / s, was bedeutet, dass B eine ausgehende Internetgeschwindigkeit von 400 MB / s benötigt, um diese Sendung aufrechtzuerhalten. Inakzeptabel.

URSPRÜNGLICHE FRAGE (OBSOLETE)

Ist es irgendwie möglich, dies zu lösen, sodass B nur einen Stream auf einem Server sendet und die Teilnehmer diesen Stream einfach von diesem Server abrufen? Ja, dies bedeutet, dass die Ausgangsgeschwindigkeit auf diesem Server hoch sein muss, aber ich kann sie beibehalten.

Oder bedeutet dies vielleicht, die WebRTC-Idee zu ruinieren?

ANMERKUNGEN

Flash funktioniert nicht für meine Anforderungen gemäß schlechtem UX für Endkunden.

LÖSUNG (NICHT WIRKLICH)

26.05.2015 - Derzeit gibt es keine solche Lösung für skalierbares Broadcasting für WebRTC, bei der Sie überhaupt keine Medienserver verwenden. Es gibt sowohl serverseitige als auch hybride Lösungen (p2p + serverseitige Lösungen, abhängig von unterschiedlichen Bedingungen) auf dem Markt.

Es gibt zwar einige vielversprechende Technologien wie https://github.com/muaz-khan/WebRTC-Scalable-Broadcast, aber sie müssen diese möglichen Probleme beantworten: Latenz, allgemeine Stabilität der Netzwerkverbindung, Skalierbarkeitsformel (sie sind wahrscheinlich nicht unendlich skalierbar ).

VORSCHLÄGE

1. Verringern Sie die CPU / Bandbreite, indem Sie sowohl Audio- als auch Video-Codecs optimieren.
2. Holen Sie sich einen Medienserver.

Da hier so ziemlich alles behandelt wurde, ist das, was Sie hier versuchen, mit einfachem, altmodischem WebRTC (ausschließlich Peer-to-Peer) nicht möglich. Denn wie bereits erwähnt, verhandeln WebRTC-Verbindungen die Verschlüsselungsschlüssel neu, um Daten für jede Sitzung zu verschlüsseln. Ihr Sender (B) muss seinen Stream also tatsächlich so oft hochladen, wie Teilnehmer anwesend sind.

Es gibt jedoch eine recht einfache Lösung, die sehr gut funktioniert: Ich habe sie getestet, sie wird als WebRTC-Gateway bezeichnet. Janus ist ein gutes Beispiel. Es ist komplett Open Source ( Github Repo hier ).

Dies funktioniert wie folgt: Ihr Sender kontaktiert das Gateway (Janus), das WebRTC spricht . Es gibt also eine Schlüsselverhandlung: B überträgt sicher (verschlüsselte Streams) an Janus.

Wenn sich die Teilnehmer verbinden, stellen sie erneut eine Verbindung zu Janus her: WebRTC-Aushandlung, gesicherte Schlüssel usw. Von nun an sendet Janus die Streams an alle Teilnehmer zurück.

Dies funktioniert gut, da der Sender (B) seinen Stream nur einmal zu Janus hochlädt. Jetzt dekodiert Janus die Daten mit seinem eigenen Schlüssel und hat Zugriff auf die Rohdaten (RTP-Pakete) und kann diese Pakete an jeden Teilnehmer zurücksenden (Janus kümmert sich für Sie um die Verschlüsselung). Und da Sie Janus auf einen Server stellen, hat er eine große Upload-Bandbreite, sodass Sie auf viele Peers streamen können.

Ja, es handelt sich zwar um einen Server, aber dieser Server spricht WebRTC, und Sie "besitzen" ihn: Sie implementieren den Janus-Teil, damit Sie sich keine Sorgen über Datenkorruption oder Man in der Mitte machen müssen. Natürlich, es sei denn, Ihr Server ist kompromittiert. Aber Sie können so viel tun.

Um Ihnen zu zeigen, wie einfach die Verwendung ist, haben Sie in Janus eine Funktion namens incoming_rtp()(und incoming_rtcp()), die Sie aufrufen können und die Ihnen einen Zeiger auf die rt (c) p-Pakete gibt. Sie können es dann an jeden Teilnehmer senden (sie werden in sessionsJanus gespeichert , was die Verwendung sehr einfach macht). Suchen Sie hier nach einer Implementierung der incoming_rtp()Funktion . In einigen Zeilen unten sehen Sie, wie die Pakete an alle Teilnehmer übertragen werden, und hier sehen Sie die tatsächliche Funktion zum Weiterleiten eines RTP-Pakets.

Es funktioniert alles ziemlich gut, die Dokumentation ist ziemlich einfach zu lesen und zu verstehen. Ich schlage vor, Sie beginnen mit dem "echotest" Beispiel, es ist das einfachste und Sie können das Innenleben von Janus verstehen. Ich schlage vor, dass Sie die Echo-Testdatei bearbeiten, um Ihre eigene zu erstellen, da viel redundanter Code geschrieben werden muss. Sie können also genauso gut von einer vollständigen Datei ausgehen.

Habe Spaß! Hoffe ich habe geholfen.

Wie @MuazKhan oben erwähnt:

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

funktioniert in Chrom und noch keine Audioübertragung, aber es scheint eine erste Lösung zu sein.

Eine skalierbare WebRTC-Peer-to-Peer-Broadcast-Demo.

Dieses Modul initialisiert einfach socket.io und konfiguriert es so, dass einzelne Broadcasts ohne Probleme mit der Bandbreite / CPU-Auslastung über unbegrenzte Benutzer weitergeleitet werden können. Alles passiert Peer-to-Peer!

Dies sollte auf jeden Fall möglich sein.
Andere können dies ebenfalls erreichen: http://www.streamroot.io/

AFAIK Die einzige aktuelle Implementierung, die relevant und ausgereift ist, ist Adobe Flash Player, der seit Version 10.1 P2P-Multicast für Peer-to-Peer-Videoübertragungen unterstützt.

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

Eine "skalierbare" Übertragung ist im Internet nicht möglich, da das IP-UDP-Multicasting dort nicht zulässig ist. Aber theoretisch ist es in einem LAN möglich.
Das Problem mit Websockets ist, dass Sie keinen Zugriff auf RAW UDP haben und dies nicht zulässig ist.
Das Problem mit WebRTC ist, dass die Datenkanäle eine Form von SRTP verwenden, bei der jede Sitzung einen eigenen Verschlüsselungsschlüssel hat . Also , wenn jemand „erfindet“ oder eine API eine Art und Weise ermöglicht, gemeinsam einen Sitzungsschlüssel zwischen allen Clients ist die Multicast - nutzlos.

Es gibt die Lösung der Peer-Assisted Delivery, was bedeutet, dass der Ansatz hybride ist. Sowohl Server als auch Peers helfen bei der Verteilung der Ressource. Das ist der Ansatz, den peer5.com und peercdn.com gewählt haben.

Wenn wir speziell über Live-Übertragungen sprechen, sieht es ungefähr so ​​aus:

1. Der Sender sendet das Live-Video an einen Server.
2. Der Server speichert das Video (wandelt es normalerweise auch in alle relevanten Formate um).
3. Es werden Metadaten zu diesem Live-Stream erstellt, die mit HLS oder HDS oder MPEG_DASH kompatibel sind
4. Verbraucher navigieren dort zum entsprechenden Live-Stream. Der Player erhält die Metadaten und weiß, welche Teile des Videos als Nächstes abgerufen werden sollen.
5. Gleichzeitig wird der Verbraucher mit anderen Verbrauchern verbunden (über WebRTC).
6. Anschließend lädt der Player den entsprechenden Block entweder direkt vom Server oder von Peers herunter.

Das Befolgen eines solchen Modells kann abhängig von der Bitrate des Live-Streams und der kollaborativen Aufwärtsverbindung der Zuschauer bis zu ~ 90% der Serverbandbreite einsparen.

Haftungsausschluss: Der Autor arbeitet bei Peer5

Mein Master konzentriert sich auf die Entwicklung eines hybriden CDN / P2P-Live-Streaming-Protokolls mit WebRTC. Ich habe meine ersten Ergebnisse unter http://bem.tv veröffentlicht

Alles ist Open Source und ich suche Mitwirkende! :-)

Die Antwort von Angel Genchev scheint richtig zu sein, es gibt jedoch eine theoretische Architektur, die eine Übertragung mit geringer Latenz über WebRTC ermöglicht. Stellen Sie sich vor, B (Sender) strömt zu A1 (Teilnehmer 1). Dann verbindet sich A2 (Teilnehmer 2). Anstatt von B nach A2 zu streamen, beginnt A1 mit dem Streaming von Videos, die von B nach A2 empfangen werden. Wenn A1 die Verbindung trennt, beginnt A2 mit dem Empfang von B.

Diese Architektur könnte funktionieren, wenn keine Latenzen und Verbindungszeitlimits vorliegen. Theoretisch ist es also richtig, aber praktisch nicht.

Im Moment verwende ich eine serverseitige Lösung.

Auf dem Markt sind einige Lösungen für skalierbare WebRTC-Lösungen verfügbar. Sie bieten skalierbares Webrtc-Streaming mit geringer Latenz. Hier sind einige Beispiele. Janus , Jitsi , Wowza , Red5pro , Ant Media Server

Ich bin Entwickler für Ant Media Server . Wir bieten sowohl Community- als auch Enterprise-Editionen an, einschließlich Android- und iOS-SDK. Lassen Sie uns wissen, ob wir Ihnen irgendwie helfen können.

Sie beschreiben die Verwendung von WebRTC mit einer Eins-zu-Viele-Anforderung. WebRTC wurde für Peer-to-Peer-Streaming entwickelt. Es gibt jedoch Konfigurationen, mit denen Sie von der geringen Latenz von WebRTC profitieren und gleichzeitig Videos für viele Zuschauer bereitstellen können.

Der Trick besteht darin, den Streaming-Client nicht mit jedem Betrachter zu besteuern und, wie Sie bereits erwähnt haben, über einen "Relay" -Medienserver zu verfügen. Sie können dies selbst erstellen, aber ehrlich gesagt besteht die beste Lösung häufig darin, etwas wie das WebRTC-Streaming-Produkt von Wowza zu verwenden .

Um effizient von einem Telefon zu streamen, können Sie das GoCoder SDK von Wowza verwenden. Meiner Erfahrung nach funktioniert jedoch ein erweitertes SDK wie StreamGears am besten.

Ich entwickle ein WebRTC-Rundfunksystem mit dem Kurento Media Server . Kurento unterstützt verschiedene Arten von Streaming-Protokollen wie RTSP, WebRTC und HLS. Es funktioniert auch in Bezug auf Echtzeit und Skalierung.

Daher unterstützt Kurento kein RTMP, das derzeit in Youtube oder Twitch verwendet wird. Eines der Probleme bei mir ist die Anzahl der Benutzer, die gleichzeitig damit arbeiten.

Hoffe es hilft.

Da Peer1 nur der Peer ist, der getUserMedia () aufruft, erstellt Peer1 einen Raum.

1. Peer1 erfasst also Medien und startet den Raum.
2. Peer2 tritt dem Raum bei und erhält Stream (Daten) von Peer1 sowie eine offene Parallelverbindung mit dem Namen "Peer2-Verbindung".
3. Wenn Peer3 dem Raum beitritt und Stream (Daten) von Peer2 erhält und auch eine parallele Verbindung mit dem Namen "Peer3-Verbindung" usw. öffnet.

Dieser Prozess dauert an, da viele Peers miteinander verbunden werden.

Auf diese Weise kann eine einzelne Sendung ohne Probleme mit der Bandbreite / CPU-Auslastung über unbegrenzte Benutzer übertragen werden.

Schließlich ist alles oben Genannte eine Referenz von Link .