Veröffentlichen und abspielen
Auf der Serverseite gibt es zwei Hauptfunktionen für den WebRTC-Betrieb im Bereich des Streaming von Videos: Veröffentlichung und Wiedergabe. Beim Veröffentlichen wird der Videostream von der Webkamera erfasst und vom Browser auf den Server übertragen. Beim Abspielen bewegt sich der Stream in die entgegengesetzte Richtung, vom Server zum Browser, wird dekodiert und im HTML5 <video> -Element des Browsers auf dem Bildschirm des Geräts abgespielt.
UDP und TCP
Video kann über zwei Transportprotokolle übertragen werden: TCP oder UDP. Bei UDP arbeiten die RTCP-Rückmeldungen von NACK aktiv und enthalten die Informationen zu den verlorenen Paketen. Daher ist es eine recht einfache Aufgabe, die Verschlechterung des UDP-Kanals zu erkennen. Sie werden auf die NACK-Zählung (Negative ACK) heruntergezählt, um sie zu bestimmen die Qualität. Je mehr NACK- und PLI-Rückkopplungen (Picture Loss Indicator) vorhanden sind, desto größer sind die tatsächlichen Verluste und desto geringer ist die Kanalqualität.
TCP ohne NACK
In diesem Artikel konzentrieren wir uns mehr auf das TCP-Protokoll. Wenn WebRTC über TCP verwendet wird, werden keine NACK RTCP-Rückmeldungen gesendet, und selbst wenn sie gesendet werden, spiegeln sie nicht das tatsächliche Bild der Verluste wider, und es scheint nicht möglich zu sein, die Kanalqualität anhand der Rückmeldungen zu bestimmen. Es ist allgemein bekannt, dass TCP ein Transportprotokoll mit garantierter Zustellung ist. Aus diesem Grund wird für den Fall, dass sich die Kanalqualität verschlechtert, der Rest der Pakete, die sich im Netzwerk befinden, auf der Ebene des Transportprotokolls gesendet. Früher oder später werden sie geliefert, aber für diese Verluste wird kein NACK generiert, da tatsächlich keine Verluste aufgetreten sind. Infolgedessen erreichen die Pakete ihr Ziel mit einer Verzögerung. Die verzögerten Pakete werden einfach nicht zu Videoframes zusammengefasst und vom Depaketierer verworfen, wodurch der Benutzer ein Bild wie das folgende voller Artefakte sieht:
Die Rückmeldungen zeigen, dass alles in Ordnung ist, aber das Bild enthält Artefakte. Unten sehen Sie Screenshots des Wireshark-Datenverkehrs, die das Verhalten des Streams veranschaulichen, der auf komprimierten TCP- und UDP-Kanälen veröffentlicht wird, sowie Screenshots der Google Chrome-Statistiken. In den Screenshots können Sie sehen, dass die NACK-Metrik im Fall von TCP nicht anders wächst als die UDP-Metrik, obwohl der Status des Kanals sehr schlecht ist.
TCP
UDP
Warum überhaupt über TCP streamen, wenn es UDP gibt?
Dies ist eine vernünftige Frage. Die Antwort ist, große Auflösungen durch den Kanal zu schieben. Im Fall von VR-Streaming (Virtual Reality) können die Auflösungen beispielsweise ab 4 KB beginnen. Es scheint nicht möglich zu sein, einen Stream mit einer solchen Auflösung und einer Bitrate von ungefähr 10 Mbit / s ohne Verluste in einen regulären Kanal zu pushen. Der Server spuckt die UDP-Pakete aus und sie beginnen, im Netzwerk in Bündeln verloren zu gehen, dann der Rest von ihnen beginnt gesendet zu werden, und so weiter. Große Mengen von verworfenen Videopaketen beschädigen das Video, und das Nettoergebnis ist, dass die Qualität sehr schlecht wird. Aus diesem Grund wird WebRTC über TCP für die Übertragung von Videos in Allzwecknetzwerken und mit hohen Auflösungen wie Full HD und 4k verwendet, um Netzwerkpaketverluste auf Kosten einer geringfügigen Erhöhung der Kommunikationslatenz auszuschließen.
RTT zur Ermittlung der Kanalqualität
Es gibt also keine Metrik, die Ihnen sicher sagt, dass sich der Kanal in einem sehr schlechten Zustand befindet. Einige Entwickler versuchen, sich auf die RTT-Metrik zu verlassen, aber sie funktioniert bei weitem nicht in allen Browsern und liefert keine genauen Ergebnisse.
Nachfolgend finden Sie eine Darstellung der Abhängigkeit der Kanalqualität von RTT nach dem callstat-Projekt
REMB-basierte Lösung
Wir haben uns entschlossen, dieses Problem etwas anders anzugehen. Auf der Serverseite arbeitet das REMB , das die eingehende Bitrate für alle eingehenden Streams berechnet, die Abweichung vom Mittelwert berechnet und vorschlägt, dass der Browser die Bitrate im Falle einer erheblichen Streuung senkt und spezielle REMB-Befehle über das RTCP sendet Protokoll. Der Browser empfängt eine solche Nachricht und senkt die Bitrate des Video-Encoders um die empfohlenen Werte: So funktioniert der Schutz vor Kanalüberlastung und Beeinträchtigung des eingehenden Datenstroms. Auf diese Weise wurde der Bitratenberechnungsmechanismus bereits serverseitig implementiert. Die Mittelung und Bestimmung der Dispersion erfolgt über das Kalman-Filter. Dies ermöglicht es, die aktuelle Bitrate jederzeit mit hoher Genauigkeit abzurufen und signifikante Abweichungen herauszufiltern.
Der Leser wird mit Sicherheit die Frage haben: "Wie kann ich die Bitrate ermitteln, die der Server für den eingehenden Stream sehen kann?" Auf diese Weise können Sie nur verstehen, dass auf dem Server Videos mit einer Bitrate mit dem Wert eingehen von denen man feststellen konnte. Zur Bewertung der Kanalqualität wird eine weitere Komponente benötigt.
Die ausgehende Bitrate und warum es wichtig ist
Die Statistik für den publizierenden WebRTC-Stream zeigt an, mit welcher Bitrate der Videostream aus dem Browser kommt. Ein alter Witz besagt, dass ein Site-Administrator beim Überprüfen seines Sturmgewehrs sagt: „Auf meiner Seite sind die Kugeln herausgeflogen. Die Probleme sind auf Ihrer Seite ... “Bei der Überprüfung der Kanalqualität werden zwei Bitraten verglichen: 1) die vom Browser gesendete Bitrate, 2) die tatsächlich vom Server empfangene Bitrate.
Der Site-Administrator feuert die Kugeln ab und berechnet die Geschwindigkeit, mit der sie auf seiner Seite herausfliegen. Der Server berechnet die Geschwindigkeit, mit der sie auf seiner Seite empfangen werden. Es gibt noch einen weiteren Teilnehmer dieser Veranstaltung, TCP. Dies ist ein Superheld, der sich in der Mitte zwischen dem Administrator und dem Server befindet und Kugeln nach dem Zufallsprinzip stoppen kann. Zum Beispiel kann es 10 zufällige Kugeln von 100 für 2 Sekunden stoppen und sie dann wieder fliegen lassen. Das ist die Matrix, die wir hier sehen.
Auf der Browserseite nehmen wir die aktuelle Bitrate aus der WebRTC-Statistik, glätten dann das Diagramm mit dem Kalman-Filter in der JavaScript-Implementierung und erhalten am Ende des Prozesses eine geglättete Version der Client-Browser-Bitrate. Jetzt haben wir praktisch alles, was wir brauchen: Die Client-Bitrate gibt an, wie der Datenverkehr vom Browser ausgeht, und die Server-Bitrate gibt an, wie der Datenverkehr vom Server gesehen wird und mit welcher Bitrate er empfangen wird. Es ist offensichtlich, dass, wenn die Client-Bitrate hoch bleibt und die Server-Bitrate im Verhältnis zur Client-Bitrate abnimmt, nicht alle Aufzählungszeichen das Ziel erreicht haben und der Server tatsächlich keinen Teil des Datenverkehrs sehen kann das wurde dorthin geschickt. Auf dieser Basis können wir den Schluss ziehen, dass etwas mit dem Kanal nicht stimmt und es Zeit ist, die Anzeigefarbe auf Rot zu ändern.
Und es gibt noch mehr
Die Graphen korrelieren, sind jedoch leicht zeitversetzt zueinander. Für eine vollständige Korrelation ist es erforderlich, die Diagramme zeitlich abzugleichen, um die Client- und Server-Bitrate zum gleichen Zeitpunkt mit historischen Daten zu vergleichen. Die Desynchronisation sieht ungefähr so aus:
Und so sieht ein zeitsynchronisierter Graph aus.
Lass es uns testen
Wir haben noch ein wenig zu tun, wir müssen es nur testen. Veröffentlichen Sie einen Videostream, öffnen Sie ihn und sehen Sie sich das Diagramm der veröffentlichten Bitraten an: auf der Browserseite und auf der Serverseite. Die Grafiken zeigen praktisch eine perfekte Übereinstimmung. Und das ist der Name des Indikators, PERFECT.
Dann fangen wir an, den Kanal zu beschädigen. Dazu können wir die folgenden kostenlosen Tools verwenden: winShaper für Windows oder Network Link Conditioner für MacOS. Sie ermöglichen das Komprimieren des Kanals auf den voreingestellten Wert. Wenn wir beispielsweise wissen, dass ein Stream mit 640 x 480 eine Geschwindigkeit von 1 MBit / s erreichen kann, komprimieren wir ihn auf 300 KBit / s. Dabei dürfen wir nicht vergessen, dass wir mit TCP arbeiten. Lassen Sie uns das Ergebnis unseres Tests überprüfen: In den Diagrammen gibt es eine inverse Korrelation, und der Indikator rutscht auf BAD ab. In der Tat sendet der Browser weiterhin Daten und erhöht sogar die Bitrate, um einen neuen Teil des Datenverkehrs in das Netzwerk zu leiten. Diese Daten sammeln sich im Netzwerk in Form von erneuten Übertragungen an und erreichen den Server nicht. Infolgedessen zeigt der Server ein umgekehrtes Bild und meldet, dass die Bitrate, die er sehen kann, gesunken ist. In der Tat ist es schlecht.
Wir haben viele Tests durchgeführt, die die korrekte Funktion des Indikators belegen . Als Ergebnis haben wir eine Funktion, die es ermöglicht, den Benutzer zuverlässig und schnell über Probleme mit dem Kanal zu informieren, sowohl beim Veröffentlichen als auch beim Abspielen (nach dem gleichen Prinzip). Ja, diese ganze Aufregung war für diese grün-rote Lampe, PERFEKT-SCHLECHT. Die Praxis zeigt jedoch, dass dieser Indikator sehr wichtig ist und dass sein Fehlen sowie das Nichtverstehen des aktuellen Status große Probleme für einen normalen Benutzer eines WebRTC-Video-Streaming-Dienstes verursachen können.
Links
WCS 5.2 ist ein Streaming-Media-Server für die Entwicklung von Web- und Mobilanwendungen
Qualitätskontrolle für Publisher- und Player-Kanäle
REMB - Geschätzte maximale Bitrate des Empfängers, die für die Bandbreitensteuerung verwendet wird
NACK - Negative Acknowledgement (negative Bestätigung), die für die Kontrolle über den Verlust eines Pakets und für die erneute Übertragung verwendet wird