Du startest ein Video, und in der Netzwerkansicht erscheinen eine Textliste und mehrere kleine Mediendateien. Das kann zum vorgesehenen Wiedergabeweg gehören. Bei HTTP Live Streaming, kurz HLS, beschreibt eine Wiedergabeliste, welche Medienabschnitte der Player abrufen soll.
HLS bezeichnet diesen Auslieferungsablauf. Der Name sagt für sich allein noch nicht, wie das Bild codiert ist, wie viele Qualitätsstufen vorhanden sind oder ob ein bestimmtes Gerät die Wiedergabe unterstützt. Diese Teile gehören zusammen, erfüllen aber verschiedene Aufgaben.
Liste und Medieninhalt unterscheiden
RFC 8216 beschreibt zwei grundlegende Listenarten: Eine Medienliste verweist auf Abschnitte einer Fassung. Eine übergeordnete Liste, im RFC „Master Playlist“ genannt, kann auf mehrere Varianten verweisen. Der Player erhält so zunächst eine Beschreibung und kann daraus passende Medienabrufe ableiten.
Die Listen enthalten Text und Verweise; die eigentlichen Bild- und Tondaten liegen in den referenzierten Medienressourcen. Ein Segment kann als eigene Datei oder durch einen angegebenen Bytebereich beschrieben sein. Eine HLS-Präsentation ist deshalb nicht zwingend eine Reihe gleich benannter vollständiger Videodateien.
Apples aktuelle HLS-Übersicht ordnet das Verfahren der Auslieferung über gewöhnliche Webserver und Content Delivery Networks zu. Der Name „Live Streaming“ beschränkt es dabei nicht auf laufende Übertragungen: Auch fertige Videos können über HLS bereitgestellt werden.
Unser eigener sechssekündiger Versuch
Für diesen Artikel haben wir am 22.10.2026 ein lokales Testbild mit H.264-Video und AAC-Tonspur erzeugt. Es enthält keine Kundenaufnahme. Mit der vorhandenen FFmpeg-Version 8.0.1 wurde daraus eine HLS-Fassung mit zweisekündigen Abschnitten erstellt. Die tatsächliche Ausgabe enthält:
- „atlas.m3u8“ als Wiedergabeliste.
- „atlas-00.ts“ mit dem ersten angegebenen Abschnitt von zwei Sekunden.
- „atlas-01.ts“ mit den nächsten angegebenen zwei Sekunden.
- „atlas-02.ts“ mit den letzten angegebenen zwei Sekunden.
In der erzeugten Liste steht vor jedem dieser drei Verweise „#EXTINF:2.000000,“ als Dauerangabe. „#EXT-X-PLAYLIST-TYPE:VOD“ kennzeichnet den vorbereiteten Abrufinhalt; „#EXT-X-ENDLIST“ beendet die Medienliste. Die drei deklarierten Abschnittsdauern ergeben zusammen sechs Sekunden. Die Grafik zeigt genau diesen eigenen Fall.
Anschließend haben wir die vollständige lokale Wiedergabeliste mit FFmpeg dekodiert. Der Lauf endete erfolgreich und ohne Fehlermeldung. Damit ist mehr geprüft als das bloße Vorhandensein von vier Dateinamen: Der lokale Decoder konnte die referenzierten Abschnitte zusammen verarbeiten.
Diese Probe hatte genau eine Medienfassung. Es gab keinen gemessenen Qualitätswechsel, keinen Anbieterupload und keinen HLS-Browsertest. Die erzeugten Beispiele bleiben lokale Recherchedateien; die Namen im Artikel sind keine öffentlichen Downloadadressen.
Woher die verschiedenen Qualitätsstufen kommen
Segmentierung allein erzeugt keine Wahl zwischen niedrigem und hohem Datenbedarf. Dafür müssen entsprechende Fassungen vorbereitet und so beschrieben werden, dass ein geeigneter Player sie auswählen kann. MDN erläutert dieses Zusammenspiel von Abschnitten, Qualitätsfassungen und Wiedergabelisten.
Ein vorgestelltes Atlas-Tutorial könnte beispielsweise zwei passend vorbereitete Bildfassungen besitzen. Der Player würde dann nicht beide vollständig nacheinander abspielen, sondern passende Abschnitte einer gewählten Variante abrufen und bei Bedarf zwischen geeigneten Varianten wechseln. Dieses Zwei-Varianten-Szenario ist eine Erklärung, kein zweiter durchgeführter Versuch.
Welche Fassung tatsächlich gewählt wird, hängt vom Player, den verfügbaren Varianten und dem Wiedergabekontext ab. Eine schmale Einbettung oder eine langsame Verbindung ist deshalb keine verlässliche Aussage darüber, welche Daten gerade übertragen wurden. Für einen konkreten Befund muss man die tatsächlichen Abrufe beobachten.
Eine Playlist-URL ist noch keine fertige Zuschaueroberfläche
Zur Wiedergabe gehören ein geeigneter Player und ein passender Browserweg. Eine Adresse, die auf .m3u8 endet, ist zunächst die Adresse einer Beschreibung. Kopierst du sie in einen beliebigen Websiteblock, entsteht daraus nicht automatisch ein bedienbarer Player mit Startknopf, Untertiteln und sinnvoller Fehleranzeige.
Wenn ein Videodienst einen fertigen Einbettungscode anbietet, verwende dessen vorgesehenen Weg. Für eine eigene Implementierung musst du die unterstützten Medienformate und das Playerverfahren gezielt klären. Eine native Unterstützung oder ein JavaScript-Player kann je nach Umgebung eine Rolle spielen; dieser Grundlagenartikel behauptet keinen universellen Einbaucode.
Bei einer Störung die richtige Ebene prüfen
- Ist die Wiedergabeliste erreichbar und gehört sie zur erwarteten freigegebenen Fassung?
- Sind die darin referenzierten Ressourcen unter den angegebenen Adressen tatsächlich erreichbar?
- Passen Player und Medienformate zur geprüften Browserumgebung?
- Trat die Störung schon vor dem ersten Bild oder erst an einer bestimmten späteren Stelle auf?
- Welche konkrete Meldung oder welcher fehlgeschlagene Abruf wurde beobachtet?
Bei unserem lokalen Fall gehören die Liste und alle drei Segmente zusammen. Nur „atlas.m3u8“ an einen anderen Ort zu kopieren würde die referenzierten Abschnitte nicht mitnehmen. Diese kleine Abhängigkeit erklärt, warum ein HLS-Problem an einer Liste, einer Ressource oder ihrer Zuordnung liegen kann.
Die Quellen erklären den grundlegenden HLS-Aufbau; RFC 8216 stammt von 2017 und ist als „Informational“ veröffentlicht. Neuere Erweiterungen und besondere Niedriglatenzverfahren brauchen zusätzliche, aktuelle Detailprüfungen. Für das Verständnis unseres fertigen Beispiels reicht die klare Trennung: Die Liste beschreibt, die Medienabschnitte liefern den Inhalt, der Player führt beides zur Wiedergabe zusammen.
RFC 8216: grundlegender HLS-Aufbau
Apple: aktuelle HLS-Übersicht und weiterführende Dokumentation