So verhindern Sie, dass Ihr ABR-Stream zwischen Bitraten hin und her springt

Wie man eine Transcoding-Leiter entwirft, die ABR-Algorithmen nicht verrückt macht

Wenn Sie schon einmal HLS-Wiedergabe in der Praxis beobachtet haben, kennen Sie das: Der Stream springt ständig zwischen zwei Renditions hin und her. Rauf, runter, rauf, runter. Der Zuschauer sieht einen permanenten Qualitätswechsel, manchmal alle paar Sekunden. Das ist schlimmer, als die ganze Zeit auf einer niedrigeren Rendition zu bleiben. Zumindest fühlt sich ein stabiler 720p-Stream gewollt an. Ein Stream, der alle 10 Sekunden zwischen 720p und 1080p wechselt, wirkt kaputt.

Die Ursache ist fast immer dieselbe: Die Encoding-Leiter hat Renditions, die in der Bitrate zu nahe beieinander liegen, oder der Qualitätsunterschied zwischen den Stufen rechtfertigt den Bandbreitensprung nicht. Der ABR-Algorithmus auf der Client-Seite kann sich nicht entscheiden, weil der Unterschied zwischen „das kann ich mir leisten" und „das kann ich mir nicht leisten" hauchdünn ist.

Schauen wir uns an, wie man das richtig löst.

Der Bits-per-Pixel-Plausibilitätscheck

Bevor Sie irgendetwas anderes tun, müssen Sie verstehen, was Bits-per-Pixel (BPP) Ihnen über Ihre Leiter verrät. Es ist die einfachste Metrik, um zu bewerten, ob eine bestimmte Bitrate für eine bestimmte Auflösung tatsächlich sinnvoll ist.

Die Formel ist unkompliziert:

BPP = bitrate / (width × height × framerate)

Zum Beispiel ein 1920×1080-Stream mit 4500 kbps und 30 fps:

BPP = 4,500,000 / (1920 × 1080 × 30) = 0.072

Warum ist das wichtig? Weil BPP Ihnen die Kompressionsdichte auf jeder Stufe zeigt. Wenn zwei benachbarte Stufen in Ihrer Leiter sehr ähnliche BPP-Werte haben, wird der Zuschauer keinen bedeutsamen Qualitätsunterschied sehen — aber der ABR-Algorithmus wird trotzdem versuchen, zwischen ihnen zu wechseln. So entsteht das Ping-Pong-Verhalten.

Eine gut gestaltete Leiter sollte eine BPP-Kurve haben, die mit steigender Auflösung abfällt. Dies spiegelt eine reale Eigenschaft von Video-Codecs wider: Sie sind bei höheren Auflösungen effizienter. Man braucht bei 1080p weniger Bits pro Pixel, um die gleiche wahrgenommene Qualität wie bei 480p zu erreichen. Wenn Ihr BPP über die Stufen hinweg flach oder inkonsistent ist, stimmt etwas nicht.

Die „0,70-Regel" ist hier eine praktische Referenz. Die Idee ist, dass man bei einer Verdopplung der Pixelzahl (zum Beispiel beim Wechsel von 720p zu 1080p) ungefähr den 0,70-fachen BPP-Wert der niedrigeren Auflösung verwenden sollte. Es ist eine Faustregel, kein Gesetz, aber sie bietet eine schnelle Möglichkeit, Ausreißer zu erkennen. Wenn Sie die BPP-Werte Ihrer Leiter aufzeichnen und eine Stufe wie ein Fremdkörper heraussticht — zu hoch oder zu niedrig im Vergleich zu ihren Nachbarn — wird diese Stufe Probleme verursachen.

Das Fazit: Wählen Sie nicht einfach Bitraten, die wie schöne runde Zahlen aussehen. Berechnen Sie den BPP für jede Stufe und stellen Sie sicher, dass die Kurve Sinn ergibt. Wenn zwei benachbarte Stufen innerhalb von 15–20 % voneinander im BPP liegen, wird der Zuschauer sie nicht unterscheiden können, aber die ABR-Heuristik wird Zeit damit verschwenden, zwischen ihnen zu wechseln.

Bitraten-Abstände: die 1,5×-Faustregel

Es gibt keinen universellen Standard, aber eine gängige technische Richtlinie besagt, dass man mindestens ein 1,5-faches Verhältnis zwischen benachbarten Bitratenstufen einhalten sollte. Manche Implementierungen gehen bis zu 2×.

Warum? Weil ABR-Algorithmen eine Bandbreitenschätzung verwenden, um zu entscheiden, welche Rendition sie wählen. Die Schätzung hat ein Konfidenzintervall — sie ist nie exakt. Wenn zwei Renditions bei 2,5 Mbps und 3,0 Mbps liegen, kann die BWE bei einer leicht schwankenden Verbindung leicht über und unter 3,0 Mbps pendeln, was ständiges Umschalten verursacht. Wenn der Sprung stattdessen von 2,0 Mbps auf 4,0 Mbps geht, braucht der Algorithmus eine deutlich größere Bandbreitenänderung, um einen Wechsel auszulösen. Das Ergebnis: stabilere Wiedergabe.

Hier ein konkretes Beispiel. Nehmen wir an, Sie haben eine saubere Vier-Stufen-Leiter:

Auflösung	Bitrate	BPP (30fps)	Verhältnis zur vorherigen
480×270	400 kbps	0.103	—
960×540	2000 kbps	0.129	5.0×
1280×720	2800 kbps	0.101	1.4×
1920×1080	4500 kbps	0.072	1.6×

Auf den ersten Blick sieht es vernünftig aus — vier Auflösungen, steigende Bitraten. Aber schauen Sie sich den Sprung von 540p zu 720p an: 2000 kbps auf 2800 kbps. Das ist nur ein 1,4-faches Verhältnis. Bei jeder Verbindung, die um 2,5–3 Mbps schwankt (was den meisten mobilen Verbindungen entspricht), wird die BWE diese Schwelle ständig überschreiten. Rauf, runter, rauf, runter. Der Zuschauer sieht alle paar Segmente einen Auflösungswechsel.

Und hier ist das andere Problem: Der BPP-Wert sinkt tatsächlich von 0,129 bei 540p auf 0,101 bei 720p. Der Zuschauer bekommt also mehr Pixel, aber weniger Daten pro Pixel. Je nach Inhalt sieht die 720p-Rendition möglicherweise nicht merklich besser aus als 540p — man hat Auflösung hinzugefügt, aber Kompressionsspielraum verloren. Der ABR-Algorithmus wechselt umsonst.

Eine bessere Version dieser Leiter würde die 720p-Bitrate erhöhen und die 540p-Bitrate senken:

Auflösung	Bitrate	BPP (30fps)	Verhältnis zur vorherigen
480×270	400 kbps	0.103	—
960×540	1500 kbps	0.096	3.75×
1280×720	3000 kbps	0.109	2.0×
1920×1080	5800 kbps	0.093	1.93×

Jetzt beträgt der Sprung von 540p zu 720p ein sauberes 2-faches Verhältnis. Die BWE muss sich verdoppeln, bevor der Player überhaupt einen Aufwärtswechsel in Betracht zieht. Und der BPP steigt tatsächlich von 0,096 auf 0,109, was bedeutet, dass die 720p-Stufe sowohl mehr Pixel als auch bessere Kompressionsqualität liefert — der Zuschauer sieht eine echte Verbesserung. Der Sprung von 720p zu 1080p mit 1,93× ist ebenso solide, und der BPP sinkt nur leicht auf 0,093, was dem erwarteten Effizienzgewinn bei höheren Auflösungen entspricht.

Stufe für Stufe prüfen: Einzelne-Rendition-Wiedergabetests

Hier ist etwas, das ich selten bei Teams beobachte, aber es ist entscheidend: Spielen Sie jede Rendition einzeln ab und schauen Sie sich das Ganze an.

Es klingt offensichtlich, aber die meisten Leute testen ABR nur als kompletten Multi-Variant-Stream. Sie isolieren nie eine einzelne Rendition und spielen sie von Anfang bis Ende ab. Wenn Sie das tun, entdecken Sie Probleme, die das ABR-Verhalten verbirgt:

Eine Rendition, die selbst bei ihrer eigenen deklarierten Bitrate puffert (weil der deklarierte BANDWIDTH-Wert in der Playlist im Vergleich zur tatsächlichen Spitzen-Bitrate zu niedrig ist)
Eine Rendition, bei der der Encoder Schwierigkeiten hatte und bei bestimmten Szenen sichtbare Artefakte erzeugt hat
Eine Rendition, bei der die Bildrate einbricht oder stottert, weil die Kombination aus Auflösung und Bitrate für den Decoder des Zielgeräts zu anspruchsvoll ist

Um dies zu testen, können Sie die Einzelrendition-Wiedergabe auf verschiedene Weisen erzwingen:

Mit der hls.js-Demoseite: Laden Sie Ihren Multi-Variant-Stream, wählen Sie dann im Qualitätsauswahl-Dropdown manuell jede Stufe einzeln aus. Die hls.js-Demo unter hlsjs.video-dev.org/demo/ zeigt alle Qualitätsstufen und ermöglicht es Ihnen, ABR zu überschreiben. Spielen Sie jede Stufe mindestens ein paar Minuten mit repräsentativem Inhalt ab. Achten Sie auf verworfene Frames im Tab „Buffer & Statistics".

Mit AVPlayer auf Apple-Plattformen: Verwenden Sie preferredPeakBitRate und preferredMaximumResolution auf AVPlayerItem, um die Wiedergabe auf eine einzelne Rendition zu beschränken. Oder noch einfacher: Erstellen Sie eine Test-Playlist, die nur eine Variante enthält.

Mit ffprobe oder mediainfo: Bevor Sie überhaupt etwas abspielen, überprüfen Sie die tatsächlichen Bitraten-Statistiken jeder Rendition. Der BANDWIDTH-Wert in Ihrer Master-Playlist muss die Spitzenwerte berücksichtigen, nicht nur den Durchschnitt. Wenn Ihre VBR-Kodierung Spitzen hat, die 40 % über dem Durchschnitt liegen, muss Ihr deklarierter BANDWIDTH-Wert das widerspiegeln.

Wenn eine einzelne Rendition nicht flüssig bei ihrer eigenen deklarierten Bitrate abgespielt werden kann, wird sie im ABR-Modus definitiv Probleme verursachen. Der ABR-Algorithmus wählt diese Rendition in der Annahme aus, genügend Bandbreite zu haben, trifft dann auf eine VBR-Spitze, stockt, fällt zurück, erholt sich, wählt diese Rendition erneut — Ping-Pong.

Segmentdauer: Ihr ABR-Umschalttakt

Es gibt einen weiteren Faktor, den viele übersehen: Die Segmentdauer steuert direkt, wie oft der ABR-Algorithmus eine Entscheidung treffen kann. Jede Segmentgrenze ist ein potenzieller Umschaltpunkt. Wenn Sie also 2-Sekunden-Segmente verwenden, kann der Player bis zu 30 Mal pro Minute neu bewerten und umschalten. Bei 6-Sekunden-Segmenten sinkt das auf 10 Mal pro Minute. Bei 10-Sekunden-Segmenten nur noch 6 Mal.

Das ist besonders wichtig, wenn Ihre Leiter bereits enge Bitratenabstände hat. Kurze Segmente kombiniert mit eng beieinander liegenden Bitratenstufen sind die schlechteste Kombination — Sie geben dem ABR-Algorithmus maximale Gelegenheiten, marginale Wechsel vorzunehmen, die der Zuschauer nicht sehen muss.

Umgekehrt wirken längere Segmente als natürlicher Dämpfer gegen Oszillation. Selbst wenn die Bandbreitenschätzung schwankt, muss der Player bei seiner aktuellen Rendition bleiben, solange das gerade heruntergeladene Segment dauert. Bis der nächste Entscheidungspunkt kommt, hat sich die BWE möglicherweise stabilisiert.

Die HLS-Spezifikation schreibt keine bestimmte Dauer vor, aber Apples Authoring-Richtlinien empfehlen ein Ziel von 6 Sekunden. In der Praxis:

2-Sekunden-Segmente sind sinnvoll für Low-Latency-Live, wo schneller Start und schnelle Anpassung entscheidend sind. Aber Sie brauchen eine gut gestaffelte Leiter, um ständiges Hin- und Herschalten zu vermeiden.
6-Sekunden-Segmente sind ein guter Standard für VOD und normales Live-Streaming. Sie geben dem ABR-Algorithmus genug Zeit, um zwischen den Entscheidungen eine zuverlässige Bandbreitenschätzung aufzubauen.
10-Sekunden-Segmente sind sehr stabil, aber reagieren langsam auf Änderungen. Wenn die Bandbreite stark abfällt, hängt der Player beim Download eines hochbitratigen Segments fest, das er möglicherweise nicht rechtzeitig fertig laden kann.

Es gibt auch eine Feinheit bei der VBR-Kodierung: Die Bitratenvarianz innerhalb eines Segments nimmt mit der Segmentdauer zu. Ein 10-Sekunden-Segment eines Szenenwechsels — von einer statischen Einstellung zu einer Actionsequenz — kann intern massive Bitratenschwankungen aufweisen. Wenn der deklarierte BANDWIDTH-Wert in der Playlist zum Gesamtdurchschnitt passt, aber nicht zu den Spitzenwerten einzelner Segmente, wird der ABR-Algorithmus überrascht. Kürzere Segmente haben tendenziell konsistentere Bitraten pro Segment, was die BWE genauer macht.

Das Fazit: Wenn Sie Oszillation beobachten und die Abstände Ihrer Leiter in Ordnung aussehen, überprüfen Sie Ihre Segmentdauer. Ein Wechsel von 4 auf 6 Sekunden könnte alles sein, was nötig ist, um die Situation zu beruhigen.

Verwenden Sie Network Link Conditioner, um reale Bedingungen zu simulieren

ABR-Tests über eine stabile 100-Mbps-Glasfaserverbindung sind nutzlos. Sie müssen reale Bedingungen simulieren, und Apples Network Link Conditioner ist dafür das beste Werkzeug unter macOS.

Sie erhalten ihn über Apples Additional Tools for Xcode-Paket: Gehen Sie in Xcode zu Xcode > Open Developer Tool > More Developer Tools, was Sie zur Apple-Entwickler-Downloadseite bringt. Suchen Sie nach „Additional Tools for Xcode", laden Sie das DMG für Ihre Xcode-Version herunter, öffnen Sie es, und im Ordner Hardware finden Sie Network Link Conditioner.prefPane. Doppelklicken Sie zum Installieren. Er erscheint dann als Panel in den Systemeinstellungen. Damit können Sie Bandbreitenprofile mit bestimmtem Durchsatz, Latenz, Paketverlustrate und DNS-Verzögerung definieren.

Erstellen Sie relevante benutzerdefinierte Profile:

Mittelmäßiges 4G: 8 Mbps Download / 2 Mbps Upload, 80 ms RTT, 1 % Paketverlust
Schlechtes WLAN: 3 Mbps Download / 1 Mbps Upload, 150 ms RTT, 3 % Paketverlust
Übergang: Starten Sie mit 15 Mbps, wechseln Sie während der Wiedergabe manuell auf 2 Mbps

Der letzte Test ist der entscheidende. Wenn Ihre Leiter gut gestaltet ist, sollte der Player innerhalb weniger Sekunden reibungslos auf eine niedrigere Rendition wechseln und dort bleiben. Wenn er beginnt, zwischen zwei Renditions zu oszillieren, liegen Ihre Stufen an der Bandbreitengrenze zu eng beieinander.

Auf iOS-Geräten ist der Network Link Conditioner über die Entwicklereinstellungen verfügbar (aktivieren Sie ihn unter Einstellungen > Entwickler, nachdem Sie das Gerät mit Xcode verbunden haben).

Das Ziel dieser Tests ist nicht nur „puffert es?" — sondern „pendelt sich der Stream auf eine Rendition ein und bleibt dort?" Ein gutes ABR-Erlebnis ist eines, bei dem Wechsel selten und entschieden sind. Der Zuschauer sieht den Qualitätswechsel einmal, und dann stabilisiert sich alles.

Verwenden Sie Apples AVMetrics, um Umschaltungen in der Produktion zu überwachen

Ab iOS 18 hat Apple die AVMetrics-API in AVFoundation eingeführt. Dies ist ein Wendepunkt für die Überwachung des ABR-Verhaltens im Feld.

Der wichtigste Ereignistyp für unseren Zweck ist das Variant-Switch-Event. Jedes Mal, wenn AVPlayer zwischen HLS-Varianten wechselt, erhalten Sie ein Metrik-Ereignis, das Ihnen sagt, wovon gewechselt wurde, wohin gewechselt wurde und die Details der Medien-Rendition. Sie erhalten auch Stall-Events, wenn der Player neu puffert, und ein Summary-Event am Ende der Sitzung mit den wichtigsten KPIs.

Hier ist das Swift-Muster:

let playerItem: AVPlayerItem = // your configured item

let switchMetrics = playerItem.metrics(
    forType: AVMetricPlayerItemVariantSwitchEvent.self
)
let stallMetrics = playerItem.metrics(
    forType: AVMetricPlayerItemStallEvent.self
)

for await (event, _) in switchMetrics.chronologicalMerge(with: stallMetrics) {
    switch event {
    case let switchEvent as AVMetricPlayerItemVariantSwitchEvent:
        // Log: from variant, to variant, timestamp
        await analytics.logSwitch(switchEvent)
    case let stallEvent as AVMetricPlayerItemStallEvent:
        // Log: stall duration, variant at time of stall
        await analytics.logStall(stallEvent)
    default:
        break
    }
}

Worauf Sie in Ihren Analysen achten sollten:

Umschalthäufigkeit: Wenn die durchschnittliche Sitzung mehr als 3–4 Wechsel pro Minute hat, hat Ihre Leiter Probleme. Gesunde Streams wechseln vielleicht ein- oder zweimal pro Sitzung, typischerweise beim Start.
Oszillationsmuster: Zwei Renditions, die ständig alternieren — klassisches Zeichen für Stufen, die zu nah beieinander liegen.
Stockungen korreliert mit Aufwärtswechsel: Wenn Stockungen direkt nach dem Wechsel zu einer höheren Rendition auftreten, sind Ihre BANDWIDTH-Deklarationen in der Playlist zu niedrig.

Für die WWDC 2025 hat Apple AVMetrics um Informationen zur Medien-Rendition in Variant-Switch-Events erweitert, wodurch es einfacher wird, genau zu sehen, welche Audio-/Video-/Untertitelspuren während des Wechsels aktiv waren.

Wenn Sie nicht auf Apple-Plattformen arbeiten, können ähnliche Daten von hls.js über die Events LEVEL_SWITCHED und FRAG_BUFFERED gesammelt werden. Die gleichen Prinzipien gelten.

Experimentieren Sie mit hls.js: ABR-Verhalten feintunen

Die hls.js-Demoseite (hlsjs.video-dev.org/demo/) ist das beste kostenlose Tool zum Experimentieren mit ABR-Umschaltverhalten im Web. Laden Sie Ihren HLS-Stream und verwenden Sie die Panels „Real-time metrics" und „Buffer & Statistics", um zu beobachten, was passiert.

Wichtige hls.js-Konfigurationsparameter zum Experimentieren:

abrEwmaFastVoD und abrEwmaSlowVoD: Diese steuern den exponentiell gewichteten gleitenden Durchschnitt (EWMA) für die Bandbreitenschätzung. Niedrigere Werte lassen den Player schneller auf Bandbreitenänderungen reagieren (aggressiveres Umschalten). Höhere Werte machen ihn konservativer (langsameres Umschalten, stabiler). Wenn Sie zu viel Umschaltung beobachten, versuchen Sie, diese Werte zu erhöhen.
abrBandWidthFactor (Standard: 0,95) und abrBandWidthUpFactor (Standard: 0,7): Dies sind Sicherheitsmargen. Der Player wählt eine Rendition, deren Bitrate unter estimatedBandwidth × factor liegt. Der Aufwärtswechsel-Faktor ist bewusst niedriger — der Player ist konservativer beim Hochschalten als beim Herunterschalten. Wenn Ihre Leiter enge Abstände hat, können Sie abrBandWidthUpFactor auf 0,6 senken, um Oszillation zu reduzieren.
abrMaxWithRealBitrate (Standard: false): Wenn aktiviert, verwendet der ABR-Controller die tatsächlich gemessene Bitrate der heruntergeladenen Segmente anstelle des deklarierten BANDWIDTH-Werts aus der Playlist. Dies ist besonders nützlich, wenn Ihre deklarierten Bitraten ungenau sind.

Aber hier ist der Punkt: Wenn Sie diese Parameter stark anpassen müssen, um eine stabile Wiedergabe zu erreichen, ist Ihre Leiter wahrscheinlich falsch aufgebaut. Diese Einstellungen sind Feintuning. Die Encoding-Leiter selbst ist das Fundament. Eine gut gestaffelte Leiter funktioniert gut mit den Standard-ABR-Einstellungen auf jedem Player.

Praktische Empfehlungen

Wenn ich das in einer Checkliste zusammenfassen müsste:

Berechnen Sie den BPP für jede Stufe Ihrer Leiter. Stellen Sie sicher, dass er mit steigender Auflösung abnimmt. Entfernen oder korrigieren Sie jede Stufe, bei der der BPP innerhalb von 15 % ihres Nachbarn liegt.
Halten Sie mindestens ein 1,5-faches Bitratenverhältnis zwischen benachbarten Stufen ein. Bevorzugen Sie 2× wenn möglich, besonders in der unteren Hälfte der Leiter, wo Bandbreitenschwankungen den größten Einfluss haben.
Testen Sie jede Rendition isoliert. Erzwingen Sie Einzelvarianten-Wiedergabe und schauen Sie sich repräsentativen Inhalt von Anfang bis Ende an. Wenn es allein nicht flüssig läuft, wird es im ABR-Modus auch nicht flüssig laufen.
Verwenden Sie Network Link Conditioner, um Bandbreiteneinbrüche zu simulieren. Der Stream sollte sich schnell auf eine Rendition einpendeln und dort bleiben.
Überprüfen Sie Ihre Segmentdauer. Wenn Sie bei 2–4 Sekunden sind und Oszillation beobachten, versuchen Sie 6 Sekunden. Längere Segmente reduzieren die Umschalthäufigkeit natürlich, indem sie der BWE mehr Zeit zur Stabilisierung zwischen Entscheidungen geben.
Instrumentieren Sie Ihren Player. Verwenden Sie AVMetrics auf Apple, hls.js-Events im Web. Verfolgen Sie die Umschalthäufigkeit pro Sitzung. Wenn Sitzungen im Durchschnitt mehr als eine Handvoll Wechsel außerhalb der Startphase aufweisen, untersuchen Sie die Ursache.
Vertrauen Sie nicht allein dem deklarierten BANDWIDTH. Verwenden Sie abrMaxWithRealBitrate in hls.js oder überprüfen Sie mit ffprobe, dass Ihre VBR-Spitzen den deklarierten Wert nicht überschreiten.
Weniger Stufen sind oft besser. Eine 5-Stufen-Leiter mit gut verteilten Renditions wird eine 10-Stufen-Leiter übertreffen, bei der die Hälfte der Stufen zu eng beieinander liegt. Der Zuschauer braucht keine 12 Qualitätsstufen. Er braucht 4 oder 5, die jeweils merklich anders aussehen und zuverlässig abgespielt werden.

Der ganze Sinn von ABR ist, dass es unsichtbar sein sollte. Der Zuschauer sollte nicht bemerken, dass es arbeitet. Wenn doch, stimmt etwas nicht — und in neun von zehn Fällen liegt es an der Leiter.

Referenzen: