WebRTC - skalierbares Live-Stream-Broadcasting / Multicasting

114

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.
igorpavlov
quelle
3
"Die einzige Möglichkeit, eine skalierbare App zu erstellen, ist die Verwendung einer serverseitigen Lösung." Das scheint ziemlich klar zu sein ... WebRTC war nie für große Sendungen gedacht. Verwenden Sie dafür etwas, das Multicast unterstützt, oder, wenn Sie über das Internet gehen müssen, eine serverbasierte Eins-zu-Eins-Verbindung, da ISPs Multicast nicht weiterleiten.
Dark Falcon
1
Warum nicht WebRTC von Client zu Server verwenden? Das Problem liegt in der Verteilung, da die Verbindung des Clients nicht damit umgehen kann. Senden Sie also einen Dampf an den Server und streamen Sie von dort zu den Clients. Die Bandbreite wird teuer sein, aber Sie können weder einen einzelnen Stream an jeden Benutzer senden noch den Stream an andere Benutzer senden lassen.
Dark Falcon
1
Es gibt mindestens zwei Unternehmen, von denen ich weiß, dass sie versuchen, eine webrtc-basierte P2P-Videobereitstellung durchzuführen : affovi.com/rtcplayer.html - hauptsächlich für Live-Videos; und peer5.com - hauptsächlich für VoD .
Svetlin Mladenov
1
@igorpavlov Vielleicht möchten Sie Folgendes überprüfen: github.com/muaz-khan/WebRTC-Scalable-Broadcast Obwohl es nur in Chrom funktioniert und noch keine Audioübertragung.
Muaz Khan
4
Es gibt keine Möglichkeit, diese Skalierbarkeit ohne eine MCU zu erreichen. WebRTC ist als Peer-to-Peer konzipiert. Sie können nicht von ihm senden, ohne Ihren Sender absolut zu verprügeln (mit einer eindeutigen Peer-Verbindung für jeden Stream, der intern ist, wird ein anderer Stream codiert). Das Weiterleiten der Medien von Peer zu Peer könnte möglich sein, aber dies würde natürlich zu einer zusätzlichen Latenz für jeden Peer führen, der später zum Stream hinzugefügt wird. Für Qualität und Skalierbarkeit ist ein webrtc MCU-Server die einzig realistische Lösung.
Benjamin Trent

Antworten:

66

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.

nschoe
quelle
1
Stimmt es, dass dies derzeit in Safari nicht funktioniert (oder in einem Browser, der WebRTC nicht unterstützt?). Kennt jemand eine Hybridlösung, bei der Sie mithilfe von WebRTC vom Browser zum Server senden und das Video dann in HLS / HDS (oder sogar RTMP) umcodieren, um es in ein herkömmliches Übertragungssystem zu integrieren?
Ben
1
@ Ben ja, es funktioniert nicht mit Browsern, die WebRTC nicht unterstützen. Damals (als ich das schreibe) hat Safari dies eindeutig nicht unterstützt. Heute habe ich allerdings nicht nachgesehen. Aber ich denke immer noch, dass sie WebRTC nicht unterstützen (muss jedoch noch bestätigt werden). Die Verwendung in einem Hybridsystem ist durchaus möglich. Genau das habe ich für das Unternehmen getan, bei dem ich gearbeitet habe. Wie Sie sagten, habe ich vom Browser auf den Server gesendet und von dort aus eine GStreamer-Pipeline erstellt und angeschlossen, um den Feed zu transkodieren. Sie können dies auch tun!
Nschoe
Irgendeine Idee über Jitsi? ist jitisi auch das gleiche?
ishandutta2007
@nschoe Ist das besser als die Verwendung von Websocket, um dasselbe zu tun?
Navigateur
Sie erklären tatsächlich, wie eine SFU (Selective Forwarding Unit) funktioniert. Sie können das gleiche mit mediasoup tun
Dirk V
11

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!

Geben Sie hier die Bildbeschreibung ein

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

rubo77
quelle
1
Dieses Zeug scheint mir ein bisschen veraltet zu sein. Irgendwelche Updates oder Gedanken zu dieser Idee?
Igorpavlov
Löst es auch Latenzprobleme? Zum Beispiel spricht Peer1 mit Peer5 und Peer2 verliert schließlich die Verbindung. Oder ist diese Architektur nur für LAN geeignet?
Igorpavlov
Ist Streamroot auch Peer5 ähnlich?
Igorpavlov
7

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 .

Tom
quelle
1
Die Leute töten die Technologie nicht. Die Technologie bringt sich selbst um, indem sie eine sehr schlechte UX bereitstellt, insbesondere wenn Mikrofone / Kameras zugelassen werden. Hier gewinnt getusermedia.
Igorpavlov
Konnte nicht mehr zustimmen.
Tom
Wäre dies, abgesehen von dem schlechten UX, die Lösung? Server weniger?
rubo77
6

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.

Engel Genchev
quelle
1
Aber Chats funktionieren bereits mit WebRTC, so dass jeder jede Nachricht sieht, so dass einer von vielen auch irgendwie für Videos arbeiten sollte
rubo77
@ rubo77 Die mit Textnachrichten gesendeten Daten sind im Vergleich zu der Rate und Menge der mit Videostreams gesendeten Daten überhaupt nichts. So können Chats leicht mehr Benutzer gleichzeitig enthalten
Dirk V
5

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

Shacharz
quelle
Danke dir. Ich kenne Peer5 und finde es eine ziemlich attraktive Lösung. Der Zweck dieser Frage war jedoch, eine Lösung zu finden, die absolut serverlos ist (nur STUN / TURN erlaubt).
Igorpavlov
5

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

flavioribeiro
quelle
Verwenden Sie irgendeine Art von serverseitiger Software, eine Art MCU?
Igorpavlov
Ich benutze tatsächlich einige serverseitige Komponenten von rtcio people: github.com/rtc-io
flavioribeiro
1
Es sieht so aus, als würden Sie ihre Komponenten für die Signalisierung verwenden. Wie wäre es mit serverseitigem Video-Streaming? Oder ist Ihre Lösung absolut P2P?
Igorpavlov
Entschuldigung für die lange Verzögerung bei der Beantwortung von @igorpavlov. Ich verwende EvoStream, um die Videos zu segmentieren. Ich schleife eine Videoquelle und zeige mit dem Elemental-Encoder auf EvoStream.
Flavioribeiro
Es ist ein Medienserver-Anbieter. Effizienter? Wahrscheinlich. Ist es das, wonach ich suche? Nr.
igorpavlov
2

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.

igorpavlov
quelle
Was ist mit der Stream-Geschwindigkeit in der serverseitigen Lösung? Bitte teilen.
user2003356
Serverseitige Lösung bedeutet? Was hast du benutzt? Es wäre hilfreich für meine Forschung. Bitte teilen. Vielen Dank.
user2003356
Serverseitige Lösung bedeutet Opentok von Tokbox. Ich mache keine Werbung für sie, es gibt Unmengen solcher Lösungen auf dem Markt, aber ich bleibe bei dieser. Es funktioniert wie ein Medienserver. PS Was meinst du mit Mehrparteienkommunikation? Ich verstehe es nicht
Igorpavlov
@igorpavlov Können Sie eine Liste der Unternehmen angeben, die serverseitiges Webrtc anbieten? Ich kenne nur Flashphoner und Opentok. Vielen Dank
Ramil Amerzyanov
Ich wäre gespannt, ob sich das tatsächlich skalieren lässt. Es gibt sicherlich Skalierungsprobleme mit der Latenz bei RIESIGEN Gruppen (1000+), aber wenn es nur 5-10 gibt, würde ich mir vorstellen, dass es ganz gut funktionieren würde, aber wenn jemand in der Mitte der Peer-Kette wäre, wäre eine ausgefallene Fußarbeit erforderlich "Das Verlassen und Wiederverbinden aller nachfolgenden Kollegen, wenn es sich nur um eine einzelne Kette handelt, wäre ein RIESIGES Problem. Möglicherweise ist es besser, eine binäre / ternäre Baumstruktur zu verwenden.
Benjamin Trent
2

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.

weit weg
quelle
1

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.

Videoking
quelle
1

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.

imalice
quelle
0

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 .

susan097
quelle
1
Dieser Ansatz wurde bereits erwähnt, funktioniert jedoch möglicherweise nicht in der realen Welt. Warum sollte ich mich als Peer3 für die Bandbreitenleistung des Peer2 interessieren? Natürlich kann Peer3 auf Peer1 zurückgreifen, wenn Peer2 die Kette verlässt, aber das führt zu Tonnen von Stream-Unterbrechungen, Wiederverbindungen usw. Je weiter ich in der Kette bin, desto mehr werde ich leiden. Also, ja, funktioniert vielleicht im LAN, aber das ist es wahrscheinlich.
Igorpavlov
Paralleles Broadcasting kümmert sich nicht um die Bandbreite, und wenn die Verbindung von Peer3 zu Peer1 über Peer2 hergestellt ist und Peer2 zurückfällt, bleibt Peer3 mit Peer1 verbunden.
Susan097
Ich bin mir nicht sicher, ob ich das verstehe. Ich habe mich eigentlich nicht auf den Link bezogen, jetzt lass mich darauf verweisen. Dieser Link github.com/muaz-khan/WebRTC-Scalable-Broadcast hat ein Bild in "Wie es funktioniert?" Sektion. Dieses Bild zeigt Ihnen deutlich, dass Peer5,9 und 10 einmal von der Sendung getrennt werden, wenn Peer5 die Verbindung trennt. Sie müssen eine Verbindung zu Peer2 oder Peer6 herstellen, dies führt jedoch zu Verzögerungen. Außerdem hat dieses Projekt weder Mitwirkende noch Aktivitäten.
Igorpavlov