Transloadit

Was ist adaptives Bitratenstreaming?

Adaptives Bitratenstreaming bietet mehrere codierte Varianten desselben Inhalts. Der Player wechselt während der Wiedergabe je nach Bandbreite, Pufferfüllstand und Geräteleistung zwischen ihnen.

Ein Quellvideo
Bitratenleiter, segmentiert und in einem Manifest aufgeführt
Player fragt eine Variante pro Segment an
Die Bitratenleiter wird codiert und verpackt, bevor ihre Segmente angefragt werden. Während der Wiedergabe wählt der Player für jede Segmentanfrage anhand seiner eigenen Messungen eine Variante. Der Server transkodiert daher nicht für jeden Zuschauer einzeln.

So funktioniert adaptives Bitratenstreaming

Adaptives Streaming teilt zeitlich aufeinander abgestimmte Varianten in adressierbare Mediensegmente und beschreibt sie in einem Manifest: einer Playlist bei HLS und einem XML-Dokument namens MPD bei MPEG-DASH. Der Player wählt eine Variante für kommende Segmentanfragen anhand von Signalen wie dem gemessenen Datendurchsatz und den gepufferten Medien. Der Wechsel ist somit eine clientseitige Entscheidung bei der Auslieferung und keine serverseitige Transkodierung während des Streams. Beide Protokolle können fragmentierte MP4-Segmente übertragen. Dadurch kann CMAF-Packaging denselben Satz von Mediendateien unter beiden Manifesten ausliefern.

Wichtige Fakten

  1. Die Voraussetzungen für saubere Wechsel werden beim Encoding und Packaging geschaffen. RFC 8216 verlangt, dass übereinstimmende Inhalte in jeder HLS-Variante übereinstimmende Zeitstempel tragen. Apples Spezifikation zur Medienaufbereitung verlangt, dass jedes Videosegment mit einem IDR-Bild beginnt, und empfiehlt Segmentgrenzen an denselben Zeitpunkten über alle Varianten hinweg. Das DASH-IF-Interoperabilitätsprofil beginnt ebenfalls jedes Segment mit einem IDR-ähnlichen Einstiegspunkt und richtet die Segmentgrenzen innerhalb eines Adaptation Sets aufeinander aus.
  2. Der Wechselalgorithmus gehört zum Player, nicht zum Protokoll: RFC 8216 schließt ihn aus seinem Geltungsbereich aus. Derselbe Stream kann sich daher in verschiedenen Playern unterschiedlich verhalten. In hls.js verlangen die Standardeinstellungen beispielsweise beim Wechsel auf eine höhere Qualitätsstufe (abrBandWidthUpFactor) eine größere Bandbreitenreserve als beim Halten oder Senken der Stufe (abrBandWidthFactor). Die Qualität wird nur dann auf die Größe des Videoelements begrenzt oder als Reaktion auf verworfene Bilder angepasst, wenn capLevelToPlayerSize beziehungsweise capLevelOnFPSDrop aktiviert ist. Beide sind standardmäßig deaktiviert.
  3. Die Startqualität hängt von der Playlist-Reihenfolge und den Player-Einstellungen ab. Apples Spezifikation behandelt die erste Variante, die innerhalb jeder Gruppe von Varianten mit kompatiblem Audio in der Multivarianten-Playlist aufgeführt ist, als Standard dieser Gruppe. Wenn startLevel in hls.js nicht gesetzt ist, wird die Wiedergabe nicht auf die erste aufgeführte Qualitätsstufe festgelegt, obwohl Teile der API-Dokumentation dies behaupten: Der Quellcode von v1.6.13 wählt die Startstufe anhand einer Bandbreitenschätzung, die durch die Bitrate der ersten aufgeführten Variante angehoben werden kann. Die Playlist-Reihenfolge beeinflusst den Start also, ohne ihn festzulegen. Bei startLevel mit dem Wert -1 lädt hls.js standardmäßig ein Fragment der niedrigsten Qualitätsstufe herunter, um vor der Auswahl die Bandbreite zu schätzen.
  4. Die Abstände zwischen den Stufen einer Bitratenleiter hängen vom Inhalt ab, und die angegebenen Bitraten müssen korrekt sein. Apple stellt seine Bitratentabellen als erste Zielwerte vor, die anhand Ihrer eigenen Inhalte bewertet werden sollen. Die titelbezogene Untersuchung von Netflix ergab, dass eine feste Bitratenleiter mehr Bits verbraucht, als einfache Titel benötigen, während bei komplexen Titeln Artefakte verbleiben. Das erklärte Ziel ist ein Abstand von etwa einem gerade wahrnehmbaren Qualitätsunterschied zwischen benachbarten Stufen, damit Wechsel mit möglichst wenigen Varianten fließend bleiben. Für HLS warnt RFC 8216, dass ein ungenauer Wert für BANDWIDTH zu Wiedergabepausen führen oder die Wiedergabe einer Variante verhindern kann.

Wann adaptives Bitratenstreaming relevant ist

Stellen Sie eine Bitratenleiter bereit, wenn wechselnde Netzwerkbedingungen sonst zu Wiedergabepausen führen würden. Ungünstige Abstände zwischen den Varianten können Speicher verschwenden oder sichtbare Qualitätseinbrüche erzwingen, ohne die unterbrechungsfreie Wiedergabe wesentlich zu verbessern.

So hilft Transloadit bei adaptivem Bitratenstreaming

Der Robot /video/adaptive von Transloadit verpackt codierte Varianten als HLS-, MPEG-DASH- oder CMAF-Ausgabe und erzeugt die Playlist- und Manifestdateien. Wenn technique auf cmaf gesetzt ist, verweisen die DASH- und HLS-Manifeste auf dieselben fMP4-Segmente. Die Varianten stammen normalerweise aus Steps mit /video/encode, die die Voreinstellungen unter hls/ oder dash/ verwenden. Die Ausgaben dieser Steps werden für einen einzigen Step mit /video/adaptive gebündelt.

Transloadit bereitet die Dateien vor. Die Auswahl einer Variante während der Wiedergabe übernimmt der von Ihnen verwendete Player. Die Robot-Dokumentation beschreibt außerdem, wie Sie in jedem Step mit /video/encode übereinstimmende Keyframes erzwingen, damit die Segmente über alle Varianten hinweg ausgerichtet sind. Sie erläutert auch, welche CORS-Header Sie auf Ihrem Dateiserver konfigurieren müssen (erforderlich, wenn der Player die Dateien von einem anderen Ursprung lädt) und wie Sie die Metadateneigenschaft relative_path beim Speichern der Segmente verwenden müssen, damit die Playlists aufgelöst werden können.

Entdecken Sie Transloadits Streaming-Möglichkeiten

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren