%20(1).webp)
Im Jahr 2009 führte Apple ein HTTP Live Streaming (HLS) als Möglichkeit, Live- und On-Demand-Audio- und Videoinhalte über das Internet zu streamen. Ist das jetzt das am weitesten verbreitete Video-Streaming-Protokoll auf der ganzen Welt, mit Unterstützung für alle gängigen Browser und Geräte.
In diesem Blog werden wir uns damit befassen, warum LL-HLS entwickelt wurde, was es ist, wie es sich von ll hls vs. hls unterscheidet, was seine herausragenden Merkmale sind, wie es im Vergleich zu LL-DASH abschneidet und ein paar Dinge, die man beachten sollte bei der Umsetzung.
Es gibt einen Teil der ...
Wie oben erläutert, ist HLS ein Streaming-Medienbereitstellungsprotokoll, das HTTP verwendet, um Video- und Audioinhalte über das Internet bereitzustellen. Es ist ein recht beliebtes Protokoll, das von OTT-Dienstanbietern und anderen großen Browsern und Geräten verwendet wird.
Andererseits ist ll hls eine Variante von HLS, die für Streaming mit geringer Latenz optimiert ist. Es verkürzt die Zeit zwischen dem Einleiten der Wiedergabe durch einen Benutzer und dem Sehen oder Hören des Inhalts (bekannt als „Latenz“). Dies kann besonders wichtig für Live-Streams sein, bei denen bereits wenige Sekunden Verzögerung das Erlebnis für die Zuschauer weniger angenehm machen können.
Der wichtigste technische Unterschied zwischen HLS und HLS Low Latency ist das Protokoll, das beide für die Verarbeitung des Streamings verwenden. HTTP-Live-Streaming verwendet einen einzigartigen Puffermechanismus, der vor dem Streaming darauf wartet, dass das gesamte Segment heruntergeladen wurde. Dies kann sich auf die Latenz auswirken, da die Zuschauer warten müssen, bis das gesamte Segment heruntergeladen ist, bevor sie Videoinhalte genießen können.
hls-Streaming mit geringer Latenz nutzt Server-Push, was zur Reduzierung der Latenz beiträgt. Das bedeutet, dass der Server die Videosegmente an den Empfänger weiterleitet. Die Wiedergabe des Videos beginnt, sobald die ersten Segmente des Videos heruntergeladen sind. Dadurch wird letztendlich die Latenz reduziert, da die Zuschauer das Video ansehen können, während die anderen Segmente heruntergeladen werden.
Da HLS mit geringer Latenz eine Chunked-Transfer-Codierung verwendet, wird die Latenz reduziert. Daher liegt die niedrige Latenz von HLS typischerweise bei etwa 2 bis 5 Sekunden, verglichen mit 6 bis 30 Sekunden bei HLS. Dies macht HLS-Streaming mit geringer Latenz zu einer besseren Wahl für Live-Streaming-Anwendungen, bei denen die Latenz entscheidend ist.
Kommen wir nun zum Geschäftlichen.
HLS, der Vorgänger von LL-HLS, wurde eingeführt, um hochwertige Inhalte in großem Maßstab über Geräte und Plattformen hinweg zu streamen. Allerdings hatte die skalenorientierte Streaming-Architektur ihren Preis, nämlich die Latenz. Für den Uneingeweihten: Latenz ist die Zeit, die von der Videoerstellung (auf einer Kamera) bis zur endgültigen Wiedergabe (auf dem Gerät eines Benutzers) vergeht, auch „Glas-zu-Glas-Latenz“ genannt. Dazwischen muss dieser Videostream vor seiner Wiedergabe kodiert (sowohl Audio als auch Video), segmentiert, verpackt, aufgelistet, heruntergeladen, bereitgestellt, dekodiert, lippensynchronisiert und gepuffert werden. Das Streaming-Protokoll (wie HLS) übernimmt die ganze schwere Arbeit.
Während HLS in puncto Qualität und Kompatibilität hervorragende Arbeit geleistet hat, sind bei seiner Entwicklung im Laufe der Jahre immer wieder Kompromisse bei der Latenz eingegangen. Und es ergab Sinn. Damals war Latenz kein Problem. Dies ist jedoch nicht mehr der Fall. Mit dem Aufkommen von Social Media und Live-Streaming wünschen sich die Menschen nun Inhalte in Echtzeit. Sie wollen nicht mehr lange warten. Hier ist eine Verzögerung von 30-50 Sekunden einfach unerträglich.
Es macht nur Sinn, dass Apple (das HLS verwaltet) irgendwann eine optimierte Lösung für Streaming mit geringer Latenz entwickeln würde. Also, das haben sie getan! Im Jahr 2019, auf der WWDC, Apple hat Low-Latency HLS oder LL-HLS angekündigt. Es wurde mit einigen Modifikationen auf bestehenden HLS-Spezifikationen aufgebaut, um eine niedrige Latenz (<5 s) zu erreichen. Schauen wir uns an, wie LL-HLS dies schafft, ohne Kompromisse bei Qualität oder Kompatibilität einzugehen:
LL-HLS nimmt einige wesentliche Änderungen an der bestehenden HLS-Spezifikation vor. Zu diesen Änderungen gehören:
In LL-HLS werden Segmente weiter in Teile unterteilt (HLS-Teilsegmente), wodurch die einzelnen Dateigrößen verringert werden. Dadurch ist es möglich, die Wiedergabe bereits zu starten, bevor das gesamte Segment heruntergeladen wurde (im Gegensatz zu HLS, wo Sie auf das vollständige Segment warten müssen).
Die Wiedergabeliste wird in LL-HLS mit geringeren Übertragungskosten im Vergleich zu HLS aktualisiert. Dies geschieht, indem der Server aufgefordert wird, Delta-Updates bereitzustellen, die die relevanten Teile der Playlist aktualisieren, die bereits beim Client verfügbar sind.
Die HTTP-GET-Anfrage eines Players kann „Delivery Directives“ in LL-HLS enthalten. Dabei handelt es sich um spezielle Abfrageparameter, die ein zukünftiges Segment in der Playlist-Antwort anfordern. Der Server blockiert dann diese Anfrage, bis das angegebene Segment verfügbar ist. Es macht das Abfragen von Wiedergabelisten überflüssig und entlastet dadurch die Server- und Netzwerkbandbreite.
Um die Latenz weiter zu reduzieren, führt LL-HLS Preload-Hinweise ein. Dabei handelt es sich um spezielle Tags in der Playlist, die den Player anweisen, mit dem Abrufen eines Segments zu beginnen, noch bevor es für die Wiedergabe benötigt wird. So kann das Segment bei Bedarf sofort und ohne Verzögerung abgespielt werden.
LL-HLS minimiert die Anzahl der Roundtrips während der Bitratenanpassung. Dies erfolgt durch das Hinzufügen von EXT-X-RENDITION-REPORT-Tags für alle Medienwiedergabelisten in einer multivarianten Wiedergabeliste. Diese Tags stellen Informationen bereit, z. B. die letzte Mediensequenznummer und den Teil, der sich derzeit in der Medienwiedergabeliste befindet. Auf diese Weise kann der Client benötigte Teile vom Server anfordern, ohne eine völlig neue Medienwiedergabeliste abrufen zu müssen.
Es gibt einige wichtige Unterschiede zwischen ihnen, die Sie kennen sollten, bevor Sie entscheiden, welches für Ihren Anwendungsfall besser ist.
Hier sind einige Unterschiede und Gemeinsamkeiten zwischen LL-HLS und HLS:
Wie wir gesehen haben, ist der größte Unterschied zwischen LL-HLS und HLS die Latenz. Mit LL-HLS ist es Apple gelungen, die Latenz deutlich zu reduzieren (auf unter 5 Sekunden) im Vergleich zu regulärem HLS (das eine Latenz von etwa 30 Sekunden hat. Diese Latenz ist sogar geringer als die Latenz beim HD-Kabel-TV-Streaming. Als Infolgedessen bietet LL-HLS Benutzern ein nahezu Echtzeit-Anzeigeerlebnis und sollte priorisiert werden, wenn die Latenz für einen bestimmten Anwendungsfall wichtig ist.
Es gibt keinen erkennbaren Qualitätsunterschied zwischen LL-HLS- und HLS-Streams. Beide bieten hochwertiges Video-Streaming in großem Maßstab. Allerdings ist LL-HLS für Bedingungen mit geringer Netzwerkbandbreite nicht die beste Lösung.
Eines der besten Dinge an HLS und LL-HLS ist ihre Kompatibilität mit allen gängigen Browsern und Geräten. Einige der Zu den beliebten Browsern, die LL-HLS unterstützen, gehören: AVPlayer (iOS), Exoplayer (Android), THEOPlayer, JWPlayer, HLS.js, VideoJS und AgnoPlay. Im Gegensatz zu anderen Protokollen müssen Sie sich also keine Sorgen darüber machen, ob Ihre Zuschauer Ihren Stream sehen können oder nicht.
Der Einsatz eines regulären HLS ist günstiger als der Einsatz von LL-HLS.
Die Implementierung von LL-HLS ist aufgrund seiner zusätzlichen Funktionen (wie Preload-Hinweise und Wiedergabeberichte) komplexer als die von HLS. Sie müssen also gut verstehen, wie es funktioniert, bevor Sie es implementieren können.
Schauen wir uns nun einige Vor- und Nachteile der Verwendung von LL-HLS für Streaming mit geringer Latenz an:
Zu den Vorteilen der Verwendung von LL-HLS für Streaming mit geringer Latenz gehören:
Wie aus dem Namen hervorgeht, wurde LL-HLS unter Berücksichtigung der Latenz entwickelt. Das Streaming-Protokoll bietet ein nahezu Echtzeit-Glas-zu-Glas-Seherlebnis. In bestimmten Szenarien kann mit LL-HLS auch eine Latenz von <2 Sekunden erreicht werden. Dies macht es ideal für Live-Streams wie Live-Sport, Nachrichten, Game-Streaming usw., bei denen es auf jede Sekunde ankommt.
Ein weiterer Vorteil der Verwendung von LL-HLS besteht darin, dass die Qualität nicht durch Latenz beeinträchtigt wird. Es verwendet dieselben Codecs (wie H.264 und H.265) wie normales HLS und bietet ein hochwertiges Video-Streaming-Erlebnis unter den gewünschten Netzwerkbedingungen.
Die Herausforderung bei den meisten Streaming-Protokollen, insbesondere denen mit geringer Latenz, besteht darin, dass sie schwer zu skalieren sind. Dies ist bei LL-HLS nicht der Fall. Es baut auf HLS auf und verwendet Standard-HLS-Pakete, was die Implementierung und Skalierung erheblich vereinfacht. Dadurch können Sie problemlos Tausende von gleichzeitigen Benutzern einbeziehen.
Das Beste an LL-HLS ist, dass es mit allen gängigen Browsern und Geräten kompatibel ist, einschließlich iOS, Android, macOS, Windows, tvOS und so weiter. Diese Kompatibilität ermöglicht es, mit Ihren Live-Streams ein größeres Publikum zu erreichen, ohne sich Gedanken darüber machen zu müssen, ob diese es sehen können oder nicht.
LL-HLS ist ein neues Streaming-Protokoll und wird daher nicht so umfassend unterstützt wie sein Vorgänger. Dies kann es schwierig machen, bestimmte Informationen zu finden oder Probleme zu beheben, die bei der Bereitstellung des Protokolls auftreten könnten.
Ein weiterer Nachteil der Verwendung von LL-HLS besteht darin, dass seine Implementierung im Vergleich zu regulärem HLS aufgrund seiner zusätzlichen Funktionen komplexer ist. Abgesehen von den bereits erwähnten großen Problemumgehungen bietet LL-HLS mehrere Optimierungen, die manchmal ziemlich überwältigend sein können.
Die mit der Implementierung von LL-HLS verbundenen Kosten sind aufgrund der zusätzlichen Infrastruktur, die für Streaming mit geringer Latenz erforderlich ist, auch höher als bei regulärem HLS. Diese Kosten lohnen sich jedoch, wenn Ihr Anwendungsfall die Bereitstellung von Inhalten in Echtzeit erfordert.
Obwohl LL-HLS oft auch mit WebRTC verglichen wird, ist der einzige faire Vergleich der mit LL-DASH.
Hier ist ein kurzer Vergleich der beiden Streaming-Protokolle:
LL-HLS verwendet HTTP Live Streaming (HLS), ein proprietäres Apple-Protokoll, während LL-DASH den offenen Standard Dynamic Adaptive Streaming over HTTP (DASH) verwendet.
LL-HLS wurde speziell für Apple-Geräte entwickelt. Da es jedoch abwärtskompatibel mit HLS-Playern ist, wird es auch plattform- und geräteübergreifend unterstützt. LL-DASH wird von Apple-Geräten nicht unterstützt.
Die Latenz von LL-HLS und LL-DASH ist vergleichbar. Je nach Anwendungsfall und erforderlicher Berechnung kann jedoch beides eine höhere oder niedrigere Latenz haben.
Während LL-HLS-„Teile“ einzeln adressierbar sind (als winzige Dateien oder Bytebereiche im gesamten Segment), ist dies bei LL-DASH-„Chunks“ (oder „Fragmenten“) nicht der Fall. Dies bedeutet, dass der Client in LL-DASH nicht warten muss, bis der Server das Segment vollständig codiert hat, bevor er die vorhergehenden Blöcke sendet.
Sowohl im HLS- als auch im DASH-Protokoll fragt der Client den Server in regelmäßigen Abständen (z. B. 10 Sekunden) ab, um nach Aktualisierungen zu suchen und neue Inhalte abzurufen. Allerdings ist es sowohl in LL-HLS als auch in LL-DASH möglich, eine Wiedergabelistenaktualisierung ohne Abfrage von Clients zu erreichen. Während LL-HLS dies mit seinen Lieferanweisungen (_HLS_msn= , _HLS_part= , & _HLS_skip=YES|v2), LL-DASH ist nicht auf eine Manifestaktualisierung angewiesen, damit ein Player einen neuen Block verstehen kann.
.webp)
Sowohl im LL-HLS- als auch im LL-DASH-Protokoll verwendet der Inhaltsschutz MPEG-CENC-Standards (Common Encryption). Beide Protokolle unterstützen auch das Common Media Application Format (CMAF). In Bezug auf Codecs ist LL-DASH codec-agnostisch, während LL-HLS nur bestimmte Codecs für die Codierung zulässt.
Beide Protokolle bieten adaptives Bitraten-Streaming. Sie helfen Spielern, basierend auf sich ändernden Netzwerkbedingungen automatisch zwischen mehreren Wiedergaben zu wechseln, ohne das Wiedergabeerlebnis für die Zuschauer zu unterbrechen. Der Unterschied zu LL-HLS besteht jedoch darin, dass es über mehrere Streams für unterschiedliche Bitraten und Auflösungen verfügt. LL-DASH verfügt nur über einen Stream für eine bestimmte Bitrate und Auflösung.
Ein weiterer Vorteil von LL-HLS gegenüber LL-DASH hängt mit dem Inhaltsschutzmechanismus zusammen, d. h. woher wissen Sie, ob Ihr Encoder eine verschlüsselte Datei mit gültigen Signaturen erstellt hat? Um dies zu überprüfen, verwendet das HLS-Protokoll EXT-X-KEY-Tags, während DASH auf PSSH-Boxen in MP4-Dateien oder separaten Init-Segmenten außerhalb von MP4s, sogenannten Xlinks, angewiesen ist – beide Methoden erfordern zusätzliche Netzwerk-Roundtrips, die bei Live-Streaming-Ereignissen zu erheblichen Verzögerungen führen können. Um dieses Problem anzugehen und die Dinge einfacher und effizienter zu machen, hat Apple eine Lösung entwickelt, bei der Schlüssel-ID- und IV-Werte direkt in die m3u8-Wiedergabeliste eingefügt wurden, damit Spieler diese vor dem Herunterladen eines Segments überprüfen können – keine zusätzliche Anfrage/Antwort erforderlich!
LL-HLS ist eine gute Wahl für Streaming mit geringer Latenz, wenn Sie ein Protokoll suchen, das mit allen gängigen Browsern und Geräten kompatibel ist. Es ist jedoch wichtig zu bedenken, dass die Implementierung im Vergleich zum regulären HLS komplexer ist.
Falls Sie Hilfe benötigen, wenden Sie sich gerne an uns.
Hat Ihnen diese Lektüre gefallen?