Adaptives Streaming: Wie HLS und DASH die Videoqualität anpassen

Bei einem herkömmlichen Download wird die Videodatei vollständig abgerufen; bei der progressiven Wiedergabe kann der Player das Video anzeigen, bevor der Download abgeschlossen ist. Beim adaptiven Streaming wird der Inhalt zusätzlich in Segmente aufgeteilt und in verschiedenen Qualitäten angeboten. Der praktische Unterschied besteht darin, dass der Client die Wiedergabe starten kann, ohne das gesamte Video zu empfangen, und während der Sitzung zu einer Darstellung mit niedrigerer oder höherer Qualität wechseln kann.

Streaming bedeutet nicht, dass das Video notwendigerweise als unteilbarer Strom ankommt oder dass temporäre Informationen nie gespeichert werden. Der Player hält Daten in einem Puffer, um während der Anforderung der nächsten Segmente weiter abzuspielen. Wenn der Download verzögert wird und der Puffer leer ist, stoppt das Bild; wenn die Verbindung Spielraum bietet, kann der Player Daten akkumulieren oder eine Darstellung mit höherer Bitrate ausprobieren. Die Kontinuität hängt vom Gleichgewicht zwischen der Liefergeschwindigkeit, dem Videoverbrauch und den Entscheidungen des Clients ab.

Es ist auch sinnvoll, zwischen dem Lieferprotokoll und dem Codec zu unterscheiden. HLS und MPEG-DASH beschreiben, wie die Präsentation organisiert und angefordert wird – beispielsweise durch Manifeste und Segmente –; H.264, HEVC oder AV1 beschreiben, wie das Video kodiert wird. Sie sind keine austauschbaren Schichten: Die Wahl eines Protokolls bestimmt nicht allein den Codec, die Auflösung oder die endgültige visuelle Qualität.

HLS, entwickelt von Apple, organisiert die Präsentation über Wiedergabelisten mit der Endung .m3u8. MPEG-DASH verwendet ein Manifest namens MPD, normalerweise mit der Endung .mpd, und ist eine internationale Spezifikation, veröffentlicht von MPEG/ISO. Beide können Video über HTTP liefern, es in Segmente unterteilen und mehrere Darstellungen anbieten, damit sich der Player an die Wiedergabebedingungen anpasst. Die geteilte Idee ist wichtiger als die Endung: Das Manifest beschreibt Optionen, und der Client fordert die Segmente an, die er benötigt.

Im Allgemeinen kann eine HLS-Masterliste auf Medienlisten für verschiedene Varianten verweisen; das DASH-MPD beschreibt die Präsentation durch Perioden, Adaptation Sets und Darstellungen. Eine Darstellung kann Eigenschaften wie Bitrate, Auflösung und Codec spezifizieren, während die Segmentinformationen ihre Positionierung und die sequentielle Wiedergabe ermöglichen. Das Manifest ist ein Index, nicht das vollständige Video: Die Überprüfung, ob es heruntergeladen wird, beweist nicht, dass alle nachfolgenden Segmente zugänglich oder dekodierbar sind.

Diese Unterschiede leiten die Implementierung, reichen aber nicht aus, um ein Protokoll universell besser zu erklären. Die tatsächliche Kompatibilität wird durch die Kombination aus Gerät, Betriebssystem, Browser, Player, Codec und Servicekonfiguration überprüft. Einige Plattformen bieten beide Formate an, um die Abdeckung zu erweitern oder Inhaltschutzanforderungen zu erfüllen; diese Entscheidung fügt Verpackungs- und Testarbeit hinzu, die im konkreten Kontext bewertet werden muss.

Bevor er abspielt, fordert der Client das Manifest an und erhält Informationen über die verfügbaren Darstellungen. Anschließend lädt er Segmente herunter, beobachtet, wie lange dies dauert, und berücksichtigt, wie viel Inhalt im Puffer gespeichert ist. Mit diesen Daten wählt er eine Qualität für die nächsten Anfragen. Die Änderung baut das gesamte Video normalerweise nicht neu auf: Die Auswahl wird auf zukünftige Segmente angewendet, sodass ein Netzwerkabfall zu einer niedrigeren Variante führen kann, bevor der bereits gespeicherte Inhalt aufgebraucht ist.

Der adaptive Bitrate-Algorithmus misst keine feste und perfekte Geschwindigkeit. Die Leistung kann zwischen Anfragen aufgrund von Stauung, drahtloser Signalstärke, Serverlast, Netzwerkpfad oder Aktivität anderer Geräte variieren. Außerdem ist die während eines Downloads beobachtete Rate nicht unbedingt die für das nächste Segment verfügbare. Der Player arbeitet mit Schätzungen und gleicht normalerweise Qualität mit Unterbrechungsrisiko ab; deshalb kann es dauern, bis eine hohe Auflösung erscheint, obwohl der Internetplan eine hohe Geschwindigkeit bewirbt.

Der Puffer fungiert als zeitlicher Puffer. Ein größerer Puffer kann kurze Schwankungen besser tolerieren, kann aber bei einer Live-Übertragung auch die Verzögerung gegenüber dem Ereignis erhöhen. Eine Reduzierung kann die Wiedergabe näher an das Live-Ereignis bringen, lässt aber weniger Zeit, um einen langsamen Download auszugleichen. Es gibt keine Einstellung, die gleichzeitig Qualität, Kontinuität und niedrige Latenz in allen Netzwerken maximiert: Die Serviceziele und das Verhalten des Players bestimmen das Gleichgewicht.

Die Bitrate drückt die Menge der pro Zeiteinheit übertragenen Daten aus. Bei gleicher Auflösung kann eine höhere Bitrate mehr Details bewahren, aber das Ergebnis hängt auch vom Codec, dem Bildinhalt, den Kodierungseinstellungen und dem Bildschirm ab. Die Auflösung allein bestimmt nicht die visuelle Qualität.

H.264, HEVC und AV1 sind Beispiele für Video-Codecs. Ihre Anwesenheit in einer Funktionsliste garantiert nicht, dass alle Geräte sie unterstützen oder dass der Service sie in jeder Wiedergabe verwendet. Kompatibilität und veröffentlichte Darstellungen beeinflussen die Auswahl. Die Auflösung allein ist unzureichend, um zwei Streams zu vergleichen, wenn Bitrate, Codec und Kodierungsqualität unbekannt sind.

Im Video beschreibt die Latenz die Verzögerung der Wiedergabe gegenüber der Übertragung. Konfigurationen mit niedriger Latenz können sie reduzieren; ihr Ergebnis hängt von der Service- und Playerkonfiguration ab. Die effektive Latenz variiert je nach Implementierung.

Opensignal bietet Konnektivitätstests und einen Video-Erfahrungstest. Letzterer erfasst Aspekte wie Ladezeit, Puffer und Videowiedergabe; die Ergebnisse helfen, das Verbindungserlebnis zu beschreiben, zertifizieren aber nicht die Qualität einer bestimmten Plattform oder eines bestimmten Inhalts. Eine isolierte Messung erklärt nicht das gesamte Erlebnis.

Um eine eigene Wiedergabe zu bewerten, sollte man zunächst den Kontext festhalten: Gerät und Betriebssystem, App oder Browser, Wi-Fi- oder Mobilverbindung, ungefähre Position, Uhrzeit, Titel und automatischer oder manueller Qualitätsmodus. Danach beobachtet man die Startzeit, Pausen, Schärfeänderungen und ob das Problem in mehr als einem Netzwerk oder auf einem Gerät auftritt. Das Wiederholen unter vergleichbaren Bedingungen hilft, ein anhaltendes Problem von einer punktuellen Variation zu trennen; es erlaubt aber nicht, die Ursache automatisch dem Internetanbieter zuzuordnen.

In einer Entwicklungsumgebung ermöglicht die Inspektion des Manifests und der Netzwerkanfragen, die angekündigten Darstellungen, die angeforderten Segmente, die Antwortcodes und die Downloadzeiten zu konsultieren. Bei HLS werden .m3u8-Listen und ihre Verweise überprüft; bei DASH das MPD und die zugehörigen Anfragen. Die Inspektion von Manifesten und Segmenten ermöglicht es zu untersuchen, wie der Inhalt angefordert und geliefert wird.

Eine einfache Überprüfung kann dieser Abfolge folgen:

1. Spielen Sie denselben Inhalt in zwei verschiedenen Netzwerken ab und notieren Sie, ob sich Start, Qualität oder Pausen ändern.
2. Vergleichen Sie die automatische Wiedergabe mit einer festen Qualität, wenn der Player dies zulässt.
3. Prüfen Sie, ob der Fehler nur ein Gerät, eine App oder auch den Browser betrifft.
4. Inspektionieren Sie in einer eigenen Implementierung das Manifest und die Segmentanfragen.

Notieren Sie, was Sie in jedem Test beobachten, um die Wiedergabebedingungen zu vergleichen.

Für Videoveröffentlicher muss das Design der Qualitätsleiter mehr als eine Verbindung und mehr als ein Gerät berücksichtigen. Das Veröffentlichen zusätzlicher Varianten kann die Anpassungsoptionen erweitern, erhöht aber die Arbeit an Kodierung, Speicherung und Distribution. Eine gut gestaltete Leiter bietet Qualitätsalternativen, nicht nur eine Version mit maximaler Auflösung.

Die Wahl zwischen HLS und DASH sollte vom Publikum und den zu bedienenden Plattformen ausgehen. Die Kompatibilität hängt vom Player und dem Gerät ab, daher ist es sinnvoll, die relevanten Kombinationen zu testen. Wenn der Service beide benötigt, kann das Teilen von Segmenten über kompatible Verpackungsformate Duplikate in einigen Architekturen reduzieren, beseitigt aber nicht die Gerätetests. Die Kompatibilitätsmatrix leitet die Entscheidung besser als eine abstrakte Präferenz für ein Protokoll.

Bei der Beobachtung einer Wiedergabe notieren Sie das Gerät, die App oder den Browser, die Verbindung und ob Pausen oder Schärfeänderungen auftreten. Wiederholen Sie den Test unter vergleichbaren Bedingungen, um zu prüfen, ob sich das Verhalten aufrechterhält. Die auf dem Bildschirm sichtbare Qualität kann sich während der Wiedergabe ändern.