Veröffentlichen und abspielen
Beim Video-Streaming gibt es zwei wichtige serverseitige WebRTC-Funktionen: Veröffentlichung und Wiedergabe. Im Falle einer Veröffentlichung wird der Videostream von der Webcam erfasst und vom Browser auf den Server verschoben. Bei der Wiedergabe bewegt sich der Stream in die entgegengesetzte Richtung - vom Server zum Browser, wird decodiert und im HTML5-Browserelement <video> auf dem Bildschirm des Geräts wiedergegeben.
UDP und TCP
Video kann über zwei Transportprotokolle übertragen werden: TCP oder UDP. Im Falle von UDP arbeiten RTCP-NACK-Rückmeldungen aktiv, die Informationen über verlorene Pakete enthalten, und daher ist das Bestimmen der Verschlechterung des UDP-Kanals eine relativ einfache Aufgabe, und es kommt darauf an, NACK (Negative ACK) zu zählen, um die Qualität zu bestimmen. Je mehr NACK- und PLI-Rückmeldungen (Picture Loss Indicator) vorliegen, desto mehr reale Verluste und desto schlechter ist die Kanalqualität
TCP ohne NACK
In diesem Artikel interessieren wir uns mehr für das TCP-Protokoll. Bei Verwendung von WebRTC über TCP werden keine NACK RTCP-Rückmeldungen gesendet. Wenn dies der Fall ist, geben sie nicht das tatsächliche Bild der Verluste wieder, und es ist nicht möglich, die Qualität des Kanals durch Rückmeldungen zu bestimmen. Wie Sie wissen, ist TCP ein Transportprotokoll mit garantierter Zustellung. Aus diesem Grund werden im Falle einer Kanalverschlechterung Pakete im Netzwerk auf der Ebene des Transportprotokolls gesendet. Früher oder später werden sie geliefert, aber NACK wird für diese Verluste nicht generiert, weil Es gab tatsächlich keine Verluste. Pakete werden irgendwann zu spät ankommen. Verspätete Pakete werden einfach nicht in Video-Frames gesammelt und vom Depaketierer verworfen, wodurch der Benutzer so etwas voll mit Artefakten sieht:
Auf Rückmeldungen wird alles in Ordnung sein, aber es werden Artefakte im Bild sein. Unten finden Sie Screenshots des Wireshark-Datenverkehrs, die das Verhalten des veröffentlichten Streams auf geklemmten TCP- und UDP-Kanälen veranschaulichen, sowie Screenshots der Google Chrome-Statistiken. Die Screenshots zeigen, dass bei TCP die NACK-Metrik im Gegensatz zu UDP nicht wächst, obwohl bei dem Kanal alles sehr schlecht ist.
TCP
UDP
Und warum müssen Sie über TCP streamen, wenn es UDP gibt
Vernünftige Frage. Antwort: Schieben Sie große Auflösungen durch den Kanal. Wenn Sie beispielsweise VR (Virtual Reality) streamen, beginnen die Berechtigungen möglicherweise bei 4 KB. Es ist nicht möglich, einen Stream mit dieser Auflösung und Bitrate von ungefähr 10 Mbit / s ohne Verlust in einen regulären Kanal zu übertragen. Der Server spuckt UDP-Pakete aus und sie beginnen, sich in Paketen im Netzwerk zu verlieren und werden dann usw. gesendet. Große Dumps von Videopaketen verderben das Video und am Ende wird die Qualität schlecht. Aus diesem Grund wird für Allzwecknetzwerke und hochauflösende Full HD, 4k, WebRTC über TCP für die Videoübertragung verwendet, um den Verlust von Netzwerkpaketen auf Kosten einer gewissen Zunahme der Kommunikationsverzögerung zu vermeiden.
RTT zur Bestimmung der Kanalqualität
Somit gibt es keine Metrik, die garantiert aussagt, dass der Kanal alles in Ordnung ist. Einige Entwickler versuchen, sich auf die RTT-Metrik zu verlassen, aber sie funktioniert nicht in allen Browsern und liefert keine genauen Ergebnisse.
Nachfolgend ist die Abhängigkeit der Kanalqualität von RTT gemäß der Version des callstat-Projekts dargestellt
REMB-Lösung
Wir haben uns entschlossen, dieses Problem aus einer etwas anderen Perspektive anzugehen. REMB arbeitet auf der Serverseite , berechnet die eingehende Bitrate für alle eingehenden Streams, berechnet die Abweichung vom Durchschnitt und bietet dem Browser bei einer großen Spreizung die Möglichkeit, die Bitrate zu senken, indem spezielle REMB-Befehle über das RTCP-Protokoll gesendet werden. Der Browser empfängt eine solche Meldung und reduziert die Video-Encoder-Bitrate auf die empfohlenen Werte - so funktioniert der Schutz vor Kanalüberlastung und Beeinträchtigung des Eingangsstroms. Somit wurde auf der Serverseite bereits ein Mechanismus zur Berechnung der Bitrate implementiert. Mittelwertbildung und Streubestimmung werden durch das Kalman-Filter implementiert. Auf diese Weise können Sie die aktuelle Bitrate jederzeit mit hoher Genauigkeit entfernen und starke Abweichungen filtern.
Der Leser wird wahrscheinlich die Frage haben: "Wie ist die Kenntnis der Bitrate, die der Server im eingehenden Stream sieht?". Dies gibt einen Überblick darüber, was genau das Video mit der Bitrate auf dem Server eingibt, dessen Wert ermittelt wurde. Um die Qualität des Kanals zu bewerten, ist eine weitere Komponente erforderlich.
Ausgehende Bitrate und warum ist es wichtig
Die Statistik des publizierenden WebRTC-Streams zeigt an, mit welcher Bitrate der Videostream den Browser verlässt. Wie in einem bärtigen Scherz: Admin, der die Maschine überprüft: „Von meiner Seite sind die Kugeln herausgeflogen. Die Probleme sind auf Ihrer Seite .. ". Die Idee, die Qualität des Kanals zu überprüfen, besteht darin, zwei Bitraten zu vergleichen: 1) die Bitrate, die der Browser sendet, 2) die Bitrate, die der Server tatsächlich empfängt.
Der Administrator feuert Kugeln ab und berechnet die Geschwindigkeit ihrer Abreise zu Hause. Der Server berechnet die Geschwindigkeit, mit der sie zu Hause empfangen werden. Es gibt einen anderen Teilnehmer in diesem Event, TCP ist ein Superheld, der sich in der Mitte zwischen dem Administrator und dem Server befindet und Kugeln zufällig verlangsamen kann. Zum Beispiel kann es 10 zufällige Kugeln von 100 für 2 Sekunden abbremsen und sie dann wieder fliegen lassen. Hier ist eine solche Matrix.
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 Ausgang eine geglättete Version der Client-Browser-Bitrate. Jetzt haben wir fast alles, was wir brauchen: Die Client-Bitrate gibt an, wie der Datenverkehr den Browser verlässt, und die Server-Bitrate gibt an, wie der Server diesen Datenverkehr sieht und welche Bitrate er empfängt. Wenn die Client-Bitrate hoch bleibt und die Server-Bitrate im Verhältnis zum Client nachgibt, sind offensichtlich nicht alle "Kugeln" abgeflogen, und der Server sieht nicht wirklich einen Teil des Datenverkehrs, der an ihn gesendet wurde. Daraus schließen wir, dass etwas mit dem Kanal nicht stimmt und es an der Zeit ist, die Anzeige auf rot zu stellen.
Es wird noch mehr kommen
Die Graphen sind korreliert, jedoch zeitlich leicht gegeneinander verschoben. Für eine vollständige Korrelation ist es erforderlich, die Zeitdiagramme zu kombinieren, um die Client- und Server-Bitrate zum gleichen Zeitpunkt für Verlaufsdaten zu vergleichen. Das Desync sieht ungefähr so aus:
Und es sieht aus wie ein zeitsynchronisiertes Diagramm.
Testen
Der Fall ist klein, es bleibt zu testen. Wir veröffentlichen den Videostream, öffnen und schauen uns den Zeitplan der veröffentlichten Bitraten an: auf der Browserseite und auf der Serverseite. Nach den Grafiken sehen wir eine fast perfekte Übereinstimmung. Der Indikator heißt PERFECT.
Als nächstes fangen wir an, den Kanal zu verderben. Dazu können Sie solche kostenlosen " winShaper " -Tools unter Windows oder " Network Link Conditioner " unter MacOS verwenden. Sie ermöglichen es Ihnen, den Kanal auf den eingestellten Wert zu klemmen. Wenn wir beispielsweise wissen, dass ein Stream mit 640 x 480 auf 1 Mbit / s beschleunigt werden kann, sollten Sie ihn auf 300 kbit / s beschränken. Gleichzeitig erinnern wir uns, dass wir mit TCP arbeiten. Wir überprüfen das Testergebnis - die Grafiken zeigen eine inverse Korrelation und der Indikator fällt auf BAD. 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 werden in Form von Neuübertragungen im Netzwerk abgelegt und erreichen den Server nicht. Infolgedessen zeigt der Server das entgegengesetzte Bild und meldet, dass die angezeigte Bitrate gesunken ist. Wirklich schlimm.
Wir haben viele Tests durchgeführt, die die korrekte Funktion des Indikators belegen . Das Ergebnis ist eine Funktion, mit der Sie den Benutzer qualitativ und effizient über Probleme mit dem Kanal informieren können, sowohl für die Veröffentlichung des Streams als auch für die Wiedergabe (funktioniert nach demselben Prinzip). Ja, um dieser grün-roten PERFECT-BAD-Glühbirne willen haben wir diesen ganzen Garten eingezäunt. Die Praxis zeigt jedoch, dass dieser Indikator sehr wichtig ist und dass sein Fehlen und Missverständnis des aktuellen Status das Leben eines normalen Benutzers eines Video-Streaming-Dienstes über WebRTC erheblich beeinträchtigen kann.
Referenzen
WCS 5.2 - ein Medienserver für die Entwicklung von Web- und mobilen Videoanwendungen
Dokumentation zur WebRTC-Kanalqualitätskontrolle für Veröffentlichung und Wiedergabe
REMB - Server Side Bitrate Management
NACK - Kontrolle verlorener Pakete von der Serverseite