Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:

Live-Videos sind gerade „liver“ geworden: Einführung von Concurrent Streaming Acceleration

2019-05-16

Lesezeit: 4 Min.
Dieser Beitrag ist auch auf English, Français, 日本語, Español, und 简体中文 verfügbar.

Wir freuen uns, heute Concurrent Streaming Acceleration vorzustellen, eine neue Technik zur Reduzierung der End-to-End-Latenz von Live-Videos im Web beim Einsatz von Stream Delivery.

Lassen Sie uns zunächst einen Blick auf die Latenz bei Live-Streaming werfen: Warum ist sie wichtig und was wurde getan, um sie zu verbessern?

Wie „live“ sind „Live“-Videos?

Live-Streaming macht einen immer größer werdenden Teil der Videos im Web aus. Egal, ob TV-Übertragung, Live-Show oder Online-Klassenzimmer – die Benutzer erwarten, dass das Video schnell und reibungslos ankommt. Und das Versprechen von „live“ ist, dass der Benutzer Ereignisse sieht, wie sie passieren. Aber wie nah an „Echtzeit“ sind Internetvideos, die „live“ sind?

Die Bereitstellung von Live-Videos im Internet ist immer noch schwierig und bringt viel Latenz mit sich:

  1. Die Inhaltsquelle zeichnet das Video auf und sendet es an einen Codierungsserver.

  2. Der Ursprungsserver konvertiert dieses Video in ein Format wie DASH, HLS oder CMAF, das effizient an Millionen von Geräten geliefert werden kann.

  3. In der Regel wird ein CDN verwendet, um das codierte Video weltweit bereitzustellen.

  4. Der Player des Clients dekodiert das Video und rendert es auf dem Bildschirm.

Und das alles unter Zeitdruck – der gesamte Prozess muss in wenigen Sekunden ablaufen, sonst wird das Videoerlebnis beeinträchtigt. Wir bezeichnen die Gesamtverzögerung zwischen dem Zeitpunkt, an dem das Video aufgenommen wurde, und dem Zeitpunkt, an dem es auf dem Gerät eines Endbenutzers betrachtet werden kann, als „End-to-End-Latenz“ (vergleichbar mit der Zeit vom Kameraobjektiv bis zum Bildschirm Ihres Telefons).

Herkömmliche segmentierte Bereitstellung

Videoformate wie DASH, HLS und CMAF funktionieren, indem Sie Videos in kleine Dateien aufteilen, sogenannte „Segmente“. Die typische Segmentdauer beträgt sechs Sekunden.

Wenn ein Client-Player warten muss, bis ein ganzes sechssekündiges Segment codiert, über ein CDN gesendet und dann dekodiert wird, kann eine lange Wartezeit entstehen! Es dauert noch länger, wenn der Client einen Puffer aus Segmenten aufbauen soll, um sich vor Lieferunterbrechungen zu schützen. Ein typischer Player-Puffer für HLS besteht aus drei Segmenten:

Clients müssen möglicherweise drei Sechs-Sekunden-Blöcke puffern, was zu mindestens 18 Sekunden Latenz führt

Wenn Sie Verzögerungen bei der Codierung berücksichtigen, ist es leicht zu erkennen, warum die Latenzzeit für Live-Streaming im Internet in der Regel etwa 20–30 Sekunden beträgt. Das geht besser.

Reduzierte Latenz durch Chunked Transfer Encoding

Ein natürlicher Weg, dieses Problem zu lösen, besteht darin, den Client-Playern zu ermöglichen, die Blöcke während des Downloads oder sogar schon während der Erstellung abzuspielen. Um das zu ermöglichen, bedarf es beim Codieren und Ausliefern der Dateien einer klugen Zusammenarbeit, die als „Chunked Encoding“ (aufgeteilte Codierung) bekannt ist. Dabei werden Segmente in kleinere, mundgerechte Happen oder „Chunks“ (Blöcke) aufgeteilt. Chunked Encoding kann die Live-Latenzzeit in der Regel auf fünf oder zehn Sekunden reduzieren.

Verwirrenderweise ist das Wort „Chunk“ überladen und bedeutet zwei verschiedene Dinge:

  1. CMAF- oder HLS-Chunks, bei denen es sich um kleine Teile eines Segments (in der Regel 1 s) handelt, die auf Schlüsselbilder ausgerichtet sind

  2. HTTP-Chunks, die nur eine Möglichkeit sind, eine beliebige Datei über das Web zu übertragen

Chunked Encoding teilt Segmente in kürzere Blöcke auf

HTTP-Chunks sind wichtig, da Webclients nur eingeschränkt in der Lage sind, Datenströme zu verarbeiten. Die meisten Clients können erst dann mit Daten arbeiten, wenn sie die vollständige HTTP-Antwort oder zumindest einen kompletten HTTP-Chunk erhalten haben. Durch die Verwendung von HTTP Chunked Transfer Encoding ermöglichen wir Videoplayern, Videos schneller zu parsen und zu decodieren.

CMAF-Chunks sind wichtig, damit Decoder die Bit, die sich in den HTTP-Chunks befinden, tatsächlich abspielen können. Ohne eine sorgfältige Codierung des Videos hätten Decoder zufällige Bit einer Videodatei, die nicht wiedergegeben werden können.

CDNs können zusätzliche Pufferung verursachen

Chunked Encoding mit HLS und CMAF wird heute zunehmend im gesamten Web eingesetzt. Ein Grund, der diese Technik so großartig macht, ist, dass HTTP Chunked Encoding von CDNs breit unterstützt wird – es ist seit 20 Jahren Teil der HTTP-Spezifikation.

Die CDN-Unterstützung ist von entscheidender Bedeutung, da sie es ermöglicht, Live-Videos mit niedriger Latenz zu skalieren und ein Publikum von Tausenden oder Millionen Zuschauern gleichzeitig zu erreichen – etwas, das derzeit mit anderen, nicht-HTTP-basierten Protokollen nur sehr schwer zu verwirklichen ist.

Aber leider kann Ihr CDN, selbst wenn Sie Chunking zur Optimierung der Lieferung aktivieren, gegen Sie arbeiten, indem es das gesamte Segment puffert. Um zu verstehen, warum, überlegen Sie, was passiert, wenn viele Menschen gleichzeitig ein Live-Segment anfordern:

Wenn sich die Datei bereits im Cache befindet, großartig! CDNs leisten hervorragende Arbeit bei der Bereitstellung von zwischengespeicherten Dateien für ein großes Publikum. Aber was passiert, wenn sich das Segment noch nicht im Cache befindet? Denken Sie daran – das ist das typische Anforderungsmuster für Live-Videos!

In der Regel sind CDNs in der Lage, bei „Cache Miss“ vom Ursprungsserver zu streamen. Das sieht in etwa so aus:

Aber noch einmal – was passiert, wenn mehrere Personen gleichzeitig die Datei anfordern? CDNs müssen in der Regel die gesamte Datei in den Cache ziehen, bevor sie sie für zusätzliche Benutzer bereitstellen können:

Nur ein Betrachter kann das Video streamen, während andere Clients darauf warten, dass das Segment beim CDN gepuffert wird.

Dieses Verhalten ist verständlich. CDN-Rechenzentren bestehen aus vielen Servern. Um eine Überlastung der Ursprünge zu vermeiden, koordinieren sich diese Server in der Regel untereinander mithilfe eines „Cache Lock“ (Mutex), das es nur einem Server gestattet, eine bestimmte Datei zu einem bestimmten Zeitpunkt vom Ursprung anzufordern. Ein Nebeneffekt davon ist, dass eine Datei, während sie in den Cache gezogen wird, nur dem ersten Benutzer, der sie angefordert hat, zur Verfügung gestellt werden kann. Leider macht dieses Cache Lock auch den Zweck der Verwendung von Chunked Encoding zunichte!

