it-swarm.com.de

WebRTC - skalierbares Live-Streaming/Multicasting

PROBLEM:

WebRTC bietet Peer-to-Peer-Video-/Audio-Verbindungen. Es ist perfekt für P2P-Anrufe, Hangouts. Aber was ist mit Broadcasting (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 nur B mit A1 und dann B mit A2. Also sendet B den Video-/Audio-Stream direkt an A1 und einen weiteren Stream an A2. B sendet zweimal Streams.

Nun stellen wir uns vor, es gibt 10000 Teilnehmer: A1, A2, ..., A10000. Das bedeutet, dass B 10000 Streams senden muss. Jeder Stream ist ~ 40 KB/s, was bedeutet, dass B eine ausgehende Internetgeschwindigkeit von 400 MB/s benötigt, um diese Übertragung aufrechtzuerhalten. Inakzeptabel.

URSPRÜNGLICHE FRAGE (OBSOLETE)

Kann das Problem irgendwie gelöst werden, so dass B nur einen Stream auf einem Server sendet und die Teilnehmer diesen Stream einfach von diesem Server abziehen? Ja, das bedeutet, dass die ausgehende Geschwindigkeit auf diesem Server hoch sein muss, aber ich kann sie aufrechterhalten. 

Oder vielleicht bedeutet das, die Idee des WebRTC zu ruinieren?

ANMERKUNGEN

Flash funktioniert nicht für meine Bedürfnisse, wie für schlechte Endgeräte für Endkunden.

LÖSUNG (NICHT WIRKLICH)

26.05.2015 - Eine solche Lösung für skalierbares Broadcasting für WebRTC gibt es derzeit nicht, wenn Sie keine Medienserver verwenden. Es gibt serverseitige Lösungen sowie Hybrid (p2p + serverseitig je nach Bedingungen) auf dem Markt.

Es gibt einige vielversprechende Techniker wie https://github.com/muaz-khan/WebRTC-Scalable-Broadcast , aber sie müssen die möglichen Probleme beantworten: Latenzzeit, Stabilität der Netzwerkverbindung, Skalierbarkeits-Formel (sie sind es nicht wahrscheinlich 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.
97
igorpavlov

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. Wie bereits erwähnt, werden bei WebRTC-Verbindungen für jede Sitzung Verschlüsselungsschlüssel neu ausgehandelt, um Daten 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 spricht WebRTC. Es gibt also eine Schlüsselverhandlung: B überträgt sicher (verschlüsselte Streams) an Janus.

Wenn Teilnehmer eine Verbindung herstellen, 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 entschlüsselt Janus die Daten mit seinem eigenen Schlüssel und hat Zugriff auf die Rohdaten (das heißt es, 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, verfügt es über eine große Upload-Bandbreite, sodass Sie Streams an viele Peers senden können.

Also ja, es beinhaltet einen Server, aber dieser Server spricht WebRTC, und Sie "besitzen" es: Sie implementieren den Janus-Teil, so dass Sie es nicht tun müssen sich Sorgen über Datenkorruption oder Menschen in der Mitte machen. Nun, es sei denn, Ihr Server ist kompromittiert. Aber Sie können so viel tun.

Um Ihnen zu zeigen, wie einfach es ist, Janus zu benutzen, haben Sie eine Funktion namens incoming_rtp() (und incoming_rtcp()), die Sie aufrufen können und die Ihnen einen Zeiger auf das RT gibt (c ) p Pakete. Sie können es dann an jeden Teilnehmer senden (sie sind in sessions gespeichert, was Janus sehr einfach macht). Hier finden Sie eine Implementierung der Funktion incoming_rtp() , ein paar Zeilen weiter unten Sie können sehen, wie die Pakete an alle Teilnehmer gesendet werden und hier sehen Sie die eigentliche 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 "echotesten" Beispiel, es ist das einfachste und Sie können das Innenleben von Janus verstehen. Ich schlage vor, Sie bearbeiten die Echo-Test-Datei, um sie selbst zu erstellen, da viel redundanter Code zu schreiben ist. Sie können also auch von einer vollständigen Datei ausgehen.

Habe Spaß! Hoffe ich habe geholfen.

50
nschoe

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 1. lösung zu sein.

Eine skalierbare Peer-to-Peer-Demo für WebRTC.

Dieses Modul initialisiert einfach socket.io und konfiguriert es auf eine Art Diese einzelne Sendung kann ohne .__ an unbegrenzte Benutzer weitergegeben werden. Probleme mit der Bandbreite/CPU-Nutzung. Alles passiert Peer-to-Peer!

enter image description here

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

9
rubo77

AFAIK Die einzig aktuelle und ausgereifte Implementierung von AFAIK ist Adobe Flash Player, der seit Version 10.1 p2p-Multicast für Peer-to-Peer-Videoübertragung unterstützt.

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

7
Tom

Im Internet ist kein "skalierbarer" Broadcast möglich, da das IP UDP-Multicasting dort nicht zulässig ist. Theoretisch ist das aber über ein LAN möglich.
Das Problem mit Websockets besteht darin, dass Sie von Entwurf aus nicht auf RAW UDP zugreifen können und dies nicht zulässig ist .
Das Problem bei WebRTC ist, dass seine Datenkanäle eine Form von SRTP verwenden, bei der jede Sitzung einen eigenen encrypt - Schlüssel hat. Wenn also nicht jemand "erfindet" oder eine API die Möglichkeit bietet, einen Sitzungsschlüssel zwischen allen Clients zu share zu teilen, ist das Multicast unbrauchbar.

6
Angel Genchev

Meine Meister konzentrieren 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 nach Mitwirkenden! :-)

5
flavioribeiro

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 das ungefähr so ​​aus:

  1. Der Sender sendet das Live-Video an einen Server.
  2. Der Server speichert das Video (normalerweise codiert es auch in alle relevanten Formate).
  3. Es werden Metadaten zu diesem Livestream erstellt, die mit HLS oder HDS oder MPEG_DASH kompatibel sind
  4. Konsumenten stöbern im relevanten Live-Stream, der Player erhält die Metadaten und weiß, welche Teile des Videos als nächstes zu erhalten sind.
  5. Gleichzeitig wird der Verbraucher mit anderen Verbrauchern verbunden (über WebRTC)
  6. Dann lädt der Player den betreffenden Block entweder direkt vom Server oder von Kollegen herunter.

Wenn Sie einem solchen Modell folgen, können Sie - abhängig von der Bitrate des Live-Streams und dem gemeinsamen Uplink der Zuschauer - bis zu 90% der Bandbreite des Servers einsparen.

haftungsausschluss: Der Autor arbeitet bei Peer5

5
shacharz

Die Antwort von Angel Genchev scheint richtig zu sein, es gibt jedoch eine theoretische Architektur, die eine Übertragung mit geringer Latenzzeit über WebRTC ermöglicht. Stellen Sie sich vor, B (Sender) strömt nach A1 (Teilnehmer 1). Dann verbindet sich A2 (Teilnehmer 2). Anstelle von Streaming von B nach A2 beginnt A1 mit dem Streaming-Video von B nach A2. Wenn A1 getrennt wird, beginnt A2 mit dem Empfang von B.

Diese Architektur könnte funktionieren, wenn keine Latenzzeiten und Verbindungszeitüberschreitungen vorliegen. Theoretisch ist es richtig, aber praktisch nicht.

Im Moment verwende ich eine serverseitige Lösung. 

2
igorpavlov

Es gibt einige auf dem Markt verfügbare Lösungen für skalierbare WebRTC-Lösungen. Sie bieten ein 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-Edition an, einschließlich Android und iOS SDK. Lassen Sie uns wissen, ob wir Ihnen irgendwie helfen können. 

1
faraway

Für dieses Problem gibt es mehrere Lösungen. Es bietet sowohl eine niedrige Latenz als auch eine extrem niedrige Latenz.

Überprüfen Sie dies mittlerer Beitrag

Für eine skalierbare, extrem niedrige Latenz können Sie ant media server versuchen

1
faraway

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. Ein Problem bei mir ist die Anzahl der Benutzer, die gleichzeitig damit arbeiten.

Ich hoffe es hilft.

0
imalice

Als peer1 ist nur der Peer, der getUserMedia () aufruft, das heißt, peer1 erstellt einen Raum.

  1. So erfasst peer1 Medien und startet Raum.
  2. peer2 tritt in den Raum ein und holt Stream (Daten) von peer1 sowie eine offene Parallelverbindung mit dem Namen "peer2-connection".
  3. Wenn sich peer3 dem Raum anschließt und Daten (Daten) von peer2 abruft und eine parallele Verbindung mit dem Namen 'peer3-Verbindung' usw. öffnet.

Dieser Prozess wird kontinuierlich fortgesetzt, da viele Peer miteinander verbunden werden.

Auf diese Weise kann ein einzelner Broadcast ohne Probleme mit der Bandbreite/CPU-Nutzung über eine unbegrenzte Anzahl von Benutzern übertragen werden.

Schließlich ist alles, was oben enthalten ist, eine Referenz von Link .

0
susan097

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 Latenzzeit von WebRTC profitieren können, während Sie Video für viele Zuschauer bereitstellen. 

Der Trick besteht darin, den Streaming-Client nicht mit jedem Zuschauer zu besteuern und, wie Sie bereits erwähnt haben, einen "Relay" -Medienserver. Sie können dies selbst erstellen, aber die beste Lösung ist oft die Verwendung von Wowzas WebRTC Streaming-Produkt .

Um effizient von einem Telefon aus zu streamen, können Sie Wowzas GoCoder SDK verwenden, aber meiner Erfahrung nach funktioniert ein besseres SDK wie StreamGears am besten.

0
videoking