Implementierung von WebRTC auf einem Medienserver - Praxis und Richtlinien

1. Streaming zu Browsern in Echtzeit - keine Lösung. Oder ist da?

Seit etwa 20 Jahren ermöglichen die Netzwerkbandbreite und die Rechenkapazitäten von Computern die Komprimierung und Übertragung von Ton und Video über das IP-Protokoll nahezu in Echtzeit. In dieser Zeit haben zentrale Standardisierungsorganisationen wie W3C und IETF sowie viele große und kleine Unternehmen Hunderte von Standards und Protokollen entwickelt, um Audio-Video-Inhalte auf Computern und Mobilgeräten effizient zu komprimieren, zu verpacken, weiterzuleiten, zu synchronisieren und abzuspielen. Besonderes Augenmerk wurde auf die Erfassung, Komprimierung und Übertragung von Videos in Echtzeit über IP gelegt, da IP zum einen auf allen Ebenen am billigsten und am leichtesten zugänglich ist und zum anderen Videokonferenz- und Videoüberwachungstechnologien von entscheidender Bedeutung sind und eine große Nachfrage haben.

Es scheint, dass so viele Jahre vergangen sind und so viel Arbeit geleistet wurde. Welche wunderbaren Erfolge in diesem Bereich können wir nach 20 Jahren beobachten? Lassen Sie uns den Deckel der Box entfernen (natürlich ist dies nicht die Büchse von Pandora und keine „Dose Würmer“) und sehen, welche wunderbaren Technologien und Möglichkeiten nach langjähriger Arbeit von Zehntausenden talentierter Software-Ingenieure verfügbar wurden. Ein Programmierer aus dem Jahr 1998, der zuerst Ton über das Netzwerk gesendet hat, ein Arzt, der eine einfache, billige und zuverlässige Telemedizinlösung wünscht, ein Lehrer, der eine Fernstunde durchführen muss - jetzt öffnen sie diese Abdeckung, voller heller Hoffnungen, und was sehen sie? In einer offensiven Kochpfanne voller umwerfendem Marketing, zynischem Kapitalismus und verzweifelten Versuchen von Enthusiasten, Dinge zu verbessern, schweben alle Arten von Codecs, Protokollen, Formaten und Anwendungen.Dies bietet die IT-Suppe „Community“ dem Verbraucher in Echtzeit. Fangen Sie sich, die weniger riecht, versuchen, testen, kaufen. Es gibt keine einfache und effektive Lösung. Im Gegensatz zu Streaming, das keine Echtzeit benötigt: Immerhin gibt es bereits etwa 5 Jahre, und es gibt einen HLS-Standard, der auf allen Browsern und Geräten funktioniert, auf denen der Lösungsanbieter den HLS-Segmentierer einfach auf Ihrem Server installieren und ruhig schlafen kann.

Hier ist RTSP - viele Konsolen und professionelle Geräte spielen es, aber Browser spielen nicht. Hier ist RTMP - Safari möchte es nicht auf iOS spielen und nicht alle Androids spielen es. Chrome verbietet es als nicht vertrauenswürdig. Hier ist MPEG2-TS - Browser spielen es auch nicht ab. HTML5 Media Source Extensions (MSE) - gut für Videosegmente mit einer Länge von 5 bis 10 Sekunden (d. H. Für HLS / Dash), aber für kurze Segmente mit einer Länge von weniger als einer Sekunde - nicht immer stabil, funktioniert in verschiedenen Browsern immer wieder unterschiedlich wird unter iOS nicht unterstützt.

Wie, fragt man sich, sendet der Kindergarten Videos von in Gruppen installierten Kameras an Eltern, die jederzeit einen Browser auf einem beliebigen Gerät öffnen möchten, ohne Plug-Ins zu installieren, um ihre Kinder in Echtzeit zu beobachten? Warum bieten nicht alle Kindergärten solche Dienstleistungen an? Ja, weil die Bereitstellung eines solchen Dienstes sehr teuer ist. Wir müssen Apps für mobile Geräte entwickeln, auf denen das Video abgespielt wird - da Browser nicht abgespielt werden. Brauche viel mehr.

Definieren wir das Konzept "nahezu in Echtzeit". Dies ist weniger als 5 Sekunden Verzögerung für die Videoüberwachung und weniger als 1 Sekunde für Videokonferenzen. Die durchschnittliche Verzögerung des HLS-Protokolls beträgt 20-30 Sekunden. Vielleicht ist es irgendwie für Kindergärten geeignet, aber für Sicherheitsvideoüberwachung, Videokonferenzen und Webinare wird eine andere Technologie benötigt.

Bis jetzt, genauer gesagt bis zum Sommer 2017, gab es keinen einzigen Standard oder Protokoll für die Übertragung von Audio-Video an einen Browser auf einem Gerät in Echtzeit. Die Gründe für diese Situation werden wir später in diesem Artikel betrachten. Sie sind aus diesen Gründen nicht technischer Natur. Lassen Sie uns in der Zwischenzeit sehen, was im Sommer 2017 passiert ist, was zumindest eine Technologie darstellt, mit der wir die oben genannten Probleme lösen können. Bei dieser Technologie handelt es sich um WebRTC. Sowohl in dieser Ressource als auch im Netzwerk im Allgemeinen wurde viel darüber geschrieben. Es kann nicht mehr als völlig neu bezeichnet werden, und zum Zeitpunkt dieses Schreibens betrachtet W3C WebRTC 1.0 als abgeschlossenes Projekt. Wir werden hier nicht darüber sprechen, was WebRTC ist. Wenn der Leser mit dieser Technologie nicht vertraut ist, empfehlen wir, eine Suche im Hub oder in Google durchzuführen und sich kennenzulernen.wofür es verwendet wird und wie es allgemein funktioniert. Hier sagen wir nur, dass diese Technologie für die Peer-to-Peer-Kommunikation in Browsern entwickelt wurde. Mit ihr können Sie Video-Chat- und Sprachanwendungen ohne Server implementieren - der Browser kommuniziert direkt mit dem Browser. WebRTC wird von allen Browsern auf allen Geräten unterstützt. Im Sommer 2017 kam Apple schließlich zu uns und fügte es seiner Safari unter iOS hinzu. Es war dieses Ereignis, das WebRTC seit dem Sonnenuntergang von RTMP, der 2015 begann, zur universellsten und allgemein akzeptierten Technologie für Echtzeit-Streaming zu Browsern machte.WebRTC wird von allen Browsern auf allen Geräten unterstützt. Im Sommer 2017 kam Apple schließlich zu uns und fügte es seiner Safari unter iOS hinzu. Dieses Ereignis machte WebRTC zur universellsten und allgemein akzeptierten Technologie für Echtzeit-Streaming zu Browsern seit dem Sonnenuntergang von RTMP, der 2015 begann.WebRTC wird von allen Browsern auf allen Geräten unterstützt. Im Sommer 2017 kam Apple schließlich zu uns und fügte es seiner Safari unter iOS hinzu. Dieses Ereignis machte WebRTC zur vielseitigsten und allgemein akzeptierten Technologie für Echtzeit-Streaming zu Browsern seit dem Sonnenuntergang von RTMP, der 2015 begann.

Was hat das Streaming von Kameras zu Browsern damit zu tun? Tatsache ist jedoch, dass WebRTC in seiner Funktionalität sehr flexibel ist und es Ihnen ermöglicht, Audio-Video nur an einen der beiden Teilnehmer (Peers) zu senden und nur den anderen zu akzeptieren. Daher wurde die Idee geboren, WebRTC in Medienservern anzupassen. Der Medienserver kann Videos von der Kamera empfangen, die Kommunikation mit dem Browser herstellen und zustimmen, dass nur dieser sendet und der Browser empfängt. Somit kann der Medienserver gleichzeitig Videos von der Kamera an viele Browser / Betrachter senden. Umgekehrt kann ein Medienserver einen Stream von einem Browser empfangen und ihn beispielsweise an viele andere Browser weiterleiten, wobei die gewünschte "Eins-zu-Viele" -Funktion implementiert wird.

