Kuidas töötab videokooder. Osa 2. Mis, miks, kuidas

Esimene osa: Videote ja piltide töötamise alused

Mis? Videokodek on osa tarkvarast/riistvarast, mis surub kokku ja/või avab digitaalset videot.

Milleks? Hoolimata teatud piirangutest nii ribalaiuse kui ka andmete salvestusruumi osas, nõuab turg järjest kvaliteetsemat videot. Kas mäletate, kuidas eelnevas postituses arvutasime minimaalset vajalikkust 30 kaadrit sekundis, 24 bitti pikseli kohta, eraldusvõimega 480×240? Saime 82,944 Mbit/s surveta. Surumine on senini ainus viis HD/FulHD/4K edastamiseks teleriekraanidele ja internetti. Kuidas see saavutatakse? Praegu vaatame kokkuvõtlikult peamisi meetodeid.
Tõlge on tehtud EDISON Software'i toetusel.

Tegeleme

videovalve süsteemide integratsiooniga arendame mikrotomograafi, samuti Kodek vs konteiner.

Levinud algajate viga on segi ajada digitaalse video kodek ja digitaalse video konteiner. Konteiner on mingisugune formaat, mis sisaldab video (ja võib-olla ka heli) metaandmeid. Kompressitud videot võib käsitleda konteineri kasulikku koormana.

Tavaliselt näitab video faili laiend, milline on selle konteineri tüüp. Näiteks fail video.mp4 on tõenäoliselt konteiner

MPEG-4 Part 14 , samas kui faili nimega video.mkv puhul on see tõenäoliseltmatrioška . Et olla täielikult kindel kodeki ja konteineri formaadi osas, võib kasutadaFFmpeg MediaInfo või Natuke ajalugu.

Enne kui liigume edasi

, uurime natuke ajalugu, et paremini mõista mõningaid vanemaid kodekeid. Kuidas?Videokodek

H.261 ilmus 1990. aastal (tehniliselt 1988) ja loodi andmeedastuskiirusel 64 Kbit/s töötamiseks. Selles kasutati juba selliseid ideid nagu värvisubdiske, makroblokid jne. 1995. aastal avaldati videokodeki standard H.263 , mis arenes edasi kuni 2001. aastani.2003. aastal lõpetati esimene versioon

H.264/AVC . Samal aastal viis ettevõte „TrueMotion” turule tasuta videokodeki, mis komprimeeris videot kaotava meetodiga nimegaVP3 . 2008. aastal ostis Google selle ettevõtte ja välja andisVP8 samal aastal. 2012. aasta detsembris avaldas Google VP9 , mis on toetatud umbes ¾ browsereid (sealhulgas mobiilseadmeid)., ja see toetatakse umbes ¾ brauserituru osast (sealhulgas mobiilseadmed).

AV1 on uus tasuta avatud lähtekoodiga videokoodek, mille on välja töötanud Avatud meedia alianss (AOMedia), kuhu kuuluvad tuntud ettevõtted nagu: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel ja Cisco. Koodeki esialgne versioon 0.1.0 avaldati 7. aprillil 2016.

AV1 sünd

2015. aasta alguses töötas Google VP10, Xiph (mille omanik on Mozilla) töötas Daala, ja Cisco valmistas oma tasuta videokoodeki nimega Thor.

Seejärel MPEG LA kõigepealt kuulutas aastased piirangud HEVC (H.265) ja tasu, mis on 8 korda kõrgem kui H.264, kuid peagi muutsid nad reegleid taas:

ilma aastase piiranguta,
tasud sisu eest (0,5% tuludest) ja
tooteühiku tasu, mis on umbes 10 korda kõrgem kui H.264.

Avatud meedia alianss loodi erinevate valdkondade ettevõtete poolt: seadmete tootjad (Intel, AMD, ARM, Nvidia, Cisco), sisu tarnijad (Google, Netflix, Amazon), brauserid (Google, Mozilla) ja teised.

Ettevõtetel oli ühine eesmärk – välja töötada videokoodek, mis ei nõua litsentsitasusid. Siis ilmub AV1 hoopis lihtsama patendilitsentsiga. Timothy B. Terriberry tegi hämmastava esituse, mis sai praeguse AV1 kontseptsiooni ja litsentsimudelina.

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

Universaalne koodek

Vaatame põhimehhanismid, mis on universaalse videokoodeki aluseks. Enamik neist kontseptsioonidest on kasulikud ja neid kasutatakse tänapäeva koodekites, nagu , mis on toetatud umbes ¾ browsereid (sealhulgas mobiilseadmeid)., AV1 ja HEVC. Hoian teid kursis, et paljusid selgitatavaid asju lihtsustatakse. Mõnikord kasutatakse reaalseid näiteid (näiteks H.264-i korral) tehnoloogia demonstreerimiseks.

1. samm — pildi jaotamine

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

Miks? On palju põhjuseid. Kui jagada pilt, on võimalik täpsemalt ennustada liikumise suunda, kasutades väikeseid osi väikeste liikuvate osade jaoks. Samas, staatilise tausta jaoks võib piirduda ka suuremate osadega.

Tavaliselt korraldavad koodekid need jaotised jaotistes (või fragmendid), makrobotloodes (või kodeerimise puu plokid) ja arvukates alamjaotistes. Nende jaotiste maksimaalne suurus varieerub, HEVC seadistab 64×64, samas kui AVC kasutab 16×16, ning alamjaotised võivad jaguneda kuni 4×4 suurustesse.

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

Neile, kes soovivad harjutada — vaadake, kuidas pilt jaguneb jaotisteks ja alamjaotisteks. Selleks saab kasutada eelnevalt mainitud tööriista. Intel Video Pro Analyzer (see on tasuline, kuid tasuta prooviversiooniga, millel on piirang esimestele 10 kaadrile). Siin on analüüsitud jaotised. , mis on toetatud umbes ¾ browsereid (sealhulgas mobiilseadmeid).:

2. samm — ennustamine

Kui meil on jaotised olemas, saame nende põhjal koostada ennustusi. Selleks INTER-ennustamine on vajalik edastada liikumisvektorid ja jääk, ning INTRA-ennustamise puhul edastatakse ennustamise suund ja jääk.

3. samm — teisendamine

Pärast jääkploki (ennustatud jaotus → tegelik jaotus) saamist on võimalik seda teisendada viisil, mis näitab, milliseid pikseleid saab kõrvaldada, samal ajal säilitades üldise kvaliteedi. On olemas teatud teisendusi, mis tagavad täpse käitumise.

Kuigi on ka teisi meetodeid, vaatleme üksikasjalikumalt diskreetset kosinusmuundamist (DCT — lühend diskreetne kosinusmuundamine). DCT põhiülesanded:

• Muudab piksliplokid ühetasandilisteks sageduskoefitsientide plokkideks.
• Kompaktib energiat, aidates kõrvaldada ruumilise ülemäärasuse.
• Tagab pööratavuse.

2. veebruaril 2017 avaldasid Cintra R.J. (Cintra, R.J.) ja Bayer F.M. (Bayer F.M.) artikli DCT-sarnaste muundamiste kohta piltide tihendamiseks, milleks on vajalik vaid 14 liitmist.

Ärge muretsege, kui te ei mõistnud iga punkti eeliseid. Nüüd vaatame konkreetsete näidete abil nende tõelist väärtust.

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

See plokk renderdatakse järgmise 8×8 pikseliga:

Rakendame DCT sellele piksliplokile ja saame 8×8 suuruse koefitsientide ploki:

Ja kui me renderdame selle koefitsientide ploki, saame sellise pildi:

Nagu näeme, ei sarnane see algse pildiga. On märgata, et esimene koefitsient erineb tugevalt kõigist teistest. Seda esimest koefitsienti tuntakse kui DC-koefitsienti, mis esindab kõiki valimeid sisendmassiivis, midagi sarnast keskmisele.

Selle koefitsientide ploki puhul on huvitav omadus: see eraldab kõrgsageduslikud komponendid madalsageduslikest.

Pildis on suurem osa võimsusest koondunud madalamatele sagedustele, seega, kui me muundame pildi selle sageduskomponentideks ja viskame kõrgsageduslikud koefitsiendid ära, saame vähendada andmete hulka, mis on vajalik pildi kirjeldamiseks, ega ohverda seejuures liiga palju kvaliteeti.

Sagedus tähendab, kui kiiresti signaal muutub.

Proovime rakendada teadmisi, mida saime testnäites, muundades algset pilti selle sagedusesse (koefitsientide ploki), kasutades DCT-d, ja visates seejärel ära osa vähem olulistest koefitsientidest.

Esiteks konverteerime selle sagedusruumi.

Seejärel viskame ära osa (67%) koefitsientidest, peamiselt alumise parempoolse osa.

Lõpuks taastame pildi sellest visatud koefitsientide plokist (peame meeles pidama, et see peaks olema pööratav) ja võrdleme originaaliga.

Näeme, et see meenutab algset pilti, kuid originaalist on palju erinevusi. Oleme visanud ära 67,1875% ja saime siiski midagi, mis meenutab esialgset. Koefitsientide väljaviskamisega oleks võinud olla mõistlikum, et saada veel paremat kvaliteeti, kuid see on juba järgmine teema.

Iga koefitsient kujuneb kõigi pikslite põhjal.

Oluline: iga koefitsient ei kajastu otseselt ühes pikslis, vaid esindab kaalutud summat kõigist pikslitest. See muljetavaldav joonis näitab, kuidas arvutatakse esimest ja teist koefitsienti, kasutades igale indeksile unikaalseid kaalu.

Samuti võite proovida DCT-d visualiseerida, vaadates lihtsat kujundamist selle põhjal. Näiteks siin on täht A, mis on vormitud iga koefitsendi kaalu abil:

4. samm — kvantiseerimine

Pärast seda, kui eemaldame mõned koefitsiendid eelneval sammul, viime viimases etapis (muundamine) läbi erilise kvantimisvormi. Sel etapil on teabe kaotamine lubatud. Teisisõnu, kvantime koefitsiendid, et saavutada kokkusurumine.

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

Kas saame selle koefitsiendi ploki tagasi pöörata? Jah, saame, korrutades sama väärtusega, millega jagasime.

See lähenemine ei ole parim, kuna see ei arvesta iga koefitsiendi tähtsust. Saaksime kasutada kvantimismatriisi ühe väärtuse asemel, ning see matt aitab DCT omadust, kvantides enamiku alumistes paremates ja vähemuse ülemistes vasakutes koefitsientides.

5. samm — entropiakodeerimine

Pärast seda, kui oleme andmed (pildiplokid, fragmendid, kaadrid) kvantinud, saame neid endiselt kaotusteta kokku suruda. Andmete kokkusurumiseks on palju algoritmilisi viise. Kavatseme tutvuda mõnega neist, sügavamate teadmiste saamiseks võite lugeda raamatut „Kokku surumise mõistmine: andmete kokkusurumine kaasaegsetele arendajatele“ (Understanding Compression: Data Compression for Modern Developers»).

Videote kodeerimine kasutades VLC-d

Oletame, et meil on sümbolite voog: a, e, r ja t. Iga sümboli esinemise tõenäosus (vahemikus 0 kuni 1) on esitatud selles tabelis.

Saame anda ainulaadsed binaarkoodid (soovitavalt väikesed) kõige tõenäolisematele sümbolitele, samal ajal kui suuremad koodid on vähem tõenäolistele.

Kokku surume voogu, arvestades, et kulutame lõpuks 8 bitti iga sümboli kohta. Ilma kokkusurumiseta oleks iga sümboli jaoks vaja 24 bitti. Kui iga sümbol asendada tema koodiga, siis saavutame kokkuhoidu!

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

Pange tähele, et iga kood peab olema ainulaadne prefiksikood. Huffman'i algoritm aitab, kuidas neid numbreid leida. Kuigi see meetod pole veatu, on olemas videokodeerijad, mis pakuvad endiselt seda algoritmilist meetodit kokkusurumiseks.

N nii kodeerijal kui ka dekooderil peab olema juurdepääs tähestikule koos nende binaarkoodidega. Seetõttu tuleb ka andmetes edastada tähestik.

Aritmeetiline kodeerimine

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

Selle tabeliga ehitame vahemikud, mis sisaldavad kõiki võimalikke sümboleid, sorteeritud suurima tõenäosuse järgi.

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

Esiteks valime esimese sümboli e, mis on vahemikus 0,3 kuni 0,6 (ilma selleta). Võtame selle vahemiku ja jagame selle uuesti samade proportsioonide järgi, kuid nüüd selle uue vahemiku jaoks.

Jätkame meie voo kodeerimist eat. Nüüd võtame teise sümboli a, mis asub uues vahemikus 0,3 kuni 0,39, ja siis võtame meie viimase sümboli t ja, korrates sama protsessi uuesti, saame viimase vahemiku 0,354 kuni 0,372.

Me peame lihtsalt valima arvu viimases vahemikus 0,354 kuni 0,372. Valime 0,36 (aga võib valida ka mõne muu arvu selles vahemikus). Ainult selle numbriga saame taastada meie originaalse voo. See on nagu tahaksime joonistada joont vahemike sees, et kodeerida meie voogu.

Tagurpidi operatsioon (st dekodeerimine) on sama lihtne: meie numbriga 0,36 ja meie algse vahemikuga saame alustada sama protsessi. Kuid nüüd, kasutades seda numbrit, tuvastame voo, mis on selle numbri abil kodeeritud.

Esimese vahemiku puhul märkame, et meie number vastab lõikepunktile, seega on see meie esimene sümbol. Jagame nüüd selle vahemiku uuesti, järgides sama protsessi nagu varem. Siin võib märgata, et 0,36 vastab sümbolile a, ja pärast protsessi kordamist jõuame viimase sümbolini t (moodustades meie algse kodeeritud voo. eat).

N nii kodeerijal kui ka dekooderil peab olema olemas tõenäosuste tabel, seega on vajalik edastada ka selle sisu.

Üsna elegantne, eks? Keegi, kes selle lahenduse välja mõtles, oli tõeliselt nutikas. Mõned videokodeerijad kasutavad seda tehnikat (või pakuvad seda igatahes valikuna).

Idee on kaotusteta kvantitud bitivoo kokkusurumine. Tõenäoliselt puuduvad selles artiklis tosin detaili, põhjuseid, kompromisse jne. Kuid kui olete arendaja, peaksite teadma rohkem. Uued koodekid püüavad kasutada erinevaid entropiakkodeerimise algoritme, nagu ANS.

6. samm — bitivoo formaat

Kui kõik need sammud on tehtud, jääb vaid dekompressida kokku pakitud kaadrid vastavalt tehtud sammudele. Dekooder tuleb selgelt teavitada kooderist tehtud otsustest. Dekooderile peab olema antud kogu vajalik teave: bitisügavus, värviruum, eraldusvõime, prognooside teave (liikumisvektorid, suunatud INTER-prognoosimine), profiil, tase, kaadrisagedus, kaadri tüüp, kaadri number ja palju muud.

Tutvume pinnapealselt bitivooga H.264. Meie esimene samm on luua minimaalne H.264 bitivoo (FFmpeg lisab vaikimisi kõik kodeerimise parameetrid, nagu SEI NAL — saame sellest veidi hiljem rohkem teada). Saame seda teha, kasutades oma reposi ja FFmpeg'i.

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

See käsk genereerib töötlemata bitivoo H.264 koos ühe kaadriga, eraldusvõimega 64×64, värviruumiga YUV420. Kasutame kaadrina järgmist pilti.

H.264 bitivoo

Standard AVC (H.264) määrab, et teave saadetakse makrogaotustes (võrgu mõistes), mida nimetatakse NAL (see on võrgu abstraktsioonitase). NAL peamine eesmärk on pakkuda videole "võrgusõbralikku" esitusviisi. See standard peab töötama televiisorites (voogude põhjal) ja Internetis (pakettide põhjal).

Nal on sünkroniseerimis marker, mis määrab NAL-elementide piirid. Iga sünkroniseerimis marker sisaldab väärtust 0x00 0x00 0x01, välja arvatud esimene, mis on võrdne 0x00 0x00 0x00 0x01. Kui käivitame hexdump genereeritud H.264 bitivoo kohta, suudame tuvastada vähemalt kolm NAL mustrit faili alguses.

Nagu mainitud, peab dekooder teadma mitte ainult pilditeavet, vaid ka video, kaadri, värvi, kasutatud parameetrite ja muu üksikasju. Iga NAL esimene bait määrab selle kategooria ja tüübi.

Tavaliselt on esimene NAL bitivoog SPS. See NAL-i tüüp vastutab kodeerimise üldiste muutujaid, nagu profiil, tase, eraldusvõime jms, teavitamise eest.

Kui jätta vahele esimene sünkroonimismärker, saame dekodeerida esimese baidi, et teada saada, milline NAL tüüp on esimene.

Näiteks, esimene bait pärast sünkroonimismärkerit on 01100111, kus esimene bitt (0) asub f väljasorbidden_zero_bit. Järgmised 2 bitti (11) annavad meile välja nal_ref_idc, mis näitab, kas see NAL on referentsväli või mitte. Ja ülejäänud 5 bitti (00111) annavad meile välja nal_unit_type, sel juhul on see SPS blokina (7) NAL.

Teine bait (binaarne=01100100, heks=0x64, dec=100) SPS NAL-is on väli profile_idc, mis näitab profiili, mida kasutaja kasutas. Sel juhul kasutati piiratud kõrge profiili (st kõrge profiil ilma kahepoolsete B-segmentide toeta).

Kui tutvuda bitivoogude spetsifikatsiooniga H.264 SPS NAL-i jaoks, saame palju väärtusi parameetrite nime, kategooria ja kirjelduse jaoks. Näiteks vaatame välju pic_width_in_mbs_minus_1 ja pic_height_in_map_units_minus_1.

Kui teeme mõningaid matemaatilisi operatsioone nende väljade väärtustega, saame eraldusvõime. 1920 x 1080 saab esitada pic_width_in_mbs_minus_1 väärtusega 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Jällegi, ruumi kokkuhoidmiseks, tehti see 119 asemel 1920.

Kui jätkata meie loodud video kontrollimist binaarselt (nt: xxd -b -c 11 v/minimal_yuv420.h264), võime liikuda viimase NAL-i juurde, mis on kaader ise.

Siin näeme selle esimesi 6 baidi väärtusi: 01100101 10001000 10000100 00000000 00100001 11111111. Kuna on teada, et esimene bait näitab NAL tüüpi, siis antud juhul (00101) on see IDR fragment (5), seega saame edasi uurida:

Kasutades spetsifikatsiooni teavet, suudame dekodeerida fragmendi tüübi (slice_type) ja kaadri numbri (frame_num) koos teiste oluliste väljadega.

Teatud väli väärtuste saamiseks (ue(v), me(v), se(v) või %Kuupäev(v)), peame dekodeerima fragmendi, kasutades spetsiaalset dekoodrit, mis põhineb Golombi eksponentsiaalne kood. See meetod on väga efektiivne muutujate väärtuste kodeerimisel, eriti kui on palju vaikeväärtusi.

Väärtused slice_type ja frame_num selle video jaoks on vastavalt 7 (I-fragment) ja 0 (esimene kaader).

Bitsükkel võib olla protokollina. Kui soovite rohkem teada bitsükli kohta, tasub vaadata spetsifikatsiooni ITU H.264. Siin on makroskeem, mis näitab, kus asuvad pildandmed (YUV kokkusurutud kujul).

Saate uurida ka teisi bitsükleid, nagu , mis on toetatud umbes ¾ browsereid (sealhulgas mobiilseadmeid)., H.265 (HEVC) või isegi meie uut parimat bitsüklit AV1. Kas kõik need on sarnased? Ei, kuid kui teate vähemalt ühte — on palju lihtsam mõista teisi.

Kas soovite praktiseerida? Uurige H.264 bitsüklit

Saate genereerida ühekaadrilise video ja kasutada MediaInfo bitsükli uurimiseks H.264. Tegelikult ei takista miski ka vaadata allika koodi, mis analüüsib bitsüklit H.264 (AVC).

Praktikaks võib kasutada Intel Video Pro Analyzerit (ma juba mainisin, et programm on tasuline, kuid on tasuta prooviversioon, millel on 10 kaadri piirang?).

Ülevaade

Oluline on märkida, et paljud tänapäeva koodekid kasutavad sama mudelit, mida just õppisime. Vaatame koodeki vooskeemi Thor. See sisaldab kõiki samme, mida me oleme läbinud. Selle märkuse mõte on, et te oleksite vähemalt paremini teadlikud uuendustest ja dokumentatsioonist selles valdkonnas.

Varasemalt arvutasime, et ühe tunni kestva video faili hoidmiseks kvaliteedis 720p ja 30 kaadrit sekundis on vajalik 139 GB kettaruumi. Kui kasutada artiklis käsitletud meetodeid (vahekaadri ja siseprognoosid, muundamine, kvantimine, entropiakodeerimine jne), siis on võimalik saavutada (eeldades, et kasutame 0,031 bitti pikseli kohta) täiesti rahuldava kvaliteediga video, mis võtab vaid 367,82 MB, mitte 139 GB mälu.

Kuidas H.265 saavutab parema kokkusurumise määra kui H.264?

Nüüd, kui on teada rohkem koodekite tööpõhimõtetest, on lihtsam mõista, kuidas uued koodekid suudavad pakkuda kõrgemat resolutsiooni vähemate bittidega.

Kui võrrelda AVC ja HEVC, tasub meeles pidada, et see on peaaegu alati valik suurema koormuse ja kokkusurumise määra vahel.

HEVC omab rohkem jaotisi (ja alajaotisi) kui AVC, rohkem sisemise prognoosimise suundi, täiustatud entropiakodeerimine ja palju muud. Kõik need täiustused on teinud H.265 suuteline tihendama 50% rohkem kui H.264.

Esimene osa: Videote ja piltide töötamise alused

Allikas: habr.com