Stopp ABR-Strømmen Fra å Hoppe Mellom Bitrater

Hvordan designe en transkodingsstige som ikke gjør ABR-algoritmer gale

Hvis du har brukt tid på å se på HLS-avspilling i praksis, har du sett det: strømmen fortsetter å hoppe mellom to renditions. Opp, ned, opp, ned. Seeren ser et konstant skifte i kvalitet, noen ganger hvert par sekunder. Det er verre enn å bli på en lavere rendition hele tiden. I det minste føles en stabil 720p-strøm tilsiktet. En strøm som svinger mellom 720p og 1080p hvert 10. sekund føles ødelagt.

Grunnårsaken er nesten alltid den samme: kodingsstigen har renditions som ligger for nærme i bitrate, eller kvalitetsgapet mellom trinnene rettferdiggjør ikke båndbreddespranget. ABR-algoritmen på klientsiden kan ikke bestemme seg, fordi forskjellen mellom "dette har jeg råd til" og "dette har jeg ikke råd til" er hårfin.

La oss snakke om hvordan man fikser dette skikkelig.

Bits-per-pixel fornuftsjekk

Før noe annet må du forstå hva bits-per-pixel (BPP) forteller deg om stigen din. Det er den enkleste metrikken for å vurdere om en gitt bitrate faktisk gir mening for en gitt oppløsning.

Formelen er grei:

BPP = bitrate / (width × height × framerate)

For eksempel en 1920×1080-strøm ved 4500 kbps og 30 fps:

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

Hvorfor er dette viktig? Fordi BPP forteller deg kompresjonstettheten på hvert trinn. Hvis to nabotrin i stigen din har svært like BPP-verdier, vil ikke seeren se en meningsfull kvalitetsforskjell — men ABR-algoritmen vil likevel prøve å bytte mellom dem. Det er slik du ender opp med ping-pong-oppførsel.

En godt designet stige bør ha en BPP-kurve som heller nedover etterhvert som oppløsningen øker. Dette gjenspeiler en reell egenskap ved video-codecs: de er mer effektive ved høyere oppløsninger. Du trenger færre bits per piksel ved 1080p for å oppnå den samme opplevde kvaliteten som ved 480p. Hvis BPP-en din er flat eller inkonsekvent på tvers av trinn, er noe galt.

"Regelen om 0,70" er en praktisk referanse her. Idéen er at når du dobler antall piksler (for eksempel fra 720p til 1080p), bør du bruke omtrent 0,70× BPP-en til den lavere oppløsningen. Det er en tommelfingerregel, ikke en lov, men den gir deg en rask måte å oppdage avvik på. Hvis du plotter BPP-verdiene til stigen din og ett trinn stikker ut — for høyt eller for lavt sammenlignet med naboene — vil det trinnet skape problemer.

Konklusjonen: ikke bare velg bitrater som ser ut som fine runde tall. Beregn BPP for hvert trinn og sørg for at kurven gir mening. Hvis to nabotrin er innenfor 15-20% av hverandre i BPP, vil ikke seeren skille dem, men ABR-heuristikken vil kaste bort tid på å bytte mellom dem.

Avstand mellom bitrater: 1,5×-tommelfingerregelen

Det finnes ingen universell standard, men en vanlig teknisk retningslinje er å opprettholde minst et 1,5× forhold mellom nabobitratetrinn. Noen implementeringer drar dette til 2×.

Hvorfor? Fordi ABR-algoritmer bruker båndbreddeestimering for å avgjøre hvilken rendition som skal velges. Estimeringen har et konfidensintervall — den er aldri nøyaktig. Hvis to renditions er på 2,5 Mbps og 3,0 Mbps, kan BWE enkelt svinge over og under 3,0 Mbps på en mildt variabel forbindelse, noe som forårsaker konstante bytter. Hvis spranget i stedet er fra 2,0 Mbps til 4,0 Mbps, trenger algoritmen en mye mer betydelig båndbreddeendring for å utløse et bytte. Resultatet: mer stabil avspilling.

Her er et konkret eksempel. La oss si at du har en ren firetrinns stige:

Oppløsning	Bitrate	BPP (30fps)	Forhold til forrige
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×

Ved første øyekast ser det rimelig ut — fire oppløsninger, stigende bitrater. Men se på spranget fra 540p til 720p: 2000 kbps til 2800 kbps. Det er bare et 1,4× forhold. På enhver forbindelse som svever rundt 2,5–3 Mbps (som er de fleste mobilforbindelser), vil BWE konstant krysse den terskelen. Opp, ned, opp, ned. Seeren ser et oppløsningsbytte hvert par segmenter.

Og her er det andre problemet: BPP faller faktisk fra 0,129 ved 540p til 0,101 ved 720p. Så seeren får flere piksler, men færre data per piksel. Avhengig av innholdet ser kanskje ikke 720p-rendisjonen merkbart bedre ut enn 540p — du har lagt til oppløsning, men mistet kompresjonsmarginen. ABR-algoritmen bytter for ingenting.

En bedre versjon av denne stigen ville økt 720p-bitraten og justert ned 540p:

Oppløsning	Bitrate	BPP (30fps)	Forhold til forrige
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×

Nå er spranget fra 540p til 720p et rent 2× forhold. BWE må dobles før spilleren i det hele tatt vurderer å bytte opp. Og BPP øker faktisk fra 0,096 til 0,109, noe som betyr at 720p-trinnet leverer både flere piksler og bedre komprimeringskvalitet — seeren ser en reell forbedring. Spranget fra 720p til 1080p ved 1,93× er like solid, og BPP faller bare marginalt til 0,093, som er den forventede effektivitetsgevinsten ved høyere oppløsninger.

Sjekk rendition for rendition: test av enkeltstående avspilling

Her er noe jeg sjelden ser team gjøre, men det er avgjørende: spill av hver rendition individuelt og se hele greia.

Det høres opplagt ut, men de fleste tester bare ABR som en komplett multivariant strøm. De isolerer aldri en enkelt rendition og spiller den fra start til slutt. Når du gjør dette, oppdager du problemer som ABR-oppførsel skjuler:

En rendition som buffrer selv ved sin egen deklarerte bitrate (fordi den deklarerte BANDWIDTH i spillelisten er for lav sammenlignet med den faktiske toppbitraten)
En rendition der koderen slet og produserte synlige artefakter på visse scener
En rendition der bildefrekvensen synker eller hakker fordi kombinasjonen oppløsning/bitrate er for krevende for målenhetens dekoder

For å teste dette kan du tvinge enkeltstående rendition-avspilling på flere måter:

Med hls.js demoside: Last inn din multivariant strøm, velg deretter manuelt hvert nivå ett om gangen i kvalitetsvelgerens nedtrekksmeny. hls.js-demoen på hlsjs.video-dev.org/demo/ eksponerer alle kvalitetsnivåer og lar deg overstyre ABR. Spill hvert nivå i minst noen minutter med representativt innhold. Se etter tapte rammer i fanen "Buffer & Statistics".

Med AVPlayer på Apple-plattformer: Bruk preferredPeakBitRate og preferredMaximumResolution på AVPlayerItem for å begrense avspillingen til en enkelt rendition. Eller enda enklere: lag en testspilleliste som bare inkluderer én variant.

Med ffprobe eller mediainfo: Før du i det hele tatt spiller noe, sjekk de faktiske bitratestatistikkene for hver rendition. BANDWIDTH-verdien i master-spillelisten din må ta høyde for toppen, ikke bare gjennomsnittet. Hvis VBR-kodingen din har topper 40% over gjennomsnittet, må den deklarerte BANDWIDTH gjenspeile det.

Hvis en enkelt rendition ikke kan spilles jevnt ved sin egen deklarerte bitrate, vil den absolutt forårsake problemer i ABR-modus. ABR-algoritmen velger den rendisjonen i den tro at den har nok båndbredde, treffer så en VBR-topp, stopper, faller tilbake, gjenoppretter, velger den rendisjonen igjen — ping-pong.

Segmentvarighet: din ABR-bytteklokke

Det er en annen faktor som folk har en tendens til å overse: segmentvarighet styrer direkte hvor ofte ABR-algoritmen får ta en avgjørelse. Hver segmentgrense er et potensielt byttepunkt. Så hvis du bruker 2-sekunders segmenter, kan spilleren revurdere og bytte opptil 30 ganger i minuttet. Med 6-sekunders segmenter faller det til 10 ganger i minuttet. Med 10-sekunders segmenter bare 6.

Dette betyr mye når stigen din allerede har tett bitrateavstand. Korte segmenter kombinert med nære bitratetrinn er den verste kombinasjonen — du gir ABR-algoritmen maksimale muligheter til å gjøre marginale bytter som seeren ikke trenger å se.

Omvendt fungerer lengre segmenter som en naturlig demper på oscillasjon. Selv om båndbreddeestimeringen svinger, må spilleren holde seg til sin nåværende rendition for varigheten av segmentet den nettopp hentet. Når neste beslutningspunkt kommer, kan BWE ha stabilisert seg.

HLS-spesifikasjonen pålegger ikke en bestemt varighet, men Apples retningslinjer for authoring anbefaler et mål på 6 sekunder. I praksis:

2-sekunders segmenter gir mening for live med lav latens der rask start og rask tilpasning er avgjørende. Men du trenger en godt spredt stige for å unngå konstant veksling.
6-sekunders segmenter er en god standard for VOD og standard live. De gir ABR-algoritmen nok tid til å bygge et pålitelig båndbreddeestimat mellom avgjørelser.
10-sekunders segmenter er svært stabile, men trege til å tilpasse seg. Hvis båndbredden faller brått, sitter spilleren fast med å laste ned et segment med høy bitrate som den kanskje ikke rekker å fullføre i tide.

Det er også en subtilitet med VBR-koding: bitratevariansen innenfor et segment øker med segmentvarigheten. Et 10-sekunders segment av en sceneovergang — fra et statisk bilde til en actionsekvens — kan ha massive bitratefluktuasjoner internt. Hvis den deklarerte BANDWIDTH i spillelisten samsvarer med det overordnede gjennomsnittet, men ikke toppene per segment, blir ABR-algoritmen overrasket. Kortere segmenter har en tendens til å ha mer konsistente bitrater per segment, noe som gjør BWE mer nøyaktig.

Bunnlinjen: hvis du ser oscillasjon og stigeavstanden din ser fin ut, sjekk segmentvarigheten. Å gå fra 4 sekunder til 6 sekunder kan være alt som trengs for å roe ting ned.

Bruk Network Link Conditioner for å simulere virkelige forhold

Å teste ABR på en stabil 100 Mbps fiberforbindelse er nytteløst. Du må simulere virkelige forhold, og Apples Network Link Conditioner er det beste verktøyet for dette på macOS.

Du får det fra Apples Additional Tools for Xcode-pakke: i Xcode, gå til Xcode > Open Developer Tool > More Developer Tools, som tar deg til Apples utviklernedlastningsside. Søk etter "Additional Tools for Xcode", last ned DMG-en for din Xcode-versjon, åpne den, og i Hardware-mappen finner du Network Link Conditioner.prefPane. Dobbeltklikk for å installere. Den vises deretter som et panel i Systeminnstillinger (eller Systemvalg på eldre macOS). Den lar deg definere båndbreddeprofiler med spesifikk gjennomstrømning, latens, pakketapsrate og DNS-forsinkelse.

Lag egendefinerte profiler som betyr noe:

Middelmådig 4G: 8 Mbps ned / 2 Mbps opp, 80ms RTT, 1% pakketap
Dårlig WiFi: 3 Mbps ned / 1 Mbps opp, 150ms RTT, 3% pakketap
Overgangstest: Start ved 15 Mbps, bytt manuelt til 2 Mbps midt i avspillingen

Den siste er den avgjørende testen. Hvis stigen din er godt designet, bør spilleren gli smidig ned til en lavere rendition innen få sekunder og bli der. Hvis den begynner å oscillere mellom to renditions, er trinnene dine for nære båndbreddegrensen.

På iOS-enheter er Network Link Conditioner tilgjengelig gjennom Utviklerinnstillinger (aktiver det i Innstillinger > Utvikler etter å ha koblet enheten til Xcode).

Målet med disse testene er ikke bare "buffer den?" — det er "stabiliserer strømmen seg på en rendition og blir der?" En god ABR-opplevelse er en der bytter er sjeldne og bestemte. Seeren ser kvalitetsendringen én gang, og deretter stabiliseres det.

Bruk Apples AVMetrics for å overvåke bytter i produksjon

Fra og med iOS 18 introduserte Apple AVMetrics API i AVFoundation. Dette er en gamechanger for overvåking av ABR-oppførsel i felten.

Den viktigste hendelsestypen for vårt formål er variantbyttehendelsen. Hver gang AVPlayer bytter mellom HLS-varianter, får du en metrikkhendelse som forteller deg hva den byttet fra, hva den byttet til, og detaljene om medierendisjonen. Du får også stallhendelser når spilleren rebuffrer, og en oppsummeringshendelse ved slutten av økten med overordnede KPI-er.

Her er Swift-mønsteret:

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
    }
}

Hva du bør se etter i analysene dine:

Byttefrekvens: Hvis den gjennomsnittlige økten har mer enn 3-4 bytter i minuttet, har stigen din problemer. Sunne strømmer bytter kanskje en eller to ganger i en økt, vanligvis ved oppstart.
Oscillasjonsmønstre: To renditions som fortsetter å veksle — klassisk tegn på trinn som er for nære.
Stall korrelert med oppbytte: Hvis stall skjer rett etter bytte til en høyere rendition, er BANDWIDTH-deklarasjonene dine i spillelisten for lave.

Til WWDC 2025 utvidet Apple AVMetrics til å inkludere medierendisjonsinformasjon i variantbyttehendelser, noe som gjør det lettere å se nøyaktig hvilke lyd-/video-/undertekstspor som var aktive under byttet.

Hvis du ikke er på Apple-plattformer, kan lignende data samles inn fra hls.js via LEVEL_SWITCHED- og FRAG_BUFFERED-hendelsene. De samme prinsippene gjelder.

Eksperimenter med hls.js: juster ABR-oppførselen

hls.js demosiden (hlsjs.video-dev.org/demo/) er det beste gratisverktøyet for å eksperimentere med ABR-bytteoppførsel på nettet. Last inn din HLS-strøm og bruk panelene "Real-time metrics" og "Buffer & Statistics" for å observere hva som skjer.

Viktige hls.js konfigurasjonsparametre å eksperimentere med:

abrEwmaFastVoD og abrEwmaSlowVoD: Disse styrer det eksponentielt vektede glidende gjennomsnittet (EWMA) for båndbreddeestimering. Lavere verdier gjør at spilleren reagerer raskere på båndbreddeendringer (mer aggressiv bytting). Høyere verdier gjør den mer konservativ (tregere til å bytte, mer stabil). Hvis du ser for mange bytter, prøv å øke disse.
abrBandWidthFactor (standard: 0.95) og abrBandWidthUpFactor (standard: 0.7): Disse er sikkerhetsmarginer. Spilleren velger en rendition med bitrate under estimatedBandwidth × factor. Oppbyttefaktoren er bevisst lavere — spilleren er mer konservativ med å bytte opp enn ned. Hvis stigen din har tett avstand, kan du ønske å senke abrBandWidthUpFactor til 0,6 for å redusere oscillasjon.
abrMaxWithRealBitrate (standard: false): Når aktivert bruker ABR-kontrolleren den faktisk målte bitraten for hentede segmenter i stedet for den deklarerte BANDWIDTH fra spillelisten. Dette er spesielt nyttig hvis dine deklarerte bitrater er unøyaktige.

Men her er poenget: hvis du trenger å justere disse parametrene kraftig for å oppnå stabil avspilling, er stigen din sannsynligvis feil. Disse knottene er for finjustering. Kodingsstigen selv er fundamentet. En godt spredt stige fungerer bra med standard ABR-innstillinger på enhver spiller.

Praktiske anbefalinger

Hvis jeg skulle oppsummere dette i en sjekkliste:

Beregn BPP for hvert trinn i stigen din. Sørg for at den synker etterhvert som oppløsningen øker. Fjern eller juster ethvert trinn der BPP er innenfor 15% av naboen.
Oppretthold minst 1,5× bitrateforhold mellom nabotrinn. Foretrekk 2× når det er mulig, spesielt i den nedre halvdelen av stigen der båndbreddesvingninger har størst innvirkning.
Test hver rendition isolert. Tving enkeltvariant avspilling og se representativt innhold fra start til slutt. Hvis den ikke kan spilles jevnt alene, vil den ikke spilles jevnt i ABR.
Bruk Network Link Conditioner for å simulere båndbreddefall. Strømmen bør stabilisere seg på en rendition raskt og bli der.
Sjekk segmentvarigheten din. Hvis du er på 2–4 sekunder og ser oscillasjon, prøv 6 sekunder. Lengre segmenter reduserer naturlig byttefrekvensen ved å gi BWE mer tid til å stabilisere seg mellom avgjørelser.
Instrumenter spilleren din. Bruk AVMetrics på Apple, hls.js-hendelser på nettet. Spor byttefrekvens per økt. Hvis økter i gjennomsnitt har mer enn en håndfull bytter utenfor oppstartsfasen, undersøk.
Stol ikke på deklarert BANDWIDTH alene. Bruk abrMaxWithRealBitrate i hls.js eller verifiser med ffprobe at VBR-toppene dine ikke overskrider den deklarerte verdien.
Færre trinn er ofte bedre. En 5-trinns stige med godt spredte renditions vil utkonkurrere en 10-trinns stige der halvparten av trinnene er for nære. Seeren trenger ikke 12 kvalitetsnivåer. De trenger 4 eller 5 som hver ser merkbart forskjellige ut og spilles pålitelig.

Hele poenget med ABR er at det skal være usynlig. Seeren skal ikke merke at det fungerer. Hvis de gjør det, er noe galt — og ni av ti ganger er det stigen.

Referanser: