Was ist HLS?

HLS steht für HTTP Live Streaming und ist ein Streaming-Protokoll, das 2009 von Apple entwickelt wurde. Ursprünglich für die Wiedergabe auf iPhones und iPads gedacht, hat sich HLS zum weltweit dominierenden Standard für Video-Streaming entwickelt — von Live-TV über Sportübertragungen bis hin zu On-Demand-Plattformen.

Das Besondere an HLS: Es nutzt das ganz normale HTTP-Protokoll, also dieselbe Technik, die auch für Webseiten verwendet wird. Das hat weitreichende Konsequenzen für Kompatibilität, Infrastruktur und Firewall-Freundlichkeit, die wir uns im Detail anschauen werden.

Wie funktioniert HLS?

Das Grundprinzip: Segmentierung

HLS zerlegt einen Video-Stream in viele kleine Stücke, sogenannte Segmente. Jedes Segment ist typischerweise 2 bis 10 Sekunden lang und wird als einzelne Datei auf einem Webserver bereitgestellt. Der Player lädt diese Segmente nacheinander herunter und spielt sie nahtlos ab.

Der Ablauf im Detail:

  1. Encoding: Das Quellvideo wird in verschiedenen Qualitätsstufen encodiert
  2. Segmentierung: Jede Qualitätsstufe wird in kurze Segmente aufgeteilt (üblicherweise .ts-Dateien)
  3. Playlist-Erstellung: Für jede Qualitätsstufe wird eine Playlist-Datei erstellt, die alle Segmente auflistet
  4. Master-Playlist: Eine übergeordnete Playlist verweist auf alle Qualitätsstufen
  5. Wiedergabe: Der Player lädt die Master-Playlist, wählt eine Qualitätsstufe und beginnt mit dem Download der Segmente

Segmente und ihre Formate

HLS-Segmente sind in der Regel im MPEG-TS-Format (Transport Stream, .ts-Dateien). Neuere HLS-Versionen unterstützen auch fMP4 (fragmented MP4, .m4s-Dateien), was effizienter ist und weniger Overhead erzeugt.

Ein typisches Segment sieht als HTTP-Anfrage so aus:

GET /stream/segment_00042.ts HTTP/1.1
Host: cdn.example.com

Die Antwort ist eine binäre Videodatei von wenigen hundert Kilobyte bis zu einigen Megabyte — je nach Bitrate und Segmentlänge.

Die Playlist-Datei (M3U8)

Das Herzstück von HLS ist die Playlist-Datei im M3U8-Format. M3U8 ist nichts anderes als eine M3U-Datei in UTF-8-Kodierung. Hier kommen wir zur wichtigen Verbindung: Das M3U-Format, das du von IPTV-Playlists kennst, ist dasselbe Format, das HLS für seine Segment-Playlists verwendet.

Eine einfache HLS-Playlist (Media Playlist) sieht so aus:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:42
#EXTINF:9.97667,
segment_00042.ts
#EXTINF:10.0,
segment_00043.ts
#EXTINF:10.0,
segment_00044.ts
#EXTINF:8.334,
segment_00045.ts

Master Playlist und Varianten

Die Master Playlist (auch Multivariant Playlist) ist die übergeordnete Datei, die verschiedene Qualitätsstufen (Varianten) auflistet:

#EXTM3U
#EXT-X-VERSION:3

#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
quality_360p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=960x540
quality_540p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
quality_720p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
quality_1080p/playlist.m3u8

Das BANDWIDTH-Attribut gibt die benötigte Bitrate in Bits pro Sekunde an, RESOLUTION die Videoauflösung.

Adaptive Bitrate Streaming

Die Master Playlist ermöglicht eines der wichtigsten Features von HLS: Adaptive Bitrate Streaming (ABR). Der Player misst kontinuierlich die verfügbare Bandbreite und wechselt automatisch zwischen den Qualitätsstufen:

  • Schnelle Verbindung: Player wählt 1080p-Variante
  • Bandbreite sinkt: Player wechselt nahtlos auf 720p
  • Verbindung wird wieder besser: Player schaltet zurück auf 1080p

Dieser Wechsel geschieht an Segmentgrenzen — also alle paar Sekunden — und ist für den Zuschauer meist kaum wahrnehmbar. Das Ergebnis: weniger Puffern, durchgängige Wiedergabe.

Der Zusammenhang zwischen M3U8 und HLS

M3U8 ist das Playlist-Format von HLS

Wenn du in der IPTV-Welt auf Dateien mit der Endung .m3u8 stößt, handelt es sich um HLS-Playlists. Die Dateiendung .m3u8 zeigt an, dass es sich um eine M3U-Datei in UTF-8-Kodierung handelt — und im HLS-Kontext bedeutet das: eine Playlist, die entweder auf Segmente oder auf Varianten verweist.

IPTV-Playlists vs. HLS-Playlists

Es gibt einen wichtigen Unterschied:

  • IPTV-Playlist (.m3u/.m3u8): Eine Liste von Kanälen mit Metadaten und Stream-URLs. Jeder Eintrag ist ein eigenständiger Kanal.
  • HLS-Playlist (.m3u8): Eine technische Datei, die entweder Segmente eines einzelnen Streams auflistet (Media Playlist) oder verschiedene Qualitätsstufen (Master Playlist).

In einer IPTV-Playlist verweisen die Stream-URLs häufig auf HLS-Streams — also auf .m3u8-Dateien, die dann ihrerseits auf die eigentlichen Video-Segmente verweisen. Es ist also eine Playlist, die auf Playlists verweist.

IPTV-Playlist (.m3u)
  └─ Kanal-URL: https://cdn.example.com/live/kanal1/master.m3u8
       └─ Master Playlist (.m3u8)
            ├─ 720p/playlist.m3u8
            │    └─ segment_001.ts, segment_002.ts, ...
            └─ 1080p/playlist.m3u8
                 └─ segment_001.ts, segment_002.ts, ...

Andere Streaming-Protokolle

MPEG-DASH

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) ist der offene, standardisierte Gegenspieler zu HLS. DASH wurde von der MPEG-Gruppe (Moving Picture Experts Group) als ISO-Standard (ISO/IEC 23009) entwickelt.

Funktionsweise:

  • Ähnliches Prinzip wie HLS: Segmentierung + Manifest-Datei
  • Manifest im XML-Format (.mpd statt .m3u8)
  • Segmente in fMP4-Format (effizienter als MPEG-TS)
  • Ebenfalls Adaptive Bitrate Streaming

Hauptunterschiede zu HLS:

AspektHLSMPEG-DASH
EntwicklerAppleMPEG / ISO
Manifest-FormatM3U8 (Textbasiert)MPD (XML)
Standard-SegmentformatMPEG-TS / fMP4fMP4 / WebM
DRMFairPlay + Widevine + PlayReadyWidevine + PlayReady
Codec-FlexibilitätH.264, H.265Codec-agnostisch
iOS-SupportNativNur über MSE/JavaScript
StandardisierungApple-proprietärISO-Standard

In der Praxis verwenden Plattformen wie YouTube und Netflix MPEG-DASH, während die meisten Live-TV- und IPTV-Anbieter auf HLS setzen.

RTMP (Legacy)

RTMP (Real-Time Messaging Protocol) wurde von Macromedia (später Adobe) für Flash Player entwickelt. Es war jahrelang der Standard für Live-Streaming, ist aber mit dem Ende von Flash Player weitgehend aus der Wiedergabe verschwunden.

Warum RTMP noch existiert:

  • Wird noch häufig für die Zulieferung (Ingest) von Live-Streams verwendet
  • OBS Studio und andere Encoder senden oft per RTMP an Streaming-Server
  • Der Server konvertiert dann zu HLS oder DASH für die Wiedergabe

Warum RTMP für die Wiedergabe ungeeignet ist:

  • Benötigt Flash Player (eingestellt) oder spezielle Player
  • Nicht firewall-freundlich (eigenes Protokoll, nicht HTTP)
  • Kein adaptives Streaming
  • Keine CDN-Kompatibilität

In IPTV-Playlists findest du gelegentlich noch rtmp://-URLs. Viele Player können diese zwar abspielen, aber die Tendenz geht klar Richtung HLS.

UDP / Multicast

UDP-Multicast ist ein grundlegend anderer Ansatz: Statt dass jeder Client seinen eigenen Stream vom Server abruft (Unicast), wird ein einzelner Stream an alle Clients gleichzeitig ausgeliefert (Multicast).

Einsatzbereich:

  • Klassisches IPTV über das Netzwerk des Internetanbieters (z. B. Telekom MagentaTV über eigene Infrastruktur)
  • Hotelnetze und geschlossene Netzwerke
  • Unternehmensumgebungen

In IPTV-Playlists erkennbar an:

udp://@239.1.1.1:1234
rtp://@239.1.1.1:1234

UDP/Multicast funktioniert nur innerhalb des Netzwerks des jeweiligen Anbieters und kann nicht über das offene Internet geroutet werden. Für webbasierte IPTV-Playlists spielt es daher keine Rolle.

RTSP (Real Time Streaming Protocol)

RTSP wird hauptsächlich bei IP-Kameras und Überwachungssystemen eingesetzt. Es ist ein Kontrollprotokoll, das die Wiedergabe steuert (Play, Pause, Seek), während die eigentlichen Daten über RTP (Real-time Transport Protocol) übertragen werden.

Für IPTV ist RTSP kaum noch relevant, taucht aber gelegentlich in älteren Playlists auf.

Vergleichstabelle der Protokolle

MerkmalHLSMPEG-DASHRTMPUDP/Multicast
TransportHTTPHTTPTCP (eigenes)UDP
AdaptivJaJaNeinNein
Latenz6-30 Sek.2-10 Sek.1-3 Sek.< 1 Sek.
CDN-fähigJaJaEingeschränktNein
Firewall-freundlichJa (Port 80/443)Ja (Port 80/443)Nein (Port 1935)Nein
Browser-SupportJa (nativ + hls.js)Ja (via MSE)Nein (Flash tot)Nein
VerschlüsselungAES-128 + HTTPSCENC (Common Encryption)RTMPSKeine (standard)
Live-StreamingJaJaJaJa
VODJaJaEingeschränktNein
Verbreitung (IPTV)DominantSeltenLegacyISP-intern

Warum HLS dominiert

CDN-Freundlichkeit

Da HLS auf HTTP basiert, können alle existierenden Content-Delivery-Networks (CDNs) HLS-Streams ohne Anpassungen ausliefern. CDN-Server cachen die Segmente und liefern sie vom nächstgelegenen Edge-Server aus — das reduziert Latenz und Serverlast erheblich.

Firewall-Kompatibilität

HLS nutzt die Standard-Ports 80 (HTTP) und 443 (HTTPS). Diese Ports sind in praktisch jedem Netzwerk offen. Andere Protokolle wie RTMP (Port 1935) werden von Firewalls häufig blockiert, was in Firmennetzen oder öffentlichen WLANs zu Problemen führt.

Adaptive Qualität

Die automatische Qualitätsanpassung sorgt dafür, dass der Stream unter wechselnden Netzwerkbedingungen stabil bleibt. Statt eines kompletten Abbruchs wird die Qualität temporär reduziert — ein deutlich besseres Nutzererlebnis als Buffering-Pausen.

Universeller Browser-Support

Moderne Browser unterstützen HLS entweder nativ (Safari) oder über JavaScript-Bibliotheken wie hls.js (Chrome, Firefox, Edge). Damit kann HLS ohne Plugins direkt im Browser wiedergegeben werden — ein entscheidender Vorteil gegenüber älteren Protokollen, die Flash oder andere Plugins benötigten.

Browser-Support für HLS

Native Unterstützung

  • Safari (macOS, iOS): Vollständige native HLS-Unterstützung — Apple hat das Protokoll schließlich erfunden
  • Microsoft Edge (Legacy): Native Unterstützung in der alten EdgeHTML-Version

Via JavaScript (hls.js)

Alle anderen Browser unterstützen HLS über die Media Source Extensions (MSE) API in Kombination mit einer JavaScript-Bibliothek:

  • Chrome: Über hls.js
  • Firefox: Über hls.js
  • Edge (Chromium): Über hls.js
  • Opera: Über hls.js

hls.js ist eine Open-Source-Bibliothek (ca. 200 KB), die HLS-Streams im Browser abspielen kann, indem sie die M3U8-Playlist parst, Segmente herunterlädt und sie über die MSE-API an das HTML5-Video-Element übergibt.

Der Browser-Player im M3U Playlist Editor

Im M3U Playlist Editor kannst du Streams direkt im Browser abspielen, ohne eine externe Anwendung installieren zu müssen. Der integrierte Browser-Player nutzt hls.js für die Wiedergabe von HLS-Streams.

Funktionsweise

Wenn du im M3U Playlist Editor auf den Browser-Play-Button klickst, passiert folgendes:

  1. hls.js wird geladen — Die Bibliothek wird erst bei Bedarf nachgeladen (Lazy Loading), sodass sie die initiale Ladezeit der Seite nicht beeinflusst
  2. Master Playlist wird abgerufen — hls.js lädt die M3U8-Datei des Streams
  3. Qualitätsstufe wird gewählt — Basierend auf der verfügbaren Bandbreite wird automatisch die passende Variante ausgewählt
  4. Segmente werden gestreamt — Die Video-Segmente werden nacheinander geladen und abgespielt

Player-Features

Der Browser-Player erscheint als schwebendes, verschiebbares Fenster, das du frei auf der Seite positionieren kannst. So kannst du gleichzeitig deine Playlist bearbeiten und einen Kanal im Hintergrund schauen. Der Player bietet:

  • Adaptive Qualität: Automatische Anpassung an die Bandbreite
  • Verschiebbar: Frei positionierbar auf der Seite
  • Größe anpassbar: Fenster nach Bedarf vergrößern oder verkleinern
  • Minimierbar: Bei Bedarf auf eine kompakte Ansicht reduzierbar

Qualitätsstufen und adaptives Streaming in der Praxis

Typische Qualitätsstufen

BezeichnungAuflösungTypische BitrateBandbreite empfohlen
SD640 x 360800 kbit/s2 Mbit/s
SD+960 x 5401.400 kbit/s3 Mbit/s
HD1280 x 7202.800 kbit/s5 Mbit/s
Full HD1920 x 10805.000 kbit/s10 Mbit/s
4K UHD3840 x 216015.000 kbit/s25 Mbit/s

Wie der Player die Qualität wählt

Der ABR-Algorithmus von hls.js berücksichtigt mehrere Faktoren:

  • Download-Geschwindigkeit der letzten Segmente
  • Buffer-Füllstand — wie viele Sekunden sind bereits vorgeladen
  • Wechselhistorie — häufiges Hin-und-Her-Wechseln wird vermieden
  • Bildschirmgröße — auf kleinen Displays bringt 4K keinen sichtbaren Vorteil

Häufige HLS-Probleme und Lösungen

Endloses Buffering

Ursache: Bandbreite reicht für die gewählte Qualitätsstufe nicht aus, und der Player wechselt nicht schnell genug auf eine niedrigere Stufe.

Lösung: Falls der Stream nur eine einzige Qualitätsstufe bietet (kein adaptives Streaming), hilft nur eine bessere Internetverbindung. Bei Streams mit mehreren Qualitätsstufen sollte der Player automatisch herunterschalten — wenn nicht, liegt das Problem meist auf Serverseite.

Stream startet nicht (404-Fehler)

Ursache: Die M3U8-Playlist-URL ist nicht mehr erreichbar oder der Server ist offline.

Lösung: Im M3U Playlist Editor kannst du den Stream-Check nutzen, um die Erreichbarkeit aller Kanäle zu prüfen. Kanäle, die einen Timeout oder Fehler zurückgeben, werden entsprechend markiert.

Audio-Video-Synchronisation

Ursache: Unterschiedliche Segment-Dauern für Audio und Video oder fehlerhafte Timestamps in den Segmenten.

Lösung: Ein Neustart des Streams (Stop und Play) behebt das Problem meist. Ist es dauerhaft, liegt der Fehler auf Seiten des Encoders.

CORS-Fehler im Browser

Ursache: Der Streaming-Server sendet keine CORS-Header, die dem Browser erlauben, die Segmente von einer anderen Domain zu laden.

Lösung: Das ist ein serverseitiges Problem. Der Streaming-Server muss den Access-Control-Allow-Origin-Header setzen. Als Workaround kann ein Proxy-Server zwischengeschaltet werden.

Schwarzes Bild, aber Audio funktioniert

Ursache: Der Video-Codec wird vom Browser nicht unterstützt. H.265 (HEVC) ist beispielsweise in vielen Browsern nicht verfügbar.

Lösung: H.264 (AVC) wird von allen Browsern unterstützt. Wenn der Stream in H.265 encodiert ist, hilft oft ein externer Player wie VLC, der einen Software-Decoder nutzen kann.

Zukunft der Streaming-Protokolle

LL-HLS (Low-Latency HLS)

Apple hat mit LL-HLS eine Erweiterung vorgestellt, die die Latenz von HLS drastisch reduziert — von 6-30 Sekunden auf unter 2 Sekunden. Das wird erreicht durch:

  • Partial Segments: Segmente werden in Teilen ausgeliefert, noch bevor sie vollständig sind
  • Preload Hints: Der Server kündigt das nächste Segment an, bevor es fertig ist
  • Rendition Reports: Informationen über andere Qualitätsstufen werden in jeder Playlist mitgeliefert

HESP und SRT

Neben den etablierten Protokollen gibt es neuere Entwicklungen:

  • HESP (High Efficiency Streaming Protocol): Zielt auf Sub-Sekunden-Latenz bei gleichzeitiger CDN-Kompatibilität
  • SRT (Secure Reliable Transport): Open-Source-Protokoll von Haivision, primär für die Zulieferung (Ingest), zunehmend auch für Last-Mile-Delivery

Fazit

HLS hat sich aus gutem Grund zum dominierenden Streaming-Protokoll entwickelt: Es funktioniert über Standard-HTTP, ist mit jedem CDN kompatibel, durchdringt Firewalls problemlos und bietet mit Adaptive Bitrate Streaming eine robuste Wiedergabe unter wechselnden Netzwerkbedingungen. Die Verbindung zwischen M3U8 und HLS ist kein Zufall — das vertraute M3U-Format bildet das technische Rückgrat des Protokolls. Im M3U Playlist Editor kommt diese Technik direkt zum Einsatz: Der integrierte Browser-Player nutzt hls.js, um HLS-Streams ohne externe Software direkt im Browser wiederzugeben — inklusive automatischer Qualitätsanpassung und als verschiebbares Overlay, das die gleichzeitige Playlist-Bearbeitung ermöglicht.

Teste den M3U Playlist Editor kostenlos

Keine Kreditkarte erforderlich