Um es noch einmal zusammenzufassen:

  • Chunked Encoding teilt Videosegmente in kleinere Teile auf

  • Dies kann die End-to-End-Latenz reduzieren, indem es ermöglicht, dass Chunks von Playern abgerufen und decodiert werden, während die Segmente noch auf dem Ursprungsserver produziert werden

  • Einige CDNs neutralisieren die Vorteile von Chunked Encoding, indem sie ganze Dateien innerhalb des CDN puffern, bevor sie an Clients ausgeliefert werden können

Die Cloudflare-Lösung: Concurrent Streaming Acceleration

Wie Sie vielleicht schon erraten haben, denken wir, dass wir es besser machen können. Einfach ausgedrückt, haben wir jetzt die Möglichkeit, nicht zwischengespeicherte Dateien an mehrere Clients gleichzeitig zu liefern, während wir die Datei einmal vom Ursprungsserver abrufen.

Das klingt nach einer einfachen Änderung, aber es erfordert viel Raffinesse, dies sicher zu tun. Wir mussten tiefgreifende Änderungen an unserer Caching-Infrastruktur vornehmen, um das Cache Lock zu entfernen und es mehreren Clients gleichzeitig zu ermöglichen, sicher aus einer einzelnen Datei zu lesen, während sie noch geschrieben wird.

Das Beste daran ist – ganz Cloudflare funktioniert jetzt so! Es ist nicht erforderlich, sich anzumelden oder eine Konfigurationsänderung vorzunehmen, um den Vorteil zu nutzen.

Wir haben diese Funktion vor ein paar Monaten eingeführt und sind mit den bisherigen Ergebnissen sehr zufrieden. Wir messen den Erfolg anhand der „Cache-Lock-Wartezeit“, d. h. wie lange eine Anforderung auf andere Anforderungen warten muss – eine direkte Komponente von Time to First Byte.  Ein OTT-Kunde sah einen Rückgang dieses Messwerts von 1,5 s bei P99 auf fast 0, wie wir erwartet hatten:

Das führt direkt zu einer Verbesserung der End-to-End-Latenzzeit um 1,5 Sekunden. Live-Videos sind gerade „liver“ geworden!

Fazit

Neue Techniken wie Chunked Encoding haben die Live-Bereitstellung revolutioniert und ermöglichen es Inhalteanbietern, Live-Videos mit niedriger Latenz in großem Maßstab zu liefern. Concurrent Streaming Acceleration hilft Ihnen, die Leistungsfähigkeit dieser Technik in Ihrem CDN zu nutzen und potenziell wertvolle Sekunden bei der End-to-End-Latenz zu sparen.

Wenn Sie interessiert daran sind, Cloudflare für die Bereitstellung von Live-Videos zu nutzen, nehmen Sie Kontakt mit unserem Enterprise Sales-Team auf.

Und wenn Sie daran interessiert sind, an Projekten wie diesem zu arbeiten und uns dabei zu helfen, die Bereitstellung von Live-Videos für das gesamte Internet zu verbessern, werden Sie Teil unseresEngineering-Teams!

Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.

Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.

Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
Speed Week (DE)Cloudflare StreamVideoGeschwindigkeit & ZuverlässigkeitProdukt-News

Folgen auf X

Jon Levine|@jplevine
Cloudflare|@cloudflare

Verwandte Beiträge

09. Oktober 2024 um 13:00

Improving platform resilience at Cloudflare through automation

We realized that we need a way to automatically heal our platform from an operations perspective, and designed and built a workflow orchestration platform to provide these self-healing capabilities across our global network. We explore how this has helped us to reduce the impact on our customers due to operational issues, and the rich variety of similar problems it has empowered us to solve....

08. Oktober 2024 um 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

27. September 2024 um 13:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

26. September 2024 um 13:00

Zero-latency SQLite storage in every Durable Object

Traditional cloud storage is inherently slow because it is accessed over a network and must synchronize many clients. But what if we could instead put your application code deep into the storage layer, such that your code runs where the data is stored? Durable Objects with SQLite do just that. ...