HLS: Was es ist, Protokoll und Funktionsprinzip

Was ist HLS?

HTTP Live Streaming (HLS) ist ein Medien-Streaming-Protokoll, das 2009 von Apple entwickelt und erstmals in iOS 3.0 und Safari eingeführt wurde. 2017 wurde das Protokoll durch RFC 8216 als Internetstandard vorgeschlagen, was seinen Status als offene Spezifikation bestätigte, die auf jeder Plattform implementiert werden kann.

Die Hauptidee von HLS besteht darin, einen kontinuierlichen Medienstrom in kurze Segmente von 2–10 Sekunden Dauer zu unterteilen. Jedes Segment ist eine eigenständige Datei, die über eine normale HTTP-Anfrage heruntergeladen werden kann. Die Stromverwaltung erfolgt über Text-Playlists im M3U8-Format, die Verweise auf Segmente und Metadaten für deren korrekte Wiedergabe enthalten.

Adaptivität ist der Hauptvorteil von HLS. Der Server bereitet mehrere Versionen desselben Inhalts mit unterschiedlichen Bitraten vor — von 200 Kbps für schwache Verbindungen bis zu über 20 Mbps für 4K-Video. Der Client wählt automatisch die geeignete Bitrate basierend auf der aktuellen Kanalbandbreite aus. Laut Apple-Forschung (WWDC 2024) reduziert LL-HLS die Umschaltzeit zwischen Bitraten auf 500 Millisekunden und gewährleistet so sanfte Qualitätswechsel ohne wahrnehmbare Pausen.

Entwicklungsgeschichte von HLS

Die erste Version von HLS (2009) unterstützte nur MPEG-2-TS-Segmente mit AAC-Audiocodec und H.264-Videocodec. iOS 8 (2014) fügte Unterstützung für fMP4-Segmente (fragmented MP4) hinzu, wodurch HLS mit moderneren Codecs einschließlich HEVC (H.265) verwendet werden konnte. iOS 11 (2017) führte Unterstützung für HDR10 und Dolby Vision ein. iOS 13 (2019) führte Low-Latency HLS ein und reduzierte die Latenz von traditionellen 6–30 Sekunden auf 2–6 Sekunden.

Im Jahr 2023 erweiterte Apple HLS um Unterstützung für die Codecs AV1 und EVC (Essential Video Coding) und führte Content Steering ein — einen Mechanismus zur dynamischen Umleitung von Clients zwischen CDN-Servern für optimale Lastverteilung. Content Steering ermöglicht es dem Server, Segment-URLs spontan zu ändern und den Client ohne Unterbrechung der Wiedergabe zum nächstgelegenen oder am wenigsten ausgelasteten CDN-Knoten umzuleiten.

Wie funktioniert HLS?

Die HLS-Architektur besteht aus drei Hauptkomponenten: der Serverseite (Origin-Server + Encoder), dem Verteilungsnetzwerk (CDN) und der Clientseite (Player mit HLS-Unterstützung). Der gesamte Prozess — von der Videoerfassung bis zur Wiedergabe auf dem Gerät des Benutzers — umfasst mehrere aufeinanderfolgende Schritte, die jeweils für die Streaming-Qualität entscheidend sind.

Kodierung und Segmentierung

Das Quellvideo wird zunächst in mehrere Varianten mit unterschiedlichen Bitraten und Auflösungen kodiert. Professionelle Encoder wie FFmpeg oder AWS Elemental MediaConvert erstellen gleichzeitig 4–12 Stream-Varianten: von 240p (400 Kbps) bis 4K (40 Mbps). Jede Variante wird in Segmente gleicher Dänge aufgeteilt, typischerweise 2–6 Sekunden für LL-HLS oder 6–10 Sekunden für traditionelles HLS.

Für jede Variante wird eine Varianten-Playlist erstellt, die die URLs aller Segmente und deren Dauer enthält. Zusätzlich wird eine Master-Playlist erstellt, die alle Varianten zusammenfasst und Informationen zu jeder enthält: Auflösung, Bitrate, Codec und Audiospuren. Der Client lädt zunächst die Master-Playlist und wählt dann basierend auf der Analyse der Verbindungsgeschwindigkeit die geeignete Variante aus.

Auslieferung über CDN

Segmente und Playlists werden auf CDN-Servern zwischengespeichert, die sich geografisch nahe an den Benutzern befinden. Die Verwendung des standardmäßigen HTTP-Protokolls zur Auslieferung verschafft HLS einen entscheidenden Vorteil: Jedes CDN, jeder Load Balancer oder Proxyserver, der HTTP unterstützt, funktioniert ohne zusätzliche Konfiguration mit HLS. Dies unterscheidet HLS von Echtzeitprotokollen wie RTMP oder WebRTC, die spezialisierte Server erfordern.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

Die Clientseite verwendet einen adaptiven Bitraten-Algorithmus (ABR). Der HLS-Player lädt die Master-Playlist, analysiert die verfügbaren Varianten und startet die Wiedergabe mit der am besten geeigneten Bitrate. Während der Wiedergabe überwacht der Player ständig die Segment-Downloadgeschwindigkeit und den Füllstand des Puffers und entscheidet, ob auf eine höhere oder niedrigere Bitrate umgeschaltet werden soll. Moderne ABR-Algorithmen berücksichtigen nicht nur die Netzwerkgeschwindigkeit, sondern auch die Puffergröße, den Inhaltstyp und sogar den Stromverbrauch des Geräts.

HLS-Stream-Struktur: Playlists und Segmente

Das Verständnis der Struktur eines HLS-Streams ist notwendig, um Kodierung, Verteilung und Fehlerbehebung bei der Wiedergabe korrekt zu konfigurieren. Jeder HLS-Stream besteht aus zwei Ebenen von Playlists und zahlreichen Mediensegmenten, die in einer strengen Hierarchie organisiert sind.

Master-Playlist

Die Master-Playlist ist der Einstiegspunkt für den HLS-Player. Die Datei mit der Erweiterung .m3u8 enthält Verweise auf alle Stream-Varianten und deren Eigenschaften. Der Player lädt diese Datei zuerst und trifft auf der Grundlage der Informationen über Bitraten und Auflösungen die anfängliche Entscheidung, welche Variante ausgewählt werden soll. Die Master-Playlist kann auch Verweise auf alternative Audiospuren, Untertitel und I-Frame-Playlists für schnelles Vor- und Zurückspulen enthalten.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

Media-Playlist

Die Media-Playlist enthält die eigentliche Liste der Segmente für eine Stream-Variante. Jedes Segment wird mit seiner Dauer und URI angegeben. Die Media-Playlist kann statisch sein (für VOD — eine vollständige Liste aller Segmente) oder dynamisch aktualisiert werden (für Live-Übertragungen — alte Segmente werden entfernt, neue hinzugefügt).

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

Segmentformate

HLS unterstützt zwei Hauptformate für Mediensegmente: MPEG-2 Transport Stream (.ts) und Fragmented MP4 (.m4s oder .mp4). MPEG-2 TS ist das ursprüngliche HLS-Format und bietet maximale Kompatibilität. fMP4 ist ein moderneres Format, das HDR, HEVC und effizientere Komprimierung unterstützt. Apple empfiehlt fMP4 für alle neuen Projekte ab iOS 10 und macOS Sierra.

Zusätzliche HLS-Stream-Elemente umfassen I-Frame-Playlists für schnelles Vor- und Zurückspulen, ID3-Metadaten zur Synchronisation von Untertiteln und Werbemarkierungen sowie Session Data zur Übermittlung von Betrachtungsinformationen an Analyseserver. Alle diese Elemente sind optional, aber ihre Verwendung verbessert die Qualität des Benutzererlebnisses.

Vor- und Nachteile von HLS

HLS dominiert den Videostreaming-Markt dank mehrerer architektonischer Vorteile, hat aber auch Einschränkungen, die bei der Auswahl eines Protokolls für ein bestimmtes Projekt berücksichtigt werden müssen. Vergleichen wir HLS mit alternativen Videolieferprotokollen.

Der Hauptvorteil von HLS ist die native Unterstützung auf allen Apple-Geräten (iPhone, iPad, Apple TV, Mac) über den integrierten AVPlayer. Dies macht HLS zum De-facto-Standard für iOS/macOS-Anwendungen. Darüber hinaus ermöglicht die Verwendung von Standard-HTTP für die Auslieferung das Zwischenspeichern von Inhalten auf jedem CDN und Proxyserver ohne zusätzliche Konfiguration, was die Lieferinfrastruktur erheblich vereinfacht.

Zu den Nachteilen von HLS gehört eine höhere Latenz im Vergleich zu RTMP oder WebRTC für Live-Übertragungen. Selbst mit LL-HLS beträgt die Mindestlatenz 2–6 Sekunden, was für Echtzeit-Interaktionsszenarien inakzeptabel ist. Außerdem generiert HLS mehr Dateien auf dem Server (jedes Segment ist eine separate Datei), was bei einer großen Anzahl gleichzeitiger Streams die Dateisystem belasten kann.

HLS in mobilen Anwendungen

Die Integration von HLS in mobile Anwendungen unterscheidet sich je nach Plattform. Auf iOS und macOS wird HLS auf Betriebssystemebene über AVFoundation und AVPlayer unterstützt, was hardwarebeschleunigte Dekodierung und minimalen Stromverbrauch ermöglicht. Auf Android wird HLS nicht vom integrierten MediaPlayer unterstützt, ist aber über ExoPlayer — den offiziellen Mediaplayer von Google — verfügbar.

HLS auf iOS über AVPlayer

Auf der Apple-Plattform ist die HLS-Wiedergabe dank integrierter Unterstützung in AVPlayer denkbar einfach. Erstellen Sie einfach einen AVPlayer mit der URL der Master-Playlist, und das System übernimmt automatisch das adaptive Bitraten-Umschalten, die Auswahl der Audiospuren und die Verarbeitung von Untertiteln. Der Entwickler erhält außerdem die volle Kontrolle über die Wiedergabe über AVPlayerItem und AVAssetResourceLoader.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

HLS auf Android über ExoPlayer

Für Android wird ExoPlayer verwendet, der HLS über ein separates Erweiterungsmodul unterstützt. ExoPlayer bietet eine feinere Kontrolle über den HLS-Stream: Sie können die Bitratenauswahl verwalten, die Pufferung konfigurieren und Segmentladefehler individuell behandeln. LL-HLS erfordert ExoPlayer Version 2.14.0 oder höher.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

Optimierung von HLS für mobile Netze

Mobile Anwendungen erfordern aufgrund der Instabilität von Mobilfunknetzen und Verkehrsbeschränkungen einen besonderen Ansatz bei der HLS-Konfiguration. Zu den wichtigsten Empfehlungen gehören: Konfiguration der Anfangsbitrate basierend auf dem Netzwerktyp (Wi-Fi oder Mobilfunk), Verwendung kürzerer Segmentdauern (2–4 Sekunden) für schnellere Anpassung, Vorabladen des Puffers beim Wechsel zu Wi-Fi und Priorität der Audiospur bei schwachem Signal.

Apple empfiehlt in der HLS Authoring Specification for Apple Devices (2024) eine Segmentgröße von nicht mehr als 6 Sekunden für mobile Geräte und mindestens 4 Bitratenvarianten. Um Datenverkehr in mobilen Netzen zu sparen, sollte der Server Segmente mit dem HTTP-Header Cache-Control ausliefern, sodass Inhalte auf zwischengeschalteten Proxyservern von Telekommunikationsbetreibern zwischengespeichert werden können.