Also war endlich alles geformt? Akuna Matata und der Kindergarten können einen solchen Medienserver irgendwo auf dem Hosting oder auf AWS installieren, von jeder Kamera einen Stream senden und von dort aus bereits mit einer Verzögerung von nicht mehr als einer Sekunde an die Browser der Eltern verteilt werden. Im Allgemeinen - ja, das Leben wird besser. Aber es gibt Probleme. Und diese Probleme hängen mit der Tatsache zusammen, dass WebRTC für solche Aufgaben sozusagen weit hergeholt ist, es wurde nicht für sie entwickelt und ist für sie nicht ganz geeignet. Neben der Codec-Kompatibilität bestehen hauptsächlich Probleme mit der Skalierbarkeit eines solchen Medienservers. Das heißt, gleichzeitig können 100 Eltern von einem Server-Computer aus bedient werden, und 500 sind bereits schwierig. Obwohl das Netzwerk erlaubt. Und schauen Sie sich die Prozessorlast auf dem Server mit 100 Verbindungen an - sie liegt bereits bei fast 90%. Wie das? Senden Sie doch einfach ein Soundvideo.

Wenn Sie mit demselben Stream über das RTMP-Protokoll an den Flash Player gesendet werden, können Sie problemlos 2000 gleichzeitige Verbindungen von einem Server aus unterstützen. Ist WebRTC nur 100?
Warum? Es gibt zwei Gründe: Erstens ist das WebRTC-Protokoll viel rechenintensiver - dort werden beispielsweise alle Daten verschlüsselt und es nimmt viel Prozessorzeit in Anspruch. Der zweite Grund, auf den wir noch näher eingehen werden, ist die äußerst ineffiziente Implementierung des Protokolls durch seinen Ersteller - Google, der den Quell-C ++ - Code für diese Implementierung zur Anpassung an Server, Gateways und andere Anwendungen bereitstellt, die WebRTC unterstützen möchten: webrtc.org/native-code

2 Googles native WebRTC-API und Media Server-Kompatibilität

Denken Sie daran, dass WebRTC erstellt wurde, um Audio-Video vom Browser zum Browser zu übertragen, und dass keine Aufgaben zur Unterstützung vieler gleichzeitiger Verbindungen vorhanden waren. Daher und nicht nur deshalb hat die Implementierung von WebRTC im Browser das Grundprinzip des Designs und der Architektur technischer Systeme - Eleganz (nichts weiter), Effizienz, hohe Leistung - völlig außer Acht gelassen. Der Schwerpunkt lag auf Zuverlässigkeit und Verwaltbarkeit bei Fehlern und Extremsituationen im Netzwerk - Verlust von Paketen, Verbindungen usw. Was natürlich gut ist. Bei näherer Betrachtung stellt sich jedoch heraus, dass dies das einzige ist, was bei der Google-Implementierung von WebRTC gut ist.

Schauen wir uns die wichtigsten Punkte an, aufgrund derer die Verwendung der Google-Implementierung von WebRTC für Medienserver äußerst problematisch ist.

2.a Der Code ist zehnmal höher als er sein sollte und äußerst ineffizient.

Dies ist eine bewährte Zahl. Zunächst laden Sie etwa 5 Gigabyte Code herunter, von denen nur 500 Megabyte für WebRTC relevant sind. Dann versuchen Sie, den unnötigen Code loszuwerden. Schließlich benötigen Sie für die Anforderungen eines Medienservers keine Codierung / Decodierung. Der Server sollte nur Inhalte empfangen und an alle weiterleiten. Wenn Sie alles Unnötige entfernt haben, das Sie konnten (und Sie konnten viel weniger entfernen, als Sie möchten), haben Sie immer noch 100 Megabyte Code. Dies ist eine monströse Figur. Sie ist zehnmal größer als es sein sollte.

Übrigens werden an dieser Stelle viele sagen - wie wird das Codieren / Decodieren nicht benötigt? Was ist mit der Transcodierung von AAC zu Opus und umgekehrt? Was ist mit der Transcodierung von VP9-> H264? Wenn Sie eine solche Transcodierung auf dem Server durchführen, können Sie auch nicht 5 gleichzeitige Verbindungen herstellen. Wenn es wirklich notwendig ist, sollte die Transcodierung nicht von einem Medienserver, sondern von einem anderen Programm durchgeführt werden.

Aber kehren wir zum Problem des aufgeblähten Codes zurück und veranschaulichen es. Was ist Ihrer Meinung nach die Tiefe des Funktionsaufrufstapels beim Senden eines bereits komprimierten Videobilds? Ein Aufruf von Winsock (unter Windows) der Funktion send oder sendto (WSASend / WSASendTo)? Nein, natürlich muss noch etwas Arbeit geleistet werden. Im Fall von WebRTC müssen Sie den Frame über das RTP-Protokoll packen und verschlüsseln, wodurch wir insgesamt das SRTP-Protokoll erhalten. Es ist notwendig, den Frame im Falle eines Paketverlusts zu speichern, um ihn später erneut zu senden. Wie viele C ++ - Objekte und Threads sollten daran beteiligt sein?

So macht es WebRTC 61:



Wie Sie auf diesem Screenshot sehen können, beträgt die Aufrufstapeltiefe von dem Moment an, in dem wir den komprimierten Frame an WebRTC weiterleiten, bis zur Warteschlange des Paced_Sender-Objekts 8 (!) Und 7 Objekte sind beteiligt!

Dann zieht ein separater Thread (Thread) PacedSender unseren Frame aus der Warteschlange und sendet ihn zur Verarbeitung weiter:



Schließlich kamen wir zu Schritt 4, in dem der bereits RTP-gepackte und verschlüsselte Frame von der Warteschlange abhängt, die an das Netzwerk gesendet werden soll, das in einem anderen Thread beschäftigt ist. Zu diesem Zeitpunkt beträgt die Tiefe des Aufrufstapels (im PacedSender-Thread) 7, und es sind 3 weitere neue Objekte beteiligt. Der Thread, der gerade mit dem Senden beschäftigt ist, ruft das endgültige WSASend / WSASendTo auch nach 3-4 verschachtelten Funktionsaufrufen auf und umfasst 3-4 weitere neue Objekte.

Wir haben also 3 Threads gesehen, von denen jeder einen tollen Job macht. Jeder, der solche Systeme programmiert hat, hat eine Vorstellung davon, wie solche Dinge gemacht werden und was wirklich getan werden muss. Nach unseren Schätzungen sind mindestens 90% der Objekte und des Codes hier überflüssig und verstoßen gegen die Prinzipien der objektorientierten Programmierung.

2.b Pro Verbindung werden 4-5 Threads zugewiesen

Kein Zweifel, mit der Anzahl der Threads in diesem Beispiel ist alles in Ordnung. Es ist notwendig, eine asynchrone Verarbeitung bereitzustellen, um niemanden zu blockieren, und alle 3 Threads werden benötigt. Im Allgemeinen weist ein PeerConnection-WebRTC 4-5 Threads zu. Nun, es wäre möglich, innerhalb von 3 zu bleiben. Aber nicht weniger. Das Problem ist, dass dies für jede Verbindung gilt! Auf dem Server können Sie beispielsweise 3 Threads speichern, die jedoch alle Verbindungen zusammen bedienen und nicht jeder Verbindung 3 Threads zuweisen. Der Thread-Pool ist zweifellos eine Serverlösung für solche Aufgaben.

2.c Asynchrone Sockets, die Windows-Nachrichten verarbeiten

Google WebRTC-Code unter Windows verwendet asynchrone Sockets über WSAAsyncSelect. Serverprogrammierer wissen, dass die Verwendung der Auswahlfunktion auf dem Server Selbstmord und WSAAsyncSelect ist, obwohl dies die Situation verbessert, jedoch nicht um eine Größenordnung. Wenn Sie Hunderte und Tausende von Verbindungen unterstützen möchten, gibt es unter Windows eine bessere Lösung als asynchrone Sockets. Überlappende Sockets und E / A-Abschlussports müssen aktiviert sein, um Benachrichtigungen an den Thread-Pool zu senden, der die Arbeit ausführt.

2.d Fazit

Wir können also zu dem Schluss kommen, dass das Anwenden des WebRTC-Codes von Google ohne größere Änderungen auf einen Medienserver möglich ist, der Server jedoch nicht in der Lage ist, Hunderte von Verbindungen gleichzeitig herzustellen. Es kann zwei Lösungen geben:

Wesentliche Änderungen am Google-Code vorzunehmen, ist ohne Übertreibung nahezu unmöglich - schließlich sind alle diese Objekte sehr eng miteinander verbunden, kapseln keine Funktionalität, sind keine unabhängigen Blöcke, die bestimmte Arbeiten ausführen, wie es sein sollte. Eine unveränderte Einbeziehung in andere Szenarien ist nicht möglich.

Verwenden Sie überhaupt keinen Google-Code, sondern implementieren Sie alles selbst mithilfe offener Bibliotheken wie libsrtp und dergleichen. Vielleicht ist dies der richtige Weg, aber abgesehen von der Tatsache, dass dies auch eine große Aufgabe ist, können Sie auf die Tatsache stoßen, dass Ihre Implementierung nicht vollständig mit Google kompatibel ist und dementsprechend nicht oder nicht in allen Fällen funktioniert Zum Beispiel mit Chrom, das nicht toleriert werden kann. Sie können sich dann lange mit den Jungs von Google streiten und beweisen, dass Sie den Standard befolgt haben, aber sie haben es nicht, und Sie werden tausendmal Recht haben. Aber sie werden bestenfalls sagen: "Wir werden es reparieren, vielleicht irgendwie später." Sie müssen sich jetzt auf Chrom einstellen. Und der Punkt.

3. Warum ist alles so traurig?

Diese Situation beim Streaming zu Browsern in Echtzeit ist ein sehr charakteristisches Beispiel dafür, wozu „geschäftsorientierte Technologie“ manchmal führt. Die vom Geschäft motivierte Technologie entwickelt sich in die Richtung, in die sie für das Geschäft notwendig ist, und sofern sie für dieses Geschäft angenehm ist. Es ist dem Geschäftsansatz zu verdanken, dass wir jetzt über PCs und Mobiltelefone verfügen - keine Regierung oder zentrale Planungsbehörde könnte jemals so interessiert sein, all diese Verbrauchertechnologien zu entwickeln und der Masse vorzustellen. Das Privatunternehmen, motiviert durch den persönlichen Gewinn seiner Eigentümer, tat dies, sobald sich eine technische Gelegenheit ergab.

Es ist seit langem bekannt, verstanden und akzeptiert, dass nicht wesentliche Konsumgüter und Dienstleistungen, ohne die Sie in Frieden leben können, von privaten Unternehmen besser entwickelt werden als die Dinge, die für eine Person von entscheidender Bedeutung sind - Energie, Straßen, Polizei und Schulbildung - zentral entwickelt werden sollten. staatlich kontrollierte Institutionen.

Wir, die Kinder der Sowjetunion und die Mentalität "machen wir technisch korrekte und starke Technologie, damit die Menschen sie nutzen können und alles in Ordnung ist", könnten natürlich sagen, dass in einem geplanten sowjetischen System (wenn die Regierung plötzlich entscheidet) die Streaming-Technologie Echtzeit-IP könnte in einem Jahr entwickelt und implementiert werden und wäre um eine Größenordnung besser als das, was das Unternehmen in 20 Jahren gewonnen hat. Wir verstehen aber auch, dass es sich dann nicht entwickeln, veraltet werden und am Ende auf lange Sicht immer noch kommerzielle westliche Technologie verlieren würde.

Da es durchaus möglich ist, ohne Streaming-Shimming auszukommen, ist es daher zu Recht der Privatwirtschaft ausgeliefert. Welches entwickelt es in ihrem eigenen Interesse und nicht im Interesse des Verbrauchers. Wie ist es nicht im Interesse des Verbrauchers? Aber was ist mit Angebot und Nachfrage? Was braucht der Verbraucher, dann bietet das Unternehmen? Aber es bietet nicht. Alle Verbraucher schreien - Google unterstützt AAC-Audio in WebRTC, aber Google wird es niemals tun, obwohl es nur spuckt, um es zu tun. Apple ist das absolut egal und implementiert nichts von den dringend benötigten Streaming-Technologien in seinen Gadgets. Warum? Ja, weil das Unternehmen nicht immer das tut, was der Verbraucher braucht. Er tut dies nicht, wenn er Monopolist ist und keine Angst vor dem Verlust des Verbrauchers hat. Dann ist das Unternehmen damit beschäftigt, seine Position zu stärken. Deshalb hat Google in den letzten Jahren eine Reihe von Herstellern von Soundcodecs gekauft.Und jetzt wird Opus-Audio gepusht und die ganze Welt gezwungen, AAC-> Opus entsprechend WebRTC zu transkodieren, da die gesamte Technologie seit langem auf AAC-Audio umgestellt hat. Google begründet dies angeblich damit, dass AAC eine kostenpflichtige Technologie ist und Opus kostenlos ist. Tatsächlich geschieht dies jedoch, um seine Technologie als Standard zu etablieren. Wie Apple es einst mit seinem elenden HLS tat, das wir lieben gelernt haben, oder wie Adobe es mit seinem unverantwortlichen RTMP-Protokoll noch früher tat. Gadgets und Browser sind technisch immer noch recht schwierig zu entwickeln, von hier aus entstehen Monopolisten, von hier aus, wie sie sagen, sind Dinge da. Und das W3C und die IETF werden von denselben Monopolisten gesponsert, daher ist die Mentalität „Lasst uns technisch korrekte und starke Technologie herstellen, damit die Leute sie nutzen können und alles in Ordnung ist“ nicht da und wird es niemals sein.Aber es hätte sein sollen.

Was ist der Ausweg aus dieser Situation? Wenn man nur auf die „richtige“ geschäftsorientierte Technologie, das Ergebnis des Wettbewerbs und allerlei andere großartige Dinge wartet, wird man sich schließlich etwas Demokratisches einfallen lassen, das für einen einfachen Landarzt geeignet ist, damit er mit seinem normalen Internet Telemedizin-Dienste anbieten kann. In der Tat ist es notwendig, eine Änderung vorzunehmen, nicht für einen einfachen Landarzt, sondern für diejenigen, die viel Geld bezahlen können. Das Unternehmen bietet seit langem Echtzeit-Streaming-Lösungen an. Gut, zuverlässig und erfordert spezielle Netzwerke und spezielle Geräte. In vielen Fällen funktioniert das IP-Protokoll nicht. Was - und dies ist ein weiterer Grund für eine so traurige Situation - nicht in Echtzeit erstellt wurde und dies nicht immer garantiert. Nicht immer, aber nicht in lebenswichtigen Situationen, ist es im Moment durchaus geeignet.Versuchen wir es mit WebRTC. Bisher ist er von allen Übeln der kleinste und demokratischste. Dafür müssen Sie sich schließlich bei Google bedanken.

4. Ein bisschen über Medienserver, die WebRTC implementieren

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro und Unreal Media Server - dies sind einige der Medienserver, die WebRTC unterstützen. Sie bieten die Veröffentlichung von Videos von Browsern auf dem Server und die Übertragung von Videos über WebRTC vom Server an Browser.

Die in diesem Artikel beschriebenen Probleme werden in diesen Softwareprodukten auf unterschiedliche Weise und mit unterschiedlichem Erfolg gelöst. Einige von ihnen, zum Beispiel Kurento und Wowza, führen Audio-Video-Transcodierungen direkt auf dem Server durch, andere, zum Beispiel Unreal Media Server, transkodieren sich nicht selbst, sondern stellen andere Programme dafür bereit. Einige Server, wie Wowza und Unreal Media Server, unterstützen das Streaming aller Verbindungen über einen zentralen TCP- und UDP-Port, da WebRTC selbst für jede Verbindung einen separaten Port zuweist, sodass der Anbieter viele Ports in der Firewall öffnen muss, was zu Sicherheitsproblemen führt.

In all diesen Servern sind viele Punkte und Feinheiten auf unterschiedliche Weise implementiert. Wie sehr dies alles dem Verbraucher passt, beurteilen Sie, liebe Benutzer.