Live-Sportarten sind spannend. Besonders in entscheidenden Momenten, wie wenn ein Schuss aus dem nichts kommt, um das Spiel zu gewinnen. Diese Momente können auch spannend für das technische Team sein, das für flüssige Echtzeitaktionen verantwortlich ist. Live-Sport-Streams müssen mehrere technische Überlegungen und Kompromisse miteinander in Einklang bringen, die im Durchschnitt etwa 30 Sekunden hinter dem Live-Spiel auf dem Spielfeld liegen. Warum die Verzögerung?
Netzwerke zur Inhaltsbereitstellung sind zwar wichtig, können jedoch die Latenz, die durch andere Teile des Video-Workflows verursacht wird, nicht reduzieren. Beispielsweise wird die Latenz ab dem Zeitpunkt der Aufnahme hinzugefügt, wenn ein Bild in ein Signal umgewandelt wird. Das Rohsignal muss dann in ein komprimiertes Format konvertiert und an das Videoverarbeitungszentrum übertragen werden, in der Regel außerhalb des Standorts und häufig in der Cloud, was durch die verfügbare Bandbreite und Infrastruktur beeinträchtigt werden kann. Als Nächstes werden die Inhalte für verschiedene Geräte und Bandbreiten transcodiert und verpackt. Während der Wiedergabe des Streams kann die Werbung dynamisch in den Stream eingefügt werden, kurz bevor sie über die letzte Meile des Internets zum Gerät des Zuschauers gelangt. Hier puffert der Player das endgültige Videosegment, dekomprimiert und rendert es. Das sind viele Schritte zwischen dem erfolgreichen Ziel des Teams und dem Content Delivery Network. Und sie können sich summieren, vor allem, wenn es für Millionen von Zuschauern auf einmal geschehen muss. Latenz in Super Bowl Livestreams, z.B. durchschnittlich 28 bis 47 Sekunden.
Die Reduzierung der Latenz ist für Streaming-Dienstanbieter ein Schwerpunkt geworden. Bei Sportarten, die an Glücksspiele im Sekundenbruchteil gebunden sind, wie Pferderennen, sind die Teilnehmer aus der Ferne gegenüber den Teilnehmern am Veranstaltungsort durch verzögerte Streams benachteiligt. Live-Tweets von Zuschauern und Newscastern am Veranstaltungsort verderben Fans spannende Momente, die sie im Fernsehen und Live-Streaming ansehen. Und da immer mehr Zuschauer beim Anschauen von Live-Sportarten einen zweiten Bildschirm verwenden, ist es kein Wunder, dass die Reduzierung der Zeit hinter Live eine wichtige Voraussetzung dafür ist, wettbewerbsfähig zu bleiben und ein großartiges Fernseherlebnis zu bieten.
Die Reduzierung der Latenz ist für uns bei Edgecast, heute Edgio, ein Schwerpunkt. Dabei geht es darum, schrittweise Verbesserungen für jeden Verarbeitungsschritt und die anderen Faktoren, die mit der Bereitstellung von Livestreams verbunden sind, zu erforschen und umzusetzen. In diesem Beitrag sehen wir uns an, was mit einem bestimmten Aspekt der Latenzreduzierung zu tun hat: Wie unser Content Delivery Network das erhöhte Anforderungsvolumen bewältigt, das sich aus einer immer beliebteren Strategie mit niedriger Latenz ergibt – nämlich der Reduzierung der Segmentgröße.
Um die Zeit hinter dem Livestream zu verkürzen, nutzen Streaming-Diensteanbieter die kürzere HLS- oder DASH-Segmentdauer. Dies kann die Latenz erheblich reduzieren, aber es gibt Kompromisse wie zusätzlichen Overhead und ein erhöhtes Risiko von Pufferbildung. Ob sich diese Kompromisse lohnen, hängt völlig von der Priorität ab, die der Latenz im Vergleich zu anderen QoE-Erwägungen eingeräumt wird. In einigen Situationen, wie oben erwähnt, hat niedrige Latenzzeiten höchste Priorität, während in anderen Situationen die aktuellen Latenzniveaus akzeptabel sind, um personalisierte Werbung, 4K-Programmierung oder die Bearbeitung von Live-Inhalten zu ermöglichen.
Die Rolle der Segmentgröße in der Latenz
Die Videostreaming-Branche setzt seit langem ABR-Technologien (Adaptive Bitrate) ein, die einen Stream in viele einzelne Videosegmente oder Teile aufteilen. Jedes Segment hat die gleiche Dauer oder Größe, ist jedoch mit unterschiedlichen Videoqualitätsstufen oder Bitraten codiert, sodass der Stream sich an die verfügbare Bandbreite des Zuschauers anpassen kann, wenn neue Segmente angefordert werden. Die beiden wichtigsten ABR-Protokolle, Apples HLS und MPEG-DASH, bieten Steuerelemente zum Anpassen der Segmentgröße.
Die Segmentgröße spielt eine wichtige Rolle bei der Latenz, da der Player eine voreingestellte Anzahl von Segmenten herunterladen muss, bevor er den Live-Stream abspielen kann. Dies geschieht, damit der Client-Video-Player ausreichend Video puffern kann, um eine reibungslose Videowiedergabe ohne Pufferung bei Netzwerküberlastung zu gewährleisten. Dies führt aber auch von Anfang an zu einem Live-Strom. In der Regel puffern integrierte Video-Player auf iOS-Geräten und Webbrowsern drei Videosegmente, bevor die Wiedergabe gestartet wird. Wenn ein Segment vier Sekunden lang ist und der Spieler drei Segmente puffern muss, bevor er spielen kann, liegt der Client bereits 12 Sekunden hinter Live zurück. Das DASH-Protokoll bietet eine gewisse Flexibilität, da Manifestdateien angeben können, wie viel von einer Datei gepuffert werden muss. Dennoch müssen viele DASH-Player und -Geräte diese Funktionalität noch nicht implementieren.
Kürzere Zeit hinter dem Leben
Da das Puffern von drei Segmenten de facto der Standard ist, ist die am häufigsten verwendete Methode zur Reduzierung der Zeit hinter dem Live-Betrieb die Verkleinerung der Größe oder Dauer jedes Segments. Im folgenden Beispiel wird die Zeit hinter Live durch die Reduzierung der Segmentgröße von vier auf zwei Sekunden auf nur sechs Sekunden reduziert – die Hälfte der Zeit, die bei Segmenten mit vier Sekunden benötigt wird.
Kleinere Segmente können zu Neupuffern führen
Bei kleineren Segmentgrößen muss der Video-Workflow reaktionsschneller sein, um ein pufferfreies Live-Video-Streaming zu ermöglichen. Dies ist auf zwei Faktoren zurückzuführen:
Erstens speichert der Player, der eine feste Anzahl von Segmenten speichert, weniger Videos, indem er die Segmentgröße verringert. Und da kürzere Segmentgrößen mehr Dateien bedeuten, müssen Ihr Video-Workflow und vor allem das Content Delivery Network doppelt so viele Dateianforderungen von Playern über eine bestimmte Stream-Dauer verarbeiten und bereitstellen. Da während einer Netzwerküberlastung weniger Videos im Player gepuffert werden, ist es wahrscheinlicher, dass die Überlastung einen Repuffer verursacht. Der Spieler reagiert jetzt empfindlicher auf Staus, selbst bei kleineren Staus.
Zweitens, wie wir kürzlich in einem Tech-artikel „Optimizing the CDN for Live Streaming“ erklärt haben, ist es bei Live-Sportarten üblich, einen Anstieg der Zuschauer zu beobachten, wenn beliebte Ereignisse beginnen oder ein nahes Spiel sich den letzten Minuten nähert. Wenn die Anzahl der Dateianforderungen steigt, muss das CDN mehr Dateianforderungen in derselben Zeit aufnehmen. Diese Aufgabe wird durch verschiedene Gerätetypen und Verbindungsgeschwindigkeiten ergänzt, die durch adaptive Bitratenparameter festgelegt werden.
Um die Zunahme des Dateivolumens zu veranschaulichen, zeigt Abbildung 2 ein 16-Sekunden-Videosegment, das in Segmenten unterschiedlicher Länge bereitgestellt wird. Bei Segmenten von vier Sekunden werden nur vier Dateien benötigt, um das 16-Sekunden-Segment zu liefern. Wenn wir jedoch zu zwei-Sekunden-Segmenten wechseln, benötigen wir acht separate Dateien – doppelt so viele Dateien, die über das CDN verarbeitet werden müssen.
Verbessern Sie die Leistung der Segmentbereitstellung mit Hot Filing
Wir haben eine Funktion namens Hot Filing entwickelt, um das sogenannte „Flash-Crowd“-Phänomen zu bewältigen, bei dem viele Live-Zuschauer gleichzeitig einem Stream beitreten. Diese Funktion bezieht sich auf die schnelle Replikation eines beliebten Segments oder einer „Hot File“ auf zusätzliche Server innerhalb eines POP (Point of Presence), sodass sie den Zuschauern so schnell bereitgestellt werden kann, wie die Nachfrage schnell steigt.
Durch die Verteilung der Last auf viele Server verhindert Hot Filing, dass ein Server überfordert wird, wenn Dateianforderungen plötzlich ansteigen. Wenn ein Server überlastet wird, ähnlich wie bei einem Denial-of-Service-Angriff, reagiert der Server langsam auf Dateianforderungen, was möglicherweise zu einer Pufferung im Client-Player führen kann. Durch die schnelle Identifizierung und Replikation von Hot Files ist das Risiko einer Überlastung eines einzelnen Servers deutlich geringer. Plötzliche Nachfrageänderungen können jetzt ohne zusätzliche Latenzzeiten bewältigt werden.
Abbildung 3 zeigt, wie Hot Filing (Abb. 3.b) die Leistung verbessert, indem eine Serverüberlastung verhindert wird. Ohne Hot Filing (Abb. 3.a) geht der gesamte Datenverkehr für ein Segment an Server 1 (S1). Wenn die Nachfrage der Zuschauer steigt, fließt der zusätzliche Datenverkehr an S1, wodurch es über die Kapazität von 100 Benutzern hinausgeht. Die Situation verschlechtert sich weiter, da S1 200 Zuschauer in der Spitzenposition bedient. Im Gegensatz dazu verarbeitet Hot Filing (Abb. 3.b) diese zusätzliche Last, indem Dateien auf zwei Server (S1 plus S2) repliziert und Dateianforderungen an den neu verfügbaren Server umgeleitet werden.
Schnellere Identifizierung von Hot-File-Dateien
Vor kurzem haben wir das Hot Filing verbessert, indem wir die Zeit für das Verschieben von Hot Files auf mehrere Server um eine Sekunde verkürzen. Wir haben die Reaktionszeit verbessert, indem wir die Art und Weise ändern, wie heiße Dateien in einem POP identifiziert werden. Wir verwenden einen zentralen Prozess, um Dateianforderungen und Byteanzahl für die Analyse zu aggregieren. Zuvor wurden die Daten aus dem Webserverprozess auf jedem Server abgerufen. Das funktionierte zwar gut, aber wir stellten fest, dass ein langsamer Webserver die Aggregation von Hot File-Daten verlangsamen konnte. Um dieses Problem zu beheben, schreiben die Server jetzt ihre Anforderung und das Byte zählt jede Sekunde auf die Disc. Wenn der zentrale Prozess Daten abruft, muss er daher nicht auf die Webserverprozesse warten, da die Daten bereits auf eine Solid-State-Festplatte geschrieben sind. Diese Änderung allein reicht aus, um die Last für die meisten Live-Events zu bewältigen.
Wie wichtig eine schnelle Reaktionszeit für Live-Events ist, zeigt Abbildung 3.c, die einen Einblick in die Funktionsweise des Hot Filing-Prozesses bietet, um zusätzliche Ressourcen zu gewinnen. In dem in Abbildung 3.c gezeigten Beispiel werden Dateien, wenn der S1-Server seine Kapazität von 100 Benutzern überschreitet, schnell nach S2 verschoben, sobald die Kapazität erreicht ist. Dadurch kann das System alle 200 Benutzer schnell und effizient aufnehmen und die volle Kapazität der verfügbaren Server nutzen.
Hot Filing auf mehreren Ports
Bei äußerst beliebten Veranstaltungen wie professionellen Playoff-Spielen oder großen internationalen Fußballspielen können Stürme und Stürme im Verkehr sehr bedeutend sein. Um diesen Bedarf zu erfüllen, müssen Sie auch die Replikation von Dateisegmenten ändern, um die Serverkapazität zu erhöhen. Bisher war das Content Delivery Network darauf beschränkt, Segmente auf einen Port pro Server zu replizieren. Aber jetzt können wir Dateien auf mehrere Ports in jedem Server replizieren. Dies erhöht den Durchsatz jedes Servers erheblich, sodass jeder POP mehr Anfragen und somit viel größere Live-Ereignisse verarbeiten kann als zuvor.
In unserem System wird der Lastausgleich durch CARP-Hashing (Cache Array Routing Protocol) durchgeführt. Für reguläre Inhalte haben wir die Dateien auf mehreren Servern repliziert. Wir verwenden CARP-Hashing, um einen einzelnen Port von jedem Server auszuwählen. Wir tun dies, um zu verhindern, dass doppelte Anforderungen an den Ursprungsserver gesendet werden, und um die Kommunikation zwischen den Prozessen zu beschränken.
Wenn eine Datei heiß genug wird, beginnt CARP, mehrere Ports pro Server auszuwählen, um noch mehr Anfragen zu unterstützen. Dieser Ansatz eignet sich gut für Hot Files, da sie nur einen kleinen Bruchteil der eindeutigen Dateien darstellen, die von einem Server bereitgestellt werden. Die Anzahl der geöffneten Ports hängt von der Anforderung einer Hot File ab. Dieser Ansatz erhöht das Datenvolumen, das pro Server bereitgestellt wird, und die Menge der CPU-Leistung, die zur Verarbeitung dieser Anforderungen zur Verfügung steht.
Schlussfolgerung
Da Streaming-Dienstanbieter die Größe von Videosegmenten reduzieren, um einen Live-Stream mit geringerer Latenz zu liefern, unterstützen Edgios Platform Hot Filing-Funktionen das Content Delivery Network dabei, die steigenden Anforderungen an Videodateien zu verwalten, insbesondere, wenn die Publikumsgröße für beliebte Sportveranstaltungen zunimmt.
