Kuidas videokoodek töötab. Osa 2. Mis, milleks, kuidas

Esimene osa: Videotehnoloogia ja piltide alused

Mida? Videokodek on tarkvara/riistvara osa, mis tihendab ja/või lahtipakkib digitaalset videot.

Milleks? Hoolimata anumõningatest piirangutest nii ribalaiuse kui ka salvestusruumi osas, nõuab turg üha kvaliteetsemat videot. Kas mäletate, kuidas eelmisel postitusel arvutasime, et 30 kaadrit sekundis, 24 bitti pikseli kohta ja 480×240 resolutsiooniga on vajalik minimaalne 82,944 Mbit/s ilma tihendamiseta? Tihendamine on praegu ainus võimalus edastada HD/FullHD/4K televisiooni ekraanidele ja internetti. Kuidas see saavutatakse? Vaatame lühidalt peamisi meetodeid.
ja andmete salvestamise mahu osas nõuab turg üha kvaliteetsemat videot. Kas mäletate, kuidas me eelmine kord arvutasime vajaliku miinimumi 30 kaadrit sekundis, 24 bitti pikseli kohta, eraldusvõimega 480×240? Saime 82,944 Mbit/s ilma pakkimata. Pakkimine on praegu ainus viis HD/FullHD/4K edastamiseks televisiooniekraanidele ja internetti. Kuidas seda saavutatakse? Vaatame nüüd lühidalt peamisi meetodeid.

Tõlge on tehtud EDISON Software'i toetusel.

Me tegeleme videovalve süsteemide integreerimisega, samuti arendame mikrotomograafi.

Kodek vs konteiner

Algajate sagedane eksitus on segi ajada digitaalvideo kodek ja digitaalvideo konteiner. Kokkulepe on mingi formaat. See on anum, mis sisaldab video (ja võimalusel ka audio) metaandmeid. Tihendatud videot võib pidada konteineri kasulikuks laadimiseks.

Videofaili laiend tavaliselt näitab selle konteineri tüüpi. Näiteks fail video.mp4 on tõenäoliselt konteiner. MPEG-4 Part 14, kuid fail nimega video.mkv on tõenäoliselt matrioška. Et olla täielikult kindel kodeki ja konteineri formaadi osas, saab kasutada FFmpeg või MediaInfo.

Veidi ajalugu

Enne kui läheme edasi Kuidas?, uurime veidi ajalugu, et mõista paremini mõningaid vanemaid kodekeid.

Videokodek H.261 tuli välja 1990. aastal (tehniliselt 1988) ja see loodi 64 Kbit/s andmeedastuskiirusel töötamiseks. Sellega kasutati juba selliseid ideid nagu värvisubdiskreetimine, makroblokid jne. 1995. aastal avaldati videokodeki standard H.263, mis arenes edasi kuni 2001. aastani.

2003. aastal lõpetati esimese versiooni H.264/AVC. Samal aastal käivitas ettevõte „TrueMotion“ oma tasuta lossidega videokodeki nimega VP3. 2008. aastal ostis Google selle ettevõtte, käivitades VP8 samal aastal. Detsembris 2012 vabastas Google VP9, ja seda toetab umbes ¾ brauseriturust (sealhulgas mobiilised seadmed).

AV1 — see on uus avatud lähtekoodiga videokooder, mille arendas välja Avatud Meedia Allianss (AOMedia), kuhu kuuluvad tuntud ettevõtted nagu: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel ja Cisco. Esimene kooderi versioon 0.1.0 avaldati 7. aprillil 2016.

AV1 sünd

2015. aasta alguses töötas Google VP10, Xiph (mis kuulub Mozilla'le) töötas Daala, ja Cisco lõi oma tasuta videokooderi nimega Thor.

Seejärel MPEG LA tundis algselt muret aastaste piirangute üle HEVC (H.265) ja tasu, mis oli 8 korda kõrgem kui H.264, kuid hiljem muutsid nad reegleid taas:

ilma aastaste piiranguteta,
tasu sisu eest (0,5% tulust) ja
tasu tooteühiku kohta, mis oli umbes 10 korda kõrgem kui H.264.

Avatud Meedia Allianss loodi erinevate valdkondade ettevõtete poolt: riistvara tootjad (Intel, AMD, ARM, Nvidia, Cisco), sisuteenuse pakkujad (Google, Netflix, Amazon), brauserite arendajad (Google, Mozilla) ja teised.

Ettevõtetel oli ühine eesmärk — litsentsitasudeta videokooder. Seejärel ilmus AV1 kaugelt lihtsama patendilitsentsiga. Timothy B. Terriberry tegi vapustava esitluse, mis on aluseks praegusele AV1 kontseptsioonile ja selle litsentsimudelile.

Teid üllatab, et AV1 koodekit saab analüüsida brauseri kaudu (huvilised võivad külastada aomanalyzer.org).

Universaalne koodek

Vaatame üle universaalse videotöötluskoodeki põhimehhanismid. Enamik neist kontseptsioonidest on kasulikud ja neid kasutatakse kaasaegsetes koodekites, nagu VP9, AV1 ja HEVC. Hoian käes, et paljusid selgitatud asju lihtsustatakse. mõnikord kasutatakse reaalseid näiteid (nagu H.264 puhul) tehnoloogiate demonstreerimiseks.

1. samm – pildi jagamine

Esimene samm on kaadri jagamine mitmeks osaks, alamosas ja edasi.

Miks? On palju põhjuseid. Kui me jagame pildi, saame täpsemalt ennustada liikumisvektorit, kasutades väikeseid osi väikeste liikuvate elementide jaoks. Samas saab staatilise tausta puhul piirduda ka suuremate osadega.

Tavaliselt korraldavad koodekid need osad sektsioonidesse (või fragmentidesse), makrobloeckidesse (või koodipuude plokkidesse) ja mitmesse alamsektsiooni. Nende osade maksimaalne suurus varieerub; HEVC seab piiriks 64×64, samas kui AVC kasutab 16×16, ning alamsektsioonid võivad olla kuni 4×4.

Kas mäletate kaadreid eelmisest artiklist?! Seda saab rakendada ka plokkidele, seega võivad meil olla I-fragment, B-plokk, P-makrobloeck jne.

Neile, kes soovivad harjutada — vaadake, kuidas pilt jaguneb osadeks ja alamseksioonideks. Selleks saab kasutada juba eelnevalt mainitud tööriista Intel Video Pro Analyzer (see, mis on tasuline, kuid millel on tasuta prooviversioon, millel on piirang esimesed 10 kaadrit). Siin analüüsitakse sektsioone. VP9:

2. samm — prognoosimine

Kui meil on osad olemas, saame nende põhjal koostada astroloogilisi prognoose. Selleks INTER-prognoosimise korral on vaja edastada liikumise vektorid ja jääk, samas kui INTRA-prognoosimise puhul edastatakse prognoosi suund ja jääk.

3. samm — teisendamine

Pärast seda, kui oleme saanud jääkploki (ennetatud osa → tegelik osa), on võimalik seda muuta nii, et teame, millised pikslid saab kõrvale jätta, säilitades samas üldise kvaliteedi. On olemas teatud teisendusi, mis tagavad täpse käitumise.

Kuigi on ka teisi meetodeid, vaatame neid lähemalt. diskreetne kosinusmuundumine (DCT — lühend diskreetne kosinusmuundumine). DCT peamised omadused:

• Muudab piksliplokid ühesuurusteks sageduskoefitsiendi plokkideks.
• Kondenseerib energiat, aidates kaotada ruumilist ülemäärasust.
• Tagab pööratavuse.

2. veebruaril 2017 avaldasid Cintra R.J. ja Bayer F.M. artikli DCT-sarnaste muundumiste kohta piltide kokkusurutamiseks, mis vajavad vaid 14 lisandit.

Ärge muretsege, kui te ei mõistnud iga punkti eeliseid. Praegu veendume, et need on tõeliselt väärtuslikud, konkreetsete näidete kaudu.

Võtame näiteks sellise 8×8 piksliploki:

See plokk renderdatakse järgmiseks 8 x 8 piksliseks pildiks:

Kohaldame DCT-d sellele piksliplokile ja saame 8×8 koefitsiendi ploki:

Ja kui renderdame selle koefitsientide ploki, saame sellise pildi:

Kuidas näeme, see ei sarnane algsele pildile. Saame märgata, et esimene koefitsient erineb tugevalt kõigist teistest. See esimene koefitsient on tuntud kui DC-koefitsient, mis esindab kõiki valimisi sisendis, midagi sarnast keskmisele väärtusele.

Sellel koefitsientide plokil on huvitav omadus: see eraldab kõrgsageduskomponendid madalsageduskomponentidest.

Pildis on enamik võimsusest koondunud madalamatele sagedustele, seetõttu, kui teisendame pildi selle sageduskomponentideks ja kõrvaldame kõrgeima sageduse koefitsiendid, saame vähendada pildi kirjeldamiseks vajalike andmete hulka, ohverdamata liiga palju kvaliteeti.

Sagedus tähendab, kui kiiresti signaal muutub.

Katsume rakendada teadlikkust, mida omandatud testnäites, muutes algse pildi selle sageduseks (koefitsientide plokk), kasutades DCT-d, ja seejärel kõrvaldame vähem olulised koefitsiendid.

Esmalt konverteerime selle sagedusvaldkonda.

Edasi viskame osa (67%) koefitsientidest, peamiselt alumise parempoolsest osast.

Lõpuks taastame pildi sellest visatud koefitsiendiblokist (pidage meeles, et see peab olema pööratav) ja võrdleme originaaliga.

Näeme, et see sarnaneb algse pildiga, kuid originaalist on palju erinevusi. Oleme eemaldanud 67,1875% ja saadud midagi, mis meenutab esialgset allikat. Koefitsiendite viskamine oleks võinud olla läbimõeldum, et saada veel parema kvaliteediga pilt, kuid see on juba järgmine teema.

Iga koefitsient moodustatakse kasutades kõiki pikslite

Oluline: iga koefitsient ei kuva otse ühte pikslit, vaid esindab kõigi pikslite kaalutud summat. See imeline joonis näitab, kuidas arvutatakse esimene ja teine koefitsient, kasutades iga indeksi jaoks ainulaadseid kaalusid.

Saate proovida visualiseerida DCT-t, vaadates lihtsalt pildi loomist selle põhjal. Näiteks on siin sümbol A, mis on loodud iga koefitsiendi kaalu abil:

4. samm — kvantimine

Pärast seda, kui eelmisel sammul teatud koefitsiendid välja visatakse, teeme viimases etapis (muundamine) spetsiaalset vormi kvantimist. Sel etapil on informatsiooni kaotamine lubatud. Lihtsamalt öeldes kvantime koefitsiente, et saavutada kompressioon.

Kuidas kvantida koefitsientide plokki? Üks lihtsamaid meetodeid on ühtlane kvantimine, kus võtame ploki, jagame selle ühe väärtusega (näiteks 10) ja ümardame saadud tulemuse.

Kas suudame seda koefitsientide plokki tagasi pöörata? Jah, saame, korrutades selle sama väärtusega, millega jagasime.

See lähenemine ei ole parim, kuna see ei arvesta iga koefitsiendi tähtsust. Võiksime kasutada kvantimismaatriksit, mitte ühte väärtust, ja see maatriks võib kasutada DCT omadust, kvantides enamik alumisi paremaid ja vähemuses ülemisi vasakuid.

5. samm – entroopia kodeerimine

Pärast andmete kvantimist (pildi plokid, fragmendid, kaadrid) saame neid endiselt kaotusteta kokkusurutuna. Andmete kokkusurumiseks on palju algoritmilisi meetodeid. Tutvume lühidalt mõnega, sügavamaks mõistmiseks võite lugeda raamatut „Kokkulepete mõistmine: andmete kokkusurumine kaasaegsetele arendajatele“ (Understanding Compression: Data Compression for Modern Developers»).

Videokodeerimine VLC abil

Oletame, et meil on sümbolite voog: a, e, r ja t. Tabelis on esitatud tõenäosus (vahemikus 0 kuni 1) iga sümboli esinemiseks voos.

Saame omistada unikaalsed binaarkoodid (eelistatavalt väikesed) kõige tõenäolisematele ja suuremad koodid vähem tõenäolistele.

Surume voogu kokku, eeldades, et kulutame iga sümboli kohta 8 bitti. Ilma kokkusurumiseta kuluks iga sümboli kohta 24 bitti. Kui asendada iga sümbol tema koodiga, siis see toob kaasa kokkuhoidu!

Esimene samm on sümboli kodeerimine e, mis on 10, ja teine sümbol on a, mis lisatakse (mitte matemaatiliselt): [10] [0], ja lõpuks kolmas sümbol t, mis muudab meie lõpliku surutud bittvoo võrdseks [10] [0] [1110] või 1001110, mille jaoks on vaja vaid 7 bitti (3,4 korda vähem ruumi kui originaalis).

Pange tähele, et iga kood peab olema ainulaadne kood eelmääratud prefiksiga. Huffmani algoritm aitab leida neid numbreid. Kuigi see meetod ei ole ilma puudusteta, on olemas videokodeerijad, mis pakuvad endiselt seda algoritmilist meetodit kompressiooniks.

N nii kodeerijal kui dekodeerijal peab olema juurdepääs sümbolite tabelile koos nende binaarkoodidega. Seega on vajalik edastada sisendandmetele ka tabel.

Aritmeetiline kodeerimine

Oletame, et meil on sümbolite voog: a, e, r, s ja t, ja nende tõenäosus on esitatud selles tabelis.

Koostame selle tabeli alusel vahemikud, mis sisaldavad kõiki võimalikke sümboleid, sorteeritud maksimaalse arvu järgi.

Nüüd kodeerime kolme sümboli voo: eat.

Esialgu valime esimese sümboli e, mis asub vahemikus 0,3 kuni 0,6 (ilma nende hulgast). Võtame selle vahemiku ja jagame selle uuesti samades proportsioonides, kuid juba selle uue vahemiku jaoks.

Jätkame meie voolu kodeerimist eat. Nüüd võtame teise sümboli a, mis asub uues alamvahemikus 0,3 kuni 0,39, ja seejärel võtame meie viimase sümboli t ja kordame sama protsessi, et saada viimane alamvahemik 0,354 kuni 0,372.

Peame lihtsalt valima numbri viimases alamvahemikus 0,354 kuni 0,372. Valime 0,36 (aga võime valida ka mis tahes muu numbri selles alamvahemikus). Ainult sellega saame taastada meie algse voolu. See on nagu joonistamine joonena vahemike sees meie voolu kodeerimiseks.

Tagasioperatsioon (ehk siis dekodeerimine) on samuti lihtne: meie numbri 0,36 ja meie algse vahemikuga saame käivitada sama protsessi. Kuid nüüd, kasutades seda numbrit, tuvastame voolu, mis on kodeeritud selle numbri abil.

Esimese vahemikuga märkame, et meie number vastab lõikele, seega on see meie esimene sümbol. Nüüd jagame jälle selle alamvahemiku, tehes sama protsessi nagu varem. Siin võib näha, et 0,36 vastab sümbolile a, ja protsessi kordamise järel oleme jõudnud viimase sümbolini t (formeerides meie algse kodeeritud voolu eat).

Nii kodeerijale kui dekooderile peab olema olemas sümbolite tõenäosuste tabel, seega tuleb sisenemisandmetes edastada ka see.

Üsna elegantne, eks? Keegi, kes selle lahenduse välja mõtles, oli ülimalt tark. Mõned videokooderid kasutavad seda tehnikat (või, igal juhul, pakuvad seda kui valikuvõimalust).

Käitumine seisneb kvantitud bitivoo kaotusteta kokkusurumises. Kindlasti puuduvad selles artiklis tohutult detaile, põhjuseid, kompromisse jne. Kuid kui olete arendaja, peaksite teadma rohkem. Uued kodeerijad püüavad rakendada erinevaid entropiaga kodeerimise algoritme, nagu ANS.

6. samm – bitivoogude formaat

Pärast kõigi nende toimingute tegemist tuleb dekompressida kokkusurutud kaadrid, arvestades tehtud samme. Dekooder peab olema selgelt informeeritud kodeerija tehtud otsustest. Dekooderile tuleb anda kogu vajalik teave: bitisügavus, värviruumi, eraldusvõime, prognooside teave (liikumisvektorid, suunatud INTER-prognoosimine), profiil, tase, kaadrisagedus, kaadritüüp, kaadri number ja palju muud.

Tutvustame pinnapealselt bitivoogu H.264. Meie esimene samm on luua minimaalne H.264 bitivoog (FFmpeg lisab vaikimisi kõik kodeerimise parameetrid, näiteks SEI NAL — õpime hiljem, mis see on). Saame seda teha, kasutades meie enda hoidlat ja FFmpeg'i.

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

See käsk genereerib toore bitivoogu H.264 ühe kaadriga, resolutsiooniga 64×64, värviruumiga YUV420. Kasutatakse järgmine pilt kaadrina.

H.264 bitivoog

Standart AVC (H.264) määrab, et teave saadetakse makrokadrites (võrgu mõttes), mida nimetatakse NAL (see on võrgu abstraktsioonitaseme mõisted). NAL-i peamine eesmärk on pakkuda „võrgusõbralikku“ video esitust. See standard peaks töötama televisioonides (voogude põhjal), Internetis (pakettide põhjal).

On sünkroonimismärker, mis määrab NAL-elementide piirid. Igal sünkroonimismärkeril on väärtus 0x00 0x00 0x01, , välja arvatud esimesel, mille väärtus on 0x00 0x00 0x00 0x01. Kui käivitame hexdump H.264 bitivooge genereerimiseks tuvastame vähemalt kolm NAL mustrit faili alguses.

Nagu mainitud, peab dekooder teadma mitte ainult pildidatal, vaid ka video, kaadrid, värvid, kasutatavad parameetrid ja palju muud. Iga NAL-i esimene bait määrab selle kategooria ja tüübi.

Tavaliselt on esimene NAL bitivoog SPS. See NAL tüüp vastutab kodeerimise üldiste muutujaid, nagu profiil, tase, resolutsioon jne, teavitamise eest.

Kui süntaksiväärisat prve markerit vahele jätta, saame dekodeerida esimese baidi, et teada, mis tüüpi NAL on esimene.

Näiteks, esimene bait süntaksivääristamise märgise järel on 01100111, kus esimene bitt (0) asub väljadel forbidden_zero_bit. Järgmised 2 bitti (11) informeerivad meid väljast nal_ref_idc, mis näitab, kas see NAL on viidatud väljana või mitte. Ja ülejäänud 5 bitti (00111) informeerivad meid väljast nal_unit_type, antud juhul on see SPS plokk (7) NAL.

Teine bait (binary=01100100, hex=0x64, dec=100) SPS NAL-is on see väli profile_idc, mis näitab profiili, mida kodeerija kasutas. Antud juhul kasutati piiratud kõrget profiili (st kõrge profiil ilma kahepoolse B-segmendi toeta).

Kui tutvuda bitivoo spetsifikatsiooniga H.264 SPS NAL-i jaoks, siis leiame palju väärtusi parameetri nime, kategooria ja kirjelduse jaoks. Näiteks vaatame parameetreid pic_width_in_mbs_minus_1 ja pic_height_in_map_units_minus_1.

Kui teeme nendest väli väärtustest teatud matemaatilisi toiminguid, saame resolutsiooni. Võime esitada 1920 x 1080, kasutades pic_width_in_mbs_minus_1 väärtust 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Taas, ruumi säästmiseks, kodeerimise asemel 1920 tegime seda 119-ga.

Kui jätkame meie loodud video kontrolleeringut binaarselt (nt: xxd -b -c 11 v/minimal_yuv420.h264), siis saame liikuda viimase NAL-i juurde, mis on kaader ise.

Siin näeme selle esimesi 6 baitide väärtusi: 01100101 10001000 10000100 00000000 00100001 11111111. Kuna on teada, et esimene bait näitab NAL tüüp, siis on antud juhul (00101) tegemist IDR fragmendiga (5), ja seega saab seda veelgi uurida:

Kasuta spetsifikatsiooni teavet, et dekodeerida fragmendi tüüp (slice_type) ja kaadrinumber (frame_num) teiste oluliste väljade seas.

Mõnede väljade väärtuste saamiseks (ue(v), me(v), se(v) või te(v)), peame dekodeerima frakmendi spetsiaalse dekooderiga, mis põhineb Golembi eksponentsiaalsel kodeerimisel. See meetod on väga efektiivne muutuva väärtuse kodeerimisel, eriti kui on palju vaikeväärtusi.

Väärtused slice_type ja frame_num Selle video väärtused on 7 (I-fragment) ja 0 (esimene kaader).

Biti voogu võib käsitleda kui protokolli. Kui soovite rohkem teada, uurige spetsifikatsiooni ITU H.264. Siin on makroskeem, mis näitab, kus asuvad pildiparameetrid (YUV komprimeeritult).

Võib uurida ka teisi bitivooge, nagu VP9, H.265 (HEVC) või isegi meie uusimat parimat bitivoogu AV1. Kas need on kõik sarnased? Ei, kuid kui mõistate vähemalt ühte — on oluliselt lihtsam mõista teisi.

Soovite harjutada? Uurige H.264 bitivoogu

Saate genereerida ühekaadrilisi videoid ja kasutada MediaInfo, et uurida bitivoolu H.264. Tegelikult ei takista miski ka lähtekoodi vaatamast, mis analüüsib bitivoolu H.264 (AVC).

Praktikaks võite kasutada Intel Video Pro Analyzerit (olen juba aru saanud, et programm on tasuline, kuid seal on tasuta prooviversioon, millel on 10 kaadri piirang?).

Ülevaade

Tuleb märkida, et paljusid kaasaegseid koodekeid kasutatakse sama mudeli järgi, mille just õppisime. Vaatame nüüd videokodeki vooskeemi Thor. See sisaldab kõiki samme, mida oleme läbinud. Selle märkuse põhisisu on, et teil oleks vähemalt parem arusaam uuendustest ja dokumentatsioonist sellel alal.

Varem arvutasime, et ühe tunni pikkuse 720p ja 30 fps video faili hoidmiseks läheb vaja 139 GB ketta ruumi. Kui kasutada selles artiklis käsitletud meetodeid (vahekaadri ja sisemised prognoosid, transformatsioon, kvantimine, entropiikodeerimine jne), on võimalik saavutada (arvestades, et kulutame 0,031 bitti pikseli kohta) täiesti rahuldava kvaliteediga video, mille suurus on vaid 367,82 MB, mitte 139 GB.

Kuidas H.265 saavutab paremat kokkusurumisastet kui H.264?

Nüüd, kui me teame rohkem, kuidas kodeerijad töötavad, on lihtsam mõista, kuidas uued kodeerijad suudavad pakkuda kõrgemat eraldusvõimet väiksema andmemahtude kasutamisega.

Kui võrrelda AVC ja HEVC, tuleb meeles pidada, et see on peaaegu alati valik suurema CPU koormuse ja kokkusurumise astme vahel.

HEVC omab rohkem sektsioonide (ja alamsektsioonide) variante kui AVC, rohkem suundi sisemise prognoosimise jaoks, täiustatud entropiakodeerimine ja palju muud. Kõik need täiustused on teinud H.265 võimeliseks suruma 50% rohkem kui H.264.

Esimene osa: Videotehnoloogia ja piltide alused

Allikas: habr.com