- Dalinamės, kaip „Instagram iOS“ programoje įgalinome „Dolby Vision“ ir aplinkos žiūrėjimo aplinką (amve), kad pagerintume vaizdo įrašų žiūrėjimo patirtį.
- „iPhone“ sukurtuose HDR vaizdo įrašuose yra unikalių „Dolby Vision“ ir „amve“ metaduomenų, kurių mums reikėjo, kad palaikytume visą
- „Instagram“, skirta „iOS“, dabar yra pirmoji „Meta“ programa, palaikanti „Dolby Vision“ vaizdo įrašus, o ateityje bus teikiama daugiau palaikymo visose „Meta“ programose.
Kiekviena „iPhone“ sukurta HDR vaizdo koduotė apima du papildomus metaduomenų elementus, kurie padeda užtikrinti, kad vaizdas atitiktų skirtingus ekranus ir žiūrėjimo sąlygas:
- Aplinkos žiūrėjimo aplinka (amve), kuri pateikia nominalios aplinkos žiūrėjimo aplinkos charakteristikas, skirtas susijusiam vaizdo turiniui rodyti. Ši informacija leidžia galutiniam įrenginiui reguliuoti vaizdo įrašo atvaizdavimą, jei tikrosios aplinkos žiūrėjimo sąlygos skiriasi nuo tų, kurioms jis buvo užkoduotas.
- Dolby Vision, kuris pagerina spalvas, ryškumą ir kontrastą, kad vaizdo įrašas geriau atitiktų ekrano galimybes.
Nors „Instagram“ ir „Facebook“ iOS programos palaiko didelio dinaminio diapazono (HDR) vaizdo įrašus Nuo 2022 m. pradinis HDR diegimas nepalaiko „Dolby Vision“ ar „amve“ pristatymo ir atkūrimo. Mūsų išvestinės koduotės buvo padarytos su FFmpegkuriai tradiciškai trūko Dolby Vision ir amve palaikymo. Kadangi mūsų įrankiai atmetė šiuos metaduomenis, tai reiškė, kad nuotraukos visiškai neatspindi būdo, kaip jas turėjo būti peržiūrimos – tai buvo ypač pastebima esant žemam ekrano ryškumui.
Dabar, išgirdę mūsų iOS programėles naudojančių žmonių atsiliepimus, bendradarbiavome su savo partneriais, siekdami išsaugoti „iOS“ sukurtus „amve“ ir „Dolby Vision“ metaduomenis nuo galo iki galo ir žymiai pagerinome HDR žiūrėjimo patirtį „iOS“ įrenginiuose.
Kaip meta apdoroja vaizdo įrašą
Pirmiausia gali būti naudinga pateikti šiek tiek informacijos apie „Meta“ vaizdo įrašo gyvavimo ciklas.
Dauguma vaizdo įrašų, įkeltų per mūsų programas, pereina tris pagrindinius etapus:
1. Kliento apdorojimas
Kliento apdorojimo etape kūrėjo įrenginys suvienodina kompoziciją į vieną vaizdo failą, kurio dydis tinkamas įkelti. HDR vaizdo įrašams, kuriuos sukuria iOS įrenginiai, tai reiškia kodavimą naudojant HEVC naudojant pagrindinį 10 profilį. Tai etapas, kuriame amve ir Dolby Vision metaduomenys sukuriami, pridedami prie užkoduoto bitų srauto ir įkeliami į Meta serverius.
2. Serverio apdorojimas
Serverio apdorojimo etape mūsų perkodavimo sistema generuoja skirtingas vaizdo įrašo versijas skirtingiems vartotojams. Kadangi atkūrimas vyksta įvairiuose įrenginiuose su skirtingomis galimybėmis, turime sukurti vaizdo įrašą tokiu formatu, kuris būtų optimalus kiekvienam įrenginiui. Kalbant apie HDR įkėlimus, tai reiškia, kad reikia sukurti SDR versiją įrenginiams, kurie nepalaiko HDR, VP9 versiją, kad patenkintų daugumą grotuvų, ir (populiariausiems vaizdo įrašams) AV1 versija aukščiausios kokybės ir mažiausio failo dydžio.
Kiekviena iš šių versijų sukuriama skirtingu pralaidumo greičiu (iš esmės – failo dydžiu), siekiant užtikrinti, kad vartotojai, esant skirtingoms tinklo sąlygoms, galėtų leisti vaizdo įrašą nelaukdami, kol bus baigtas didelis atsisiuntimas (kompromisas yra tas, kad mažesnės spartos kokybė yra žemesnė). Visos mūsų išvestinės koduotės yra sukurtos naudojant FFmpeg, kuri istoriškai nepalaikė amve ir Dolby Vision. Tai metaduomenų atsisakymo etapas.
3. Vartojimas
Vartojimo etape žiūrinčiojo įrenginys pasirenka versiją, kuri bus atkuriama sklandžiai (be kioskų), iššifruoja ją po kadro ir kiekvieną kadrą nupiešia ekrane. „IOS“ kontekste visas HDR atkūrimas atliekamas naudojant „Apple“ AVSampleBufferDisplayLayer (AVSBDL). Tai klasė, kuri naudoja amve ir Dolby Vision metaduomenis kartu su kiekvienu dekoduotu kadru.
Kaip pridėjome amve palaikymą
Kai 2022 m. pirmą kartą išvykome palaikyti amve, pastebėjome kai ką įdomaus. Kadangi dirbame pagal atsietą žemesnio lygio komponentų architektūrą, o ne įprastą aukšto lygio AVPlayer sąranką, galėjome patikrinti nepažeistą vaizdo įrašo kodavimą ir pažvelgti į amve metaduomenis tarp dekoderio ir AVSBDL. Pastebėjome, kad kiekvienas vaizdo įrašo kadras turėjo lygiai tokius pačius metaduomenis. Tai leido mums greitai pataisyti ir įrašyti šias reikšmes tiesiai į grotuvą.
Tai nebuvo puiki padėtis. Nors vertė atrodė statiška, niekas to neįtvirtino. Galbūt naujoji „iPhone“ ar „iOS“ versija sukurtų kitokias reikšmes, tada naudotume netinkamas. amve taip pat nėra „Android“ koncepcija, o tai reikštų, kad „iPhone“ peržiūrint „Android“ sukurtą HDR kodavimą vaizdas būtų techniškai netikslus.
2024 m. dirbome su bendruomene, siekdami gauti amve paramą FFmpeg. Taip pat įrengėme kai kuriuos kirtimus, kurie parodė, kad mūsų dvejų metų tvirtinimas, kad vertybės niekada nesikeičia, tebegalioja. Bet jei jie kada nors tai padarys, mes būsime tam tinkamai pasiruošę.
„Dolby Vision“ įjungimas
„Dolby Vision“ nebuvo taip paprasta priimti.
1 iššūkis: išlikusi specifikacija buvo skirta metaduomenų pernešimui HEVC bitų sraute. Mes nepristatome HEVC.
„iPhone“ sukurtame HDR naudojamas Dolby Vision 8.4 profilis, kur 8 nurodo profilį, kuriame naudojamas HEVC (vaizdo įrašo kodekas), o .4 reiškia kryžminį suderinamumą su HLG (HDR vaizdo standartu, kurio laikytųsi grotuvai be Dolby Vision palaikymo).
Kad galėtume pateikti „Dolby Vision“ metaduomenis, turėjome juos nešioti kodeke, kurį pristatome. Laimei, Dolby sukūrė 10 profilį, skirtą Dolby Vision gabenimui AV1. Kadangi VP9 nesiūlo papildomų metaduomenų perdavimo, šiuo metu „Dolby Vision“ nepalaikoma, bet mes suinteresuoti ištirti alternatyvius pateikimo mechanizmus.
Tačiau „Dolby Vision“ profiliai 10 ir 8 nebuvo tinkamai palaikomi esamais vaizdo apdorojimo įrankiais, įskaitant FFmpeg ir Šaka pakuotojas. Remdamiesi Dolby specifikacijomis, bendradarbiavome su FFmpeg kūrėjais, siekdami visiškai įgyvendinti Dolby Vision Profile 8 ir Profile 10 palaikymą. Visų pirma, įgalinome FFmpeg palaikymą, kad HEVC su 8.4 profiliu perkoduotų į AV1 su 10.4 profiliu, naudodami ir libaom, ir libsvtav1 fiksatorius į kitas dalis, įskaitant pagamintus davstack kodavimo įrenginius. dekoderis ir Shaka paketuotojas, kad tinkamai palaikytų Dolby Vision metaduomenis.
2 iššūkis: „Dolby Vision“ įtraukimas į „AVSampleBufferDisplayLayer“.
Kai tiekiate AVSBDL užkoduotą bitų srautą palaikomu formatu, pvz., HEVC iš „iPhone“ fotoaparato, „Dolby Vision“ veikia nemokamai. Tačiau mes tiekiame buferius, kuriuos iššifruojame savarankiškai, nes turime turėti galimybę iššifruoti formatus, kurių Apple nesiūlo (pavyzdžiui, AV1 įrenginiuose prieš iPhone 15 Pro). Atsižvelgiant į šią sąranką, teisinga, kad „Dolby Vision“ taip pat turėtume išgauti atskirai.
Vadovaudamiesi naujai sukurta 10 profilio pernešimo AV1 bitų sraute iš Dolby specifikacijų, įdiegėme Dolby Vision metaduomenų ištraukimą rankiniu būdu, supakavome juos į tą patį formatą, kurio tikėjosi AVSBDL, ir pradėjome verslą.
Norėdami įrodyti, kad mūsų sąranka veikė taip, kaip tikėtasi, sukūrėme identiškų Instagram įrašų su Dolby Vision metaduomenimis ir be jų. Mūsų partneriai iš Dolby išmatavo kiekvieno iš šių įrašų ryškumą naudodami ekrano spalvų analizatorių, esant skirtingam ekrano ryškumo lygiui.
Jie užfiksavo šiuos dalykus:
Šioje diagramoje X ašis rodo ekrano ryškumo nustatymą, o Y ašis – stebimą vaizdo ryškumą. Rezultatai rodo, kad esant Dolby Vision metaduomenims, turinio ryškumas daug labiau atitinka ekrano ryškumo nustatymą.
Pavyko!…Bet mes to dar nebaigėme.
Išbandome „Dolby Vision“ diegimą
„Meta“ A/B išbando naujas funkcijas prieš jas pristatydami, kad įsitikintume, jog jos veikia taip, kaip tikėjomės. Kaip A/B tikriname vaizdo įrašo bitų sraute įterptus metaduomenis? Atsakymas yra tas, kad sukūrėme papildomą kiekvieno vaizdo įrašo versiją su naujais metaduomenimis. Mes pristatėme šią naują versiją atsitiktinai paskirstytai bandomajai populiacijai, o atsitiktinai paskirstyta kontrolinė populiacija ir toliau gavo esamą patirtį. Mūsų mastu galime tvirtinti, kad maždaug vienodas gyventojų skaičius žiūrės abu kiekvieno vaizdo įrašo variantus.
Kiekvienam skoniui rinkome statistiką, pvz., kiek laiko buvo žiūrimas vaizdo įrašas, kiek laiko užtruko įkėlimas, kokio tipo ryšiu jis buvo žiūrimas ir ar atkūrimo metu buvo aptikta klaidų. Tada bendrai analizavome, kaip skonis su metaduomenimis lyginamas su skoniu be.
Iškėlėme hipotezę, kad jei metaduomenys veiks taip, kaip tikėtasi, vaizdo įrašai su naujais metaduomenimis žiūrės daugiau laiko. Tačiau 2024 m. atlikę pradinį „Instagram Reels“ testą nustatėme, kad vaizdo įrašai su „Dolby Vision“ metaduomenimis iš tikrųjų buvo žiūrimi mažiau nei standartiniai jų analogai.
Kaip tai galėtų būti įmanoma? Ar ne „Dolby Vision“ turėtų pagerinti vaizdą?
Mūsų pirmasis A/B testas naudojant „Dolby Vision“ metaduomenis
Mūsų duomenys rodo, kad žmonės žiūrėjo mažiau „Dolby Vision“ vaizdo įrašų, nes vaizdo įrašų įkėlimas užtruko per ilgai, o žmonės tiesiog perėjo į kitą sklaidos kanalo ritinį.
Buvo pagrįsta priežastis, dėl kurios pailgėjo įkėlimo laikas: nauji metaduomenys vidutiniškai pridedami 100 kbps greičiu prie kiekvieno vaizdo įrašo. Skamba smulkmeniškai, bet mūsų koduotės yra labai optimizuotos visoms įvairioms žiūrėjimo sąlygoms. Kai kuriose situacijose kiekvienas bitas yra svarbus, o 100 kb/s spartos pakako, kad susitraukimas būtų sumažintas.
Atsakymas buvo suspaustas metaduomenų formatas. „Dolby“ komanda pasiūlė kitą specifikaciją, kuri sumažintų metaduomenų sąnaudas keturis kartus, vidutiniškai iki 25 kbps.
Ar užtektų? Turėjome atlikti dar vieną testą, kad sužinotume. Tačiau pirmiausia reikėjo atlikti daugiau darbų.
Mums reikėjo įdiegti „Dolby Vision“ metaduomenų glaudinimo (ir išskleidimo, kol tai darome) palaikymą FFmpeg naudojant bitų srauto filtrą. Be to, nors nesuglaudintą formatą galėjome išgauti iš bitų srauto ir perduoti „Apple“, suspausto formato „Apple“ nepalaiko iš karto. Turėjome patys įgyvendinti kliento pusės dekompresiją.
Maždaug 2000 kodo eilučių vėliau buvome pasiruošę.
Mūsų sėkmingas A/B testas
Šį kartą nustatėme, kad vartotojai, žiūrintys naudodami „Dolby Vision“ metaduomenis, programoje praleidžia daugiau laiko. Tai priskiriame žmonėms, praleidžiantiems daugiau laiko žiūrėdami HDR vaizdo įrašus prasčiau apšviestoje aplinkoje, kai jų ekranai yra mažesnio ryškumo lygiu, o HDR vaizdo įrašai su tinkamais metaduomenimis mažiau vargina akis.
Kadangi „Dolby Vision“ metaduomenų įtraukimas davė apčiuopiamų teigiamų rezultatų, galėjome pasirūpinti, kad juos būtų galima pristatyti „iOS“ skirtoje „Instagram“ sistemoje, todėl tai tapo mūsų pirmąja programa, naudojanti „Dolby Vision“ pranašumus. 2025 m. birželio mėn. visose mūsų pateiktose AV1 koduotėse, gautose iš „iPhone“ sukurto HDR, yra „Dolby Vision“ metaduomenys.
Dolby Vision ateitis visoje meta
Paskutinis šio įrašo iššūkis yra tas, kad „Dolby Vision“ nėra plačiai palaikoma žiniatinklio ekosistemoje įvairiose naršyklėse ir ekranuose. Taigi negalime tiksliai parodyti skirtumo, kurį tai daro šiame puslapyje, ir tikimės, kad patys tai patirsite „Instagram“ naudodami „iPhone“. „Dolby vision“ ir „amve“ palaikymas dabar yra mūsų kodavimo receptuose, todėl jis yra paruoštas diegti kitose platformose, taip pat šiuo metu stengiamės išplėsti palaikymą „Facebook Reels“.
Bendradarbiaudami su „Dolby“, išsprendėme pastebimą HDR metaduomenų išsaugojimo problemą ir bendradarbiavome su „FFmpeg“ kūrėjais, kad įdiegtume jos palaikymą ir kad bendruomenė galėtų ja pasinaudoti.
Tai tik pradžia. Nekantraujame išplėsti „Dolby Vision“ į kitas „Meta“ programas ir atitinkamas operacines sistemas.
Padėkos
Norėtume padėkoti Haixia Shi, Dolby komandai ir Niklas Haas iš FFmpeg už jų darbą remiant šias pastangas.
