Koma í veg fyrir að ABR straumurinn hoppi fram og til baka á milli bitahraða

Hvernig á að hanna umkóðunarstigann þannig að ABR reikniritin verði ekki vitlaus

Ef þú hefur einhvern tíma skoðað HLS spilun í raunveruleikanum, hefur þú séð þetta: straumurinn heldur áfram að hoppa á milli tveggja gæðaútgáfa. Upp, niður, upp, niður. Áhorfandinn sér stöðuga breytingu á gæðum, stundum á nokkurra sekúndna fresti. Þetta er verra en að vera á lægri gæðaútgáfu allan tímann. Að minnsta kosti finnst stöðugur 720p straumur vera viljandi. Straumur sem sveiflast á milli 720p og 1080p á 10 sekúndna fresti virðist bilaður.

Undirliggjandi orsökin er næstum alltaf sú sama: umkóðunarstiginn hefur gæðaútgáfur sem eru of nálægt hvor annarri í bitahraða, eða gæðabilið á milli þrepa réttlætir ekki bandbreiddarhækkunina. ABR reikniritið á biðlarahliðinni getur ekki ákveðið sig, vegna þess að munurinn á „ég hef efni á þessu" og „ég hef ekki efni á þessu" er hárfínn.

Við skulum tala um hvernig á að laga þetta almennilega.

Bitar-á-díl athugunin

Áður en nokkuð annað, þarftu að skilja hvað bitar-á-díl (BPP) segir þér um stigann þinn. Þetta er einfaldasta mæligildið til að meta hvort tiltekinn bitahraði sé raunverulega skynsamlegur fyrir tiltekna upplausn.

Formúlan er einföld:

BPP = bitrate / (width × height × framerate)

Til dæmis, 1920×1080 straumur við 4500 kbps og 30 fps:

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

Hvers vegna skiptir þetta máli? Vegna þess að BPP segir þér þjöppunarþéttleikann á hverju þrepi. Ef tvö aðliggjandi þrep í stiganum þínum hafa mjög svipuð BPP gildi, mun áhorfandinn ekki sjá marktækan gæðamun — en ABR reikniritið mun samt reyna að skipta á milli þeirra. Þannig endar þú með ping-pong hegðun.

Vel hannaður stigi ætti að hafa BPP feril sem hallar niður eftir því sem upplausnin eykst. Þetta endurspeglar raunverulegan eiginleika myndbandsþjappa: þeir eru skilvirkari við hærri upplausnir. Þú þarft færri bita á hvern díl við 1080p til að ná sömu skynjaðri gæðum og við 480p. Ef BPP er flatt eða ósamkvæmt á milli þrepa, þá er eitthvað að.

„Regla 0,70" er hagnýt viðmiðun hér. Hugmyndin er sú að þegar þú tvöfaldar dílafjöldann (til dæmis þegar farið er úr 720p í 1080p), ættirðu að nota um það bil 0,70× BPP lægri upplausnarinnar. Þetta er þumalputtaregla, ekki lögmál, en hún gefur þér fljótlega leið til að greina frávik. Ef þú teiknar BPP gildi stigans þíns og eitt þrep stendur upp úr miðað við nágranna sína — of hátt eða of lágt — þá mun það þrep valda vandamálum.

Niðurstaðan: ekki bara velja bitahraða sem líta út eins og fallegar jafnar tölur. Reiknaðu BPP fyrir hvert þrep og passaðu að ferillinn sé skynsamlegur. Ef tvö aðliggjandi þrep eru innan 15-20% af hvoru öðru í BPP, mun áhorfandinn ekki greina þau í sundur, en ABR reikniritið mun eyða tíma í að skipta á milli þeirra.

Bil á milli bitahraða: 1,5× þumalputtareglan

Enginn algildur staðall er til, en algeng verkfræðileg viðmiðun er að viðhalda að minnsta kosti 1,5× hlutfalli á milli aðliggjandi bitahraðaþrepa. Sumar útfærslur ýta þessu upp í 2×.

Hvers vegna? Vegna þess að ABR reiknirit nota bandbreiddarmat til að ákveða hvaða gæðaútgáfu á að velja. Matið hefur öryggisbil — það er aldrei nákvæmt. Ef tvær gæðaútgáfur eru við 2,5 Mbps og 3,0 Mbps, getur BWE auðveldlega sveiflast fyrir ofan og neðan 3,0 Mbps á vægt breytilegri tengingu, sem veldur stöðugum skiptingum. Ef hoppið er þess í stað úr 2,0 Mbps í 4,0 Mbps, þarf reikniritið miklu meiri bandbreiddarbreytingu til að kveikja á skiptingu. Niðurstaðan: stöðugri spilun.

Hér er áþreifanlegt dæmi. Segjum að þú hafir hreinan fjögurra þrepa stiga:

Upplausn	Bitahraði	BPP (30fps)	Hlutfall miðað við fyrra
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×

Við fyrstu sýn lítur þetta skynsamlega út — fjórar upplausnir, hækkandi bitahraðar. En skoðaðu 540p→720p hoppið: 2000 kbps í 2800 kbps. Þetta er aðeins 1,4× hlutfall. Á hvaða tengingu sem er sem svífur um 2,5–3 Mbps (sem er flestar farsímatengingar), mun BWE stöðugt fara yfir þetta þröskuldsgildi. Upp, niður, upp, niður. Áhorfandinn sér upplausnartoglu á nokkurra hluta fresti.

Og hér er hitt vandamálið: BPP lækkar í raun úr 0,129 við 540p í 0,101 við 720p. Þannig fær áhorfandinn fleiri díla en minni gögn á hvern díl. Eftir efninu gæti 720p gæðaútgáfan ekki litið marktækt betur út en 540p — þú hefur bætt við upplausn en tapað þjöppunarrými. ABR reikniritið er að skipta fyrir ekki neitt.

Betri útgáfa af þessum stiga myndi hækka 720p bitahraðann og lækka 540p:

Upplausn	Bitahraði	BPP (30fps)	Hlutfall miðað við fyrra
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 540p→720p hoppið hreint 2× hlutfall. BWE þarf að tvöfaldast áður en spilarinn íhugar yfirhöfuð að skipta upp á við. Og BPP hækkar í raun úr 0,096 í 0,109, sem þýðir að 720p þrepið skilar bæði fleiri dílum og betri þjöppunargæðum — áhorfandinn sér raunverulega framför. 720p→1080p hoppið við 1,93× er jafn traust, og BPP lækkar aðeins lítillega í 0,093, sem er væntanlegur skilvirkniávinningur við hærri upplausnir.

Skoðaðu hraða fyrir hraða: prófanir á einni gæðaútgáfu í einu

Hér er eitthvað sem ég sé sjaldan lið gera, en er mikilvægt: spilaðu hverja gæðaútgáfu fyrir sig og horfðu á allt efnið.

Þetta hljómar augljóst, en flestir prófa aðeins ABR sem heildstæðan fjölútgáfu straum. Þeir einangra aldrei eina gæðaútgáfu og spila hana frá byrjun til enda. Þegar þú gerir þetta, uppgötvar þú vandamál sem ABR hegðun felur:

Gæðaútgáfa sem biðminnar jafnvel við sinn eigin tilgreinda bitahraða (vegna þess að tilgreindur BANDWIDTH í spilunarlistanum er of lágur miðað við raunverulegan hámarkshraða)
Gæðaútgáfa þar sem kóðarinn átti í erfiðleikum og framleiddi sýnilegar gervimyndir í tilteknum senum
Gæðaútgáfa þar sem rammatíðnin lækkar eða hakkar vegna þess að upplausn/bitahraða samsetningin er of krefjandi fyrir afkóðara marktækisins

Til að prófa þetta geturðu þvingað spilun á einni gæðaútgáfu á nokkra vegu:

Með hls.js kynningarsíðunni: Hladdu fjölútgáfu straumnum þínum, veldu síðan í gæðavalsglugganum og festu hvert stig handvirkt eitt í einu. hls.js kynningin á hlsjs.video-dev.org/demo/ sýnir öll gæðastig og leyfir þér að hnekkja ABR. Spilaðu hvert stig í að minnsta kosti nokkrar mínútur af dæmigerðu efni. Fylgstu með fallnum römmum í „Buffer & Statistics" flipanum.

Með AVPlayer á Apple kerfum: Notaðu preferredPeakBitRate og preferredMaximumResolution á AVPlayerItem til að festa spilun við eina gæðaútgáfu. Eða jafnvel einfaldara: búðu til prófunarspilunarskrá sem inniheldur aðeins eina útgáfu.

Með ffprobe eða mediainfo: Áður en þú spilar eitthvað, skoðaðu raunverulegan bitahraðatölur hverrar gæðaútgáfu. BANDWIDTH gildið í aðalspilunarskránni þinni verður að taka tillit til hámarksins, ekki bara meðaltalsins. Ef VBR umkóðun þín hefur toppa 40% yfir meðaltali, þarf tilgreint BANDWIDTH að endurspegla það.

Ef ein gæðaútgáfa getur ekki spilast vel við sinn eigin tilgreinda bitahraða, mun hún algerlega valda vandamálum í ABR ham. ABR reikniritið velur þá gæðaútgáfu í þeirri trú að það hafi næga bandbreidd, rekst síðan á VBR topp, stöðvast, lækkar aftur, jafnar sig, velur þá gæðaútgáfu aftur — ping-pong.

Hlutlengd: klukkan í ABR skiptingum þínum

Það er annar þáttur sem fólk hefur tilhneigingu til að horfa framhjá: hlutlengd stýrir beint hversu oft ABR reikniritið fær tækifæri til að taka ákvörðun. Hvert hlutamörk eru mögulegur skiptipunktur. Þannig að ef þú notar 2 sekúndna hluta, getur spilarinn endurmetið og skipt allt að 30 sinnum á mínútu. Með 6 sekúndna hlutum lækkar þetta í 10 sinnum á mínútu. Með 10 sekúndna hlutum, aðeins 6.

Þetta skiptir miklu máli þegar stiginn þinn hefur nú þegar þétt bitahraðabil. Stuttir hlutar ásamt nálægum bitahraðaþrepum er versta samsetningin — þú gefur ABR reikniritinu hámarkstækifæri til að gera jaðarskiptingar sem áhorfandinn þarf ekki að sjá.

Aftur á móti virka lengri hlutar sem náttúruleg deyfing á sveiflum. Jafnvel þótt bandbreiddarmatið sveiflist, þarf spilarinn að skuldbinda sig við núverandi gæðaútgáfu meðan á hlutanum stendur sem hann sótti. Þegar næsti ákvörðunarpunktur kemur, gæti BWE hafa náð jafnvægi.

HLS staðallinn kveður ekki á um tiltekna lengd, en höfundaleiðbeiningar Apple mæla með markmiði um 6 sekúndur. Í framkvæmd:

2 sekúndna hlutar eru skynsamlegir fyrir lágleynd beint streymi þar sem hröð ræsing og fljót aðlögun eru mikilvæg. En þú þarft vel dreifðan stiga til að forðast stöðuga toglu.
6 sekúndna hlutar eru góður sjálfgefinn valkostur fyrir VOD og venjulegt beint streymi. Þeir gefa ABR reikniritinu nægan tíma til að byggja upp áreiðanlegt bandbreiddarmat á milli ákvarðana.
10 sekúndna hlutar eru mjög stöðugir en seinir að aðlagast. Ef bandbreidd lækkar snögglega er spilarinn fastur við að hlaða niður hábitahraða hluta sem hann nær kannski ekki að ljúka í tæka tíð.

Það er líka fínleiki varðandi VBR umkóðun: bitahraðabreytileiki innan hluta eykst með hlutlengd. 10 sekúndna hlutur af senuskiptum — þar sem farið er úr kyrrstæðu myndefni í aðgernaatriði — getur haft miklar bitahraðasveiflur innbyrðis. Ef tilgreint BANDWIDTH í spilunarskránni samsvarar heildarmeðaltali en ekki toppa hvers hluta, kemst ABR reikniritið á óvart. Styttri hlutar hafa yfirleitt samkvæmari bitahraða á hvern hluta, sem gerir BWE nákvæmara.

Niðurstaðan: ef þú sérð sveiflur og bil stigans lítur vel út, skoðaðu hlutlengdina. Að fara úr 4 sekúndum í 6 sekúndur gæti verið allt sem þú þarft til að róa hlutina niður.

Notaðu Network Link Conditioner til að herma eftir raunverulegum aðstæðum

Að prófa ABR á stöðugri 100 Mbps ljósleiðaratengingu er gagnslaust. Þú þarft að herma eftir raunverulegum aðstæðum, og Network Link Conditioner frá Apple er besta tólið til þess á macOS.

Þú færð það frá Additional Tools for Xcode pakkanum frá Apple: í Xcode, farðu í Xcode > Open Developer Tool > More Developer Tools, sem fer með þig á niðurhalssíðu Apple þróenda. Leitaðu að „Additional Tools for Xcode", halaðu niður DMG skránni fyrir þína útgáfu af Xcode, opnaðu hana, og í Hardware möppunni finnurðu Network Link Conditioner.prefPane. Tvísmelltu til að setja upp. Það birtist síðan sem gluggi í System Settings (eða System Preferences á eldri macOS). Það leyfir þér að skilgreina bandbreiddarsniðmát með sérstakri afköstum, leynd, pakkatapmælingu og DNS töf.

Búðu til sérsniðin snið sem skipta máli:

Miðlungs 4G: 8 Mbps niður / 2 Mbps upp, 80ms RTT, 1% pakkatap
Slæmt WiFi: 3 Mbps niður / 1 Mbps upp, 150ms RTT, 3% pakkatap
Umbreytingarástand: Byrjaðu á 15 Mbps, skiptu handvirkt yfir í 2 Mbps miðja spilun

Sú síðasta er úrslitaprófið. Ef stiginn þinn er vel hannaður, ætti spilarinn að falla snurðulaust niður á lægri gæðaútgáfu innan nokkurra sekúndna og vera þar. Ef hann byrjar að sveifla á milli tveggja gæðaútgáfa, eru þrepin þín of nálægt á bandbreiddarmörkum.

Á iOS tækjum er Network Link Conditioner aðgengilegt í gegnum þróunarstillingarnar (virkjaðu það í Settings > Developer eftir að hafa tengt tækið við Xcode).

Markmiðið með þessum prófunum er ekki bara „biðminnar það?" — heldur „settist straumurinn á gæðaútgáfu og helst þar?" Góð ABR upplifun er þar sem skiptingar eru sjaldgæfar og eindregnar. Áhorfandinn sér gæðabreytingu einu sinni og svo verður stöðugleiki.

Notaðu AVMetrics frá Apple til að fylgjast með skiptingum í framleiðslu

Frá og með iOS 18 kynnti Apple AVMetrics API í AVFoundation. Þetta er byltingarkennt til að fylgjast með ABR hegðun í raunumhverfi.

Lykilatburðategund í okkar tilgangi er gæðaútgáfuskiptiatburðurinn. Í hvert sinn sem AVPlayer skiptir á milli HLS útgáfa, færðu mæligildi sem segir þér hvaðan var skipt, hvert var skipt, og upplýsingar um gæðaútgáfuna. Þú færð líka stöðvunaratburði þegar spilarinn endurhleður biðminni, og samantektaratburð í lok lotunnar með heildarlykiltölum.

Hér er Swift mynstrið:

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ð þú ert að leita að í greiningargögnum þínum:

Skiptitíðni: Ef meðallota hefur fleiri en 3-4 skiptingar á mínútu, þá er vandamál í stiganum þínum. Heilbrigðir straumar skipta kannski einu sinni eða tvisvar á lotu, yfirleitt við ræsingu.
Sveiflumynstur: Tvær gæðaútgáfur sem víxlast stöðugt — klassískt teikn um að þrep séu of nálægt.
Stöðvun tengd uppskiptingu: Ef stöðvun á sér stað strax eftir skiptingu í hærri gæðaútgáfu, þá eru BANDWIDTH tilgreiningar þínar í spilunarskránni of lágar.

Fyrir WWDC 2025 stækkaði Apple AVMetrics til að innihalda upplýsingar um gæðaútgáfu í gæðaútgáfuskiptiatburðum, sem gerir það auðveldara að sjá nákvæmlega hvaða hljóð-/myndbands-/textabrautir voru virkar meðan á skiptingunni stóð.

Ef þú ert ekki á Apple kerfum, er hægt að safna sambærilegum gögnum úr hls.js með LEVEL_SWITCHED og FRAG_BUFFERED atburðum. Sömu meginreglur gilda.

Gerðu tilraunir með hls.js: stilltu ABR hegðunina

hls.js kynningarsíðan (hlsjs.video-dev.org/demo/) er besta ókeypis tólið til að gera tilraunir með ABR skiptihegðun á vefnum. Hladdu HLS straumnum þínum og notaðu „Real-time metrics" og „Buffer & Statistics" spjöldin til að fylgjast með því sem gerist.

Helstu hls.js stillingarhnútar til að gera tilraunir með:

abrEwmaFastVoD og abrEwmaSlowVoD: Þessir stjórna EWMA (veldisvegnu hlaupandi meðaltali) fyrir bandbreiddarmat. Lægri gildi láta spilarann bregðast hraðar við bandbreiddarbreytingum (árásargjarnari skipti). Hærri gildi gera hann íhaldssamari (hægari að skipta, stöðugri). Ef þú sérð of miklar skiptingar, prófaðu að hækka þessi gildi.
abrBandWidthFactor (sjálfgefið: 0.95) og abrBandWidthUpFactor (sjálfgefið: 0.7): Þetta eru öryggisbil. Spilarinn velur gæðaútgáfu þar sem bitahraði er undir estimatedBandwidth × factor. Uppskiptistuðullinn er viljandi lægri — spilarinn er varfærnari varðandi að skipta upp en niður. Ef stiginn þinn hefur þétt bil, gætirðu viljað lækka abrBandWidthUpFactor í 0,6 til að minnka sveiflur.
abrMaxWithRealBitrate (sjálfgefið: false): Þegar virkt notar ABR stýringin raunverulegan mældan bitahraða sóttra hluta frekar en tilgreint BANDWIDTH úr spilunarskránni. Þetta er sérstaklega gagnlegt ef tilgreindir bitahraðar þínir eru ónákvæmir.

En hér er málið: ef þú þarft að stilla þessar breytur verulega til að fá stöðuga spilun, þá er stiginn þinn líklega rangur. Þessir hnútar eru fínstilling. Umkóðunarstiginn sjálfur er grunnurinn. Vel dreifður stigi virkar vel með sjálfgefnum ABR stillingum á hverjum spilara.

Hagnýtar ráðleggingar

Ef ég þyrfti að draga þetta saman í gátlista:

Reiknaðu BPP fyrir hvert þrep í stiganum þínum. Gakktu úr skugga um að það lækki eftir því sem upplausnin eykst. Fjarlægðu eða aðlagaðu hvert þrep þar sem BPP er innan 15% frá nágranna sínum.
Haltu að minnsta kosti 1,5× bitahraðahlutfalli á milli aðliggjandi þrepa. Kjóstu 2× þegar mögulegt er, sérstaklega í neðri helmingi stigans þar sem bandbreiddarsveiflur hafa mest áhrif.
Prófaðu hverja gæðaútgáfu í einangrun. Þvingaðu spilun á einni útgáfu og horfðu á dæmigerð efni frá byrjun til enda. Ef hún getur ekki spilast snurðulaust ein, mun hún ekki spilast snurðulaust í ABR.
Notaðu Network Link Conditioner til að herma eftir bandbreiddarfalli. Straumurinn ætti að setjast á gæðaútgáfu hratt og vera kyrr.
Skoðaðu hlutlengdina. Ef þú ert á 2–4 sekúndum og sérð sveiflur, prófaðu 6 sekúndur. Lengri hlutar draga náttúrulega úr skiptitíðni með því að gefa BWE meiri tíma til að ná jafnvægi á milli ákvarðana.
Mældu spilarann þinn. Notaðu AVMetrics á Apple, hls.js atburði á vefnum. Fylgstu með skiptitíðni á hverja lotu. Ef lotur hafa að meðaltali fleiri en handfylli af skiptingum utan ræsingarfasa, rannsakaðu málið.
Treystið ekki eingöngu á tilgreint BANDWIDTH. Notaðu abrMaxWithRealBitrate í hls.js eða staðfestu með ffprobe að VBR toppar þínir fari ekki yfir tilgreint gildi.
Færri þrep er oft betra. 5 þrepa stigi með vel dreifðum gæðaútgáfum mun standa sig betur en 10 þrepa stigi þar sem helmingur þrepanna er of nálægt hvort öðru. Áhorfandinn þarf ekki 12 gæðastig. Hann þarf 4 eða 5 sem líta öll marktækt ólík út og spilast áreiðanlega.

Allur tilgangurinn með ABR er að það eigi að vera ósýnilegt. Áhorfandinn ætti ekki að taka eftir því að það sé að virka. Ef hann gerir það, þá er eitthvað að — og níu af hverjum tíu sinnum er það stiginn.

Heimildir: