Unser JIT Packager — eine neue Lösung für HTTP-Streaming mit niedriger Latenzzeit

Wir freuen uns, eine neue Entwicklung von Gcore bekannt geben zu können: unseren JIT (Just-In-Time) Packager. Diese Lösung ermöglicht das gleichzeitige Streaming über sechs Protokolle: HLS, DASH, L-HLS, Chunked CMAF/DASH, Apple Low Latency HLS und HESP. In diesem Artikel erklären wir, warum HLS- und DASH-Streaming niedrige Latenzzeiten zu einer Herausforderung machen, tauchen in alternative Technologien mit aufregendem Potenzial zur Reduzierung der Latenzzeit ein und erzählen Ihnen dann von unserem JIT Packager — warum wir ihn entwickelt haben, wie er funktioniert, welche Fähigkeiten und Vorteile er bietet und welche Ergebnisse er liefert.

Warum ist es so schwierig, mit den HLS- und DASH-Standardtechnologien eine niedrige Latenzzeit zu erreichen?

Die Schwierigkeit, mit den HLS- und DASH-Standardtechnologien eine niedrige Latenzzeit zu erreichen, ergibt sich aus den empfohlenen Richtlinien für Segmentlänge und Puffergröße, die zu einer Latenzzeit von zwanzig Sekunden oder mehr führen können. Lassen Sie uns untersuchen, warum dies der Fall ist.

Beim herkömmlichen Internet-Streaming werden häufig Technologien wie HLS (HTTP Live-Streaming) und DASH (Dynamic Adaptive Streaming over HTTP) eingesetzt. Diese Protokolle basieren auf HTTP und unterteilen Video- und Audioinhalte in kleine Segmente von wenigen Sekunden Dauer. Diese Segmentierung ermöglicht eine schnelle Navigation, Bitratenumschaltung und Caching. Der Client empfängt ein Textdokument, das die Folge der Segmente, ihre Adressen sowie zusätzliche Metadaten wie Auflösung, Codecs, Bitrate, Dauer und Sprache enthält. Die Einhaltung der empfohlenen Richtlinien für Segmentlängen und Puffergrößen der HLS- und DASH-Protokolle macht es jedoch schwierig, eine niedrige Latenzzeit zu erreichen. Die Latenzzeit kann bis zu zwanzig Sekunden betragen.

Hier ist ein Beispiel: Nehmen wir an, wir initiieren die Transcodierung und erstellen Segmente mit einer Dauer von 6 Sekunden. Als Nächstes beginnen wir mit der Wiedergabe dieses Streams. Das bedeutet, dass der Player zunächst seinen Puffer füllen muss, indem drei Segmente geladen werden. Zu Beginn stellen wir fest, dass die drei vollständig gebildeten und der Echtzeit am nächsten kommenden Segmente die Segmente 3, 4 und 5 sind. Folglich beginnt die Wiedergabe mit dem 3. Segment und die Verzögerung lässt sich leicht anhand der Segmentdauer berechnen, die mindestens 18  Sekunden beträgt.

Durch die Verwendung kürzerer Segmente, z. B. 1–2 Sekunden, können wir die Verzögerung reduzieren. Segmente mit einer Dauer von 2 Sekunden würden zu einer minimalen Verzögerung von 6 Sekunden führen. Dies würde jedoch eine Reduzierung der GOP-Größe (Group of Pictures) erfordern. Die Reduzierung der GOP-Größe verringert die Codierungseffizienz und führt zu einem erhöhten Traffic-Overhead, da jedes Segment nicht nur Video- und Audio-Daten, sondern auch zusätzlichen Overhead enthält. Darüber hinaus entsteht bei jeder Segmentanforderung durch das HTTP-Protokoll ein Overhead.

Das bedeutet, dass kürzere Segmente zu einer größeren Anzahl von Segmenten und damit zu einem höheren Overhead führen. Da eine große Anzahl von Zuschauern ständig Segmente anfordert, würde dies zu einem erheblichen Traffic-Verbrauch führen.

Mit welchen Technologien kann eine Reduzierung der Latenzzeit erreicht werden?

Um beim Streaming eine geringere Latenzzeit zu erreichen, können mehrere spezielle Lösungen genutzt werden:

1. L-HLS
2. Chunked CMAF/DASH
3. Apple Low Latency HLS
4. HESP

Diese Lösungen unterscheiden sich von den herkömmlichen HLS- und DASH-Protokollen dadurch, dass sie speziell auf ein Streaming mit geringen Latenzzeiten zugeschnitten sind.

Lassen Sie uns nun genauer auf diese Protokolle eingehen.

L-HLS

Bei L-HLS erhält der Client neue Fragmente des letzten Segments, sobald diese verfügbar sind. Dies wird erreicht, indem die Adresse dieses Segments in der Wiedergabeliste mithilfe eines speziellen PREFETCH-Tags deklariert wird. Dadurch kann die Latenzzeit erheblich reduziert und der Datenpfad gemäß den folgenden Schritten verkürzt werden:

1. Der Server deklariert vorab die Adresse des neuen Live-Segments in der Wiedergabeliste.
2. Der Player fordert dieses Segment an und erhält seinen ersten Block, sobald dieser auf dem Server verfügbar ist.
3. Ohne auf den nächsten Datensatz zu warten, spielt der Player den empfangenen Block ab.

Chunked CMAF/DASH

Wenn es um Chunked CMAF/DASH geht, umfasst der Standard Felder, mit denen die Zeitachse, die Aktualisierungsrate, die Verzögerung und der Abstand zur Edge der Wiedergabeliste gesteuert werden. Die wichtigsten Verbesserungen in der Referenz-Player-Version von Dash.js v2.6.8 sind die Unterstützung der Chunked-Transfer-Codierung und der Fetch-API, wo immer möglich, sowie die Bereitstellung von Daten an den Player, sobald diese verfügbar sind.

Die Angabe eines Streams mit niedriger Latenzzeit wird durch die Verwendung der Tags „Latency target“ und „availabilityTimeOffset“ erreicht, mit denen die Zielverzögerung signalisiert und das Laden von Fragmenten ermöglicht wird, bevor die vollständige Segmentbildung abgeschlossen ist.

Durch den Einsatz dieser Technologien ist es möglich, Verzögerungen im Bereich von 2–6 Sekunden zu erreichen, was von der Konfiguration und den Einstellungen sowohl der serverseitigen als auch der Player-seitigen Komponenten abhängig ist. Darüber hinaus besteht eine Abwärtskompatibilität, sodass Geräte, die Formate mit niedriger Latenzzeit nicht kommunizieren können, vollständige Segmente wie zuvor wiedergeben können.

Apple Low Latency HLS

Apple LL-HLS bietet verschiedene Lösungen zur Optimierung der Latenzzeit, einschließlich:

1. Generieren von Teilsegmenten mit einer Länge von bis zu 200 ms, die in der Wiedergabeliste mit X-PART markiert und vor der Bildung des vollständigen Segments verfügbar sind. Veraltete Teilsegmente werden regelmäßig entfernt und durch vollständige Segmente ersetzt.
2. Durch das Senden aktualisierter Wiedergabelisten nach Aktualisierungen und nicht auf direkte Anfrage kann der Server die Bereitstellung verzögern.
3. Es werden nur die Unterschiede der Wiedergabelisten übertragen, um das Datenübertragungsvolumen zu reduzieren.
4. Ankündigung bald verfügbarer Teilsegmente mit dem neuen PRELOAD-HINT-Tag, sodass Clients frühzeitig Anfragen stellen und Server reagieren können, sobald Daten verfügbar sind.
5. Ermöglicht einen schnelleren Wechsel der Videoqualität mit dem RENDITION-REPORT-Tag, das Informationen über die letzten Segmente und Fragmente benachbarter Wiedergabelisten aufzeichnet.

Nur Apple LL-HLS funktioniert nativ auf Apple-Geräten und erfordert daher dessen Implementierung für Echtzeit-Streaming auf diesen Geräten.

HESP

HESP (High Efficiency Stream Protocol) ist ein adaptives Video-Streaming-Protokoll, das auf HTTP basiert und für ein Streaming mit extrem niedrigen Latenzzeiten entwickelt wurde. Es ist in der Lage, Videos mit einer Verzögerung von bis zu 2 Sekunden bereitzustellen. Im Gegensatz zu früheren Lösungen erfordert HESP 10-20 % weniger Bandbreite für das Streaming, indem es die Verwendung einer längeren GOP (Group of Pictures)-Dauer ermöglicht.

Mithilfe des Chunked-Transfer-Encodings erhält der Player zunächst ein JSON-Manifest mit Stream-Informationen und Timing. Der Streaming-Prozess erfolgt in zwei Streams: dem Initialisierungsstream und dem kontinuierlichen Stream.

Vom Initialisierungsstream aus kann der Player jederzeit Bilder anfordern, um die Wiedergabe zu starten, da dieser nur I-Frames (Keyframes) enthält. Sobald die Wiedergabe beginnt, wird der kontinuierliche Stream verwendet und der Player kann mit der Wiedergabe beginnen, nachdem er ein beliebiges Bild vom Initialisierungsstream empfangen hat.

Das ermöglicht eine schnelle und unterbrechungsfreie Videoübertragung und -wiedergabe im Player des Benutzers sowie einen nahtlosen Qualitätswechsel. Die Abbildung zeigt ein Beispiel, bei dem zunächst eine Videoqualität abgespielt und dann auf eine andere gewechselt wird, wobei die Anforderung des Initialisierungsstreams einmal erfolgt.

Warum wir unseren eigenen JIT-Packager entwickelt haben

Um all diese Protokolle zu implementieren, haben wir beschlossen, eine eigene Lösung zu entwickeln. Für diese Entscheidung gibt es mehrere Gründe:

1. Unabhängigkeit von anderen Anbietern: Sich auf die Qualität einer Drittanbieterlösung zu verlassen, bringt Herausforderungen mit sich. Sollten beispielsweise Probleme auftreten, können wir diese erst lösen, wenn der Anbieter sie gelöst hat – vorausgesetzt, dieser ist überhaupt bereit, die notwendigen Änderungen und/oder Verbesserungen vorzunehmen.
2. Infrastruktur von Gcore: Wir verfügen über unsere eigene globale Infrastruktur, die von Verarbeitungsservern bis hin zu Content Delivery Networks reicht. Unser Entwicklungsteam verfügt über das Fachwissen und die Ressourcen, die zur Implementierung unserer eigenen Lösung erforderlich sind.
3. Gemeinsame Merkmale der integrierten Technologien: Die gemeinsamen Eigenschaften der von uns bewerteten Technologien ermöglichen eine nahtlose Integration in ein einheitliches System.
4. Anpassbare Metriken und Überwachung: Mit unserer firmeneigenen Lösung können Metriken und Überwachung nach unseren Vorlieben und mit unseren eigenen Anpassungsoptionen eingerichtet werden.
5. Anpassungsfähigkeit an unsere Bedürfnisse und die unserer Kunden: Da wir über eine eigene Lösung verfügen, können wir diese schnell an spezifische Aufgaben und Kundenanforderungen anpassen.
6. Zukünftige Entwicklungsmöglichkeiten: Die Entwicklung unserer eigenen Lösung ermöglicht es uns, uns in jede beliebige Richtung weiterzuentwickeln. Wenn neue Protokolle und Technologien entwickelt werden, können wir sie nahtlos zu unserem bestehenden Stack hinzufügen.
7. Abwärtskompatibilität mit bestehenden Lösungen: Eine Abwärtskompatibilität mit bestehenden Lösungen ist von wesentlicher Bedeutung. Wir können sorgfältig abschätzen, wie sich neue Innovationen auf die Kunden auswirken könnten, die zuvor auf unsere vorherige Lösung vertraut haben.

Wenn man die spezifischen Technologien berücksichtigt, unterstützen nicht alle Lösungen von Drittanbietern Apple LL-HLS und HESP. Beispielsweise ist der Apple Media Stream Segmenter auf MPEG-2 TS über UDP beschränkt und funktioniert nur unter MacOS, während er Dateien in das Dateisystem hochlädt. HESP-Packager + HTTP Origin hingegen überträgt Dateien über Redis und ist in TypeScript geschrieben.

Es muss hier unbedingt beachtet werden, dass die Verwendung dieser externen Lösungen Ressourcen verbraucht, Verzögerungen und Abhängigkeiten mit sich bringt und sich auf Parallelität und Skalierbarkeit auswirken kann. Darüber hinaus kann die Verwaltung einer Vielzahl von Lösungen die Wartung und den Support erschweren.

Das Funktionsprinzip von JIT Packager

Die Funktionsweise von JIT Packager kann wie folgt skizziert werden:

1. Der Transcoder sendet Streams an unseren Packager.
2. Der Packager generiert im Handumdrehen alle notwendigen Segmente und Wiedergabelisten.
3. Clients fordern Streams vom EDGE-Knoten des CDN an.
4. Dank der API weiß das CDN bereits, von welchem Server es den Inhalt abrufen muss.
5. Die Antwort wird im Speicher des Chunked-Proxys zwischengespeichert.
6. Für alle anderen Clients wird sie direkt aus dem Cache (Zwischenspeicher) bereitgestellt.

Im Durchschnitt erreichten wir eine Caching-Rate von ca. 80 %.

Ergebnisse

Werfen wir einen Blick darauf, was wir mit unserem JIT Packager erreicht haben.

Gleichzeitiges Video-Streaming in den Formaten HLS und DASH und in Formaten mit niedriger Latenzzeit

Wir haben erfolgreich einen einzigartigen JIT Packager entwickelt, der gleichzeitig Videos in HLS, DASH und allen derzeit verfügbaren Streaming-Formaten mit geringer Latenz streamen kann. Er akzeptiert hauptsächlich Video- und Audiostreams im fragmentierten MP4-Format vom Transcoder. Der Server extrahiert direkt alle notwendigen Mediendaten aus den MP4-Dateien und generiert dynamisch Initialisierungssegmente, entsprechende Wiedergabelisten und Videofragmente für das Streaming in allen genannten Streaming-Modi mit minimalen Verzögerungen. Anschließend stehen die Streams für die Verteilung über ein CDN zur Verfügung.

HTTP-Server für die Videoverteilung in verschiedenen Streaming-Formaten

Unsere Lösung arbeitet in einem internen Netzwerk mit HTTP/1.1 ohne TLS. TLS bietet in diesem Zusammenhang keine Vorteile und würde nur unnötigen Overhead verursachen, sodass wir den gesamten Stream noch einmal verschlüsseln müssten. Stattdessen werden die Daten mithilfe des Chunked-Transfer-Encodings übertragen.

Aus diesem Grund haben wir nicht nur einen Packager entwickelt, sondern auch einen HTTP-Server, der Videos in allen zuvor genannten Formaten bereitstellen kann. Darüber hinaus werden für alle Formate die gleichen Video- und Audiostreams verwendet, was eine effiziente Ressourcennutzung gewährleistet.

DVR-Funktion für zeitversetztes Anschauen

Wir haben die DVR-Funktionalität implementiert, um Benutzern, die eine Live-Übertragung verpasst haben, das Zurückspulen und Nachholen zu ermöglichen. Alle Mikrosegmente werden in einem separaten Cache im Speicher des Servers gespeichert. Anschließend werden sie zusammengeführt und als vollständige Videofragmente auf der Festplatte zwischengespeichert. Diese vollständigen Segmente werden dann bei der Wiedergabe von Aufzeichnungen bereitgestellt. DVR-Segmente werden nach Ablauf einer bestimmten Zeitspanne automatisch gelöscht.

Effizientes Caching mit Chunked-Proxy auf CDN-Knoten

Wenn es um Protokolle geht, die Chunked-Transfer-Encoding verwenden, muss unbedingt beachtet werden, dass nicht alle CDNs das Caching von Dateien unterstützen, bevor sie vollständig vom Herkunftsserver heruntergeladen werden. Während Nginx als Proxyserver in der Lage ist, Quellen mit Chunked-Transfer zu verarbeiten und ihre Antworten Stück für Stück weiterzuleiten, werden nachfolgende Anfragen umgangen und direkt an die Quelle gesendet, bis die gesamte Antwort abgeschlossen ist. Der Cache wird nur genutzt, wenn die vollständige Antwort verfügbar ist. Dieser Ansatz erweist sich jedoch für die effiziente Skalierung von Video-Streaming mit niedriger Latenzzeit als unwirksam, insbesondere dann, wenn vermutlich eine beträchtliche Anzahl von Zuschauern gleichzeitig auf das letzte Segment zugreifen wird.

Um dieser Herausforderung zu begegnen, haben wir auf jedem CDN-Knoten einen separaten Caching-Dienst für Chunked-Proxy-Anfragen implementiert. Sein Hauptmerkmal liegt in der Fähigkeit, HTTP-Teilantworten zwischenspeichern zu können. Das bedeutet, dass während der erste Client, der die Anfrage an die Quelle initiiert, seine Antwort erhält, eine beliebige Anzahl von Clients, die dieselbe Antwort erwarten, von unserem Server mit minimaler Gesamtverzögerung bedient wird. Die bereits erhaltenen Teile werden sofort und der Rest dann bereitgestellt, sobald er von der Quelle eintrifft. Dieser Caching-Dienst speichert die weitergeleiteten Anfragen im Speicher des Servers, wodurch wir die Latenzzeit im Vergleich zur Speicherung von Fragmenten auf der Festplatte reduzieren können.

Dabei werden auch die Limits für die Speichernutzung berücksichtigt. Wenn die Gesamtgröße des Caches das Limit erreicht, werden Elemente basierend auf der Reihenfolge entfernt, in der am längsten nicht auf diese zugegriffen wurde. Darüber hinaus haben wir eine spezielle API entwickelt, die es CDN-Edge-Knoten ermöglicht, den Standort des Inhalts im Voraus proaktiv zu bestimmen.

Fazit

Die Entwicklung von JIT Packager hat es uns ermöglicht, unsere Ziele im Bereich Streaming mit niedrigen Latenzzeiten zu erreichen. Wir können über mehrere erweiterte Protokolle gleichzeitig streamen, ohne auf Drittanbieter angewiesen zu sein, was die Benutzererfahrung erheblich verbessert. Wir können umgehend auf Vorfälle reagieren und die Lösung effizienter an die Kundenbedürfnisse anpassen.

Das ist aber noch nicht alles. Zu unseren Plänen gehört eine weitere Reduzierung der Latenzzeit bei gleichzeitiger Beibehaltung von Qualität und Wiedergabestabilität. Zudem arbeiten wir daran, das System als Ganzes zu optimieren, weitere Metriken zur Überwachung und Steuerung hinzuzufügen und die Grenzen der Innovation in diesem Bereich weiter auszureizen.

Wir freuen uns über die bevorstehenden Möglichkeiten und sind auch weiterhin bestrebt, unseren Nutzern qualitativ hochwertige Streaming-Erlebnisse mit niedrigen Latenzzeiten zu bieten.