Prvá časť:
Čo je? Video kodek je softvér/hardvér, ktorý komprimuje a/alebo dekomprimuje digitálne video.
Za čo? Napriek určitým obmedzeniam ako z hľadiska šírky pásma, tak aj
a pokiaľ ide o priestor na ukladanie dát, trh vyžaduje čoraz vyššiu kvalitu videa. Pamätáte si, ako sme v minulom príspevku vypočítali požadované minimum pre 30 snímok za sekundu, 24 bitov na pixel, s rozlíšením 480 x 240? Bez kompresie sme dostali 82,944 Mbit/s. Kompresia je v súčasnosti jediným spôsobom, ako vo všeobecnosti prenášať HD/FullHD/4K na televízne obrazovky a internet. Ako sa to dosiahne? Teraz sa stručne pozrime na hlavné metódy.
Preklad bol vyhotovený s podporou EDISON Software.Sme zasnúbení a .
Kodek vs kontajner
Bežnou chybou nováčikov je zamieňanie kodeku digitálneho videa a kontajnera digitálneho videa. Kontajner je určitý formát. Obal obsahujúci video (a možno aj audio) metadáta. Komprimované video možno považovať za užitočné zaťaženie kontajnera.
Prípona video súboru zvyčajne označuje jeho typ kontajnera. Napríklad súbor video.mp4 je pravdepodobne kontajner MPEG-4 časť 14a súbor s názvom video.mkv je s najväčšou pravdepodobnosťou . Aby ste si boli úplne istí formátom kodeku a kontajnera, môžete použiť alebo .
Trocha histórie
Než sa dostaneme k Ako?, poďme sa trochu ponoriť do histórie, aby sme trochu lepšie porozumeli niektorým starším kodekom.
Video kodek H.261 sa objavil v roku 1990 (technicky - v roku 1988) a bol vytvorený na prevádzku pri rýchlosti prenosu dát 64 Kbps. Už využívala nápady ako podvzorkovanie farieb, makrobloky atď. Štandard video kodekov bol publikovaný v roku 1995 H.263, ktorý sa vyvíjal do roku 2001.
Prvá verzia bola dokončená v roku 2003 H.264 / AVC. V tom istom roku spoločnosť TrueMotion vydala svoj bezplatný stratový video kodek s názvom VP3. Google kúpil spoločnosť v roku 2008 a vydal VP8 toho istého roku. V decembri 2012 spoločnosť Google vydala VP9a je podporovaný na približne ¾ trhu prehliadačov (vrátane mobilných zariadení).
AV1 je nový bezplatný a open source video kodek vyvinutý spoločnosťou Aliancia pre otvorené médiá (AOMedia), ktorá zahŕňa najznámejšie spoločnosti, ako sú: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel a Cisco. Prvá verzia kodeku, 0.1.0, bola zverejnená 7. apríla 2016.
Narodenie AV1
Začiatkom roka 2015 na tom Google pracoval VP10Xiph (ktorý vlastní Mozilla) pracoval na daleja Cisco vytvorilo svoj vlastný bezplatný video kodek s názvom Thor.
Potom MPEG LA prvýkrát oznámené ročné limity pre HEVC (H.265) a poplatok 8x vyšší ako za H.264, no čoskoro opäť zmenili pravidlá:
žiadny ročný limit,
poplatok za obsah (0,5 % z príjmov) a
jednotkový poplatok je asi 10-krát vyšší ako H.264.
Aliancia pre otvorené médiá bol vytvorený spoločnosťami z rôznych oblastí: výrobcovia zariadení (Intel, AMD, ARM, Nvidia, Cisco), poskytovatelia obsahu (Google, Netflix, Amazon), tvorcovia prehliadačov (Google, Mozilla) a ďalší.
Spoločnosti mali spoločný cieľ – bezplatný video kodek. Potom sa objaví AV1 s oveľa jednoduchšou patentovou licenciou. Timothy B. Terryberry predviedol úžasnú prezentáciu, ktorá sa stala pôvodom súčasného konceptu AV1 a jeho licenčného modelu.
Budete prekvapení, keď viete, že kodek AV1 môžete analyzovať prostredníctvom prehliadača (záujemcovia môžu prejsť na).
Univerzálny kodek
Pozrime sa na hlavné mechanizmy, ktoré sú základom univerzálneho video kodeku. Väčšina z týchto konceptov je užitočná a používa sa v moderných kodekoch ako napr VP9, AV1 и HEVC. Upozorňujem, že mnohé z vysvetlených vecí budú zjednodušené. Niekedy sa na demonštráciu technológie použijú príklady z reálneho sveta (napríklad H.264).
1. krok – rozdelenie obrázka
Prvým krokom je rozdelenie rámu na niekoľko sekcií, podsekcií a ďalej.
Prečo? Dôvodov je veľa. Keď rozdelíme obrázok, môžeme presnejšie predpovedať pohybový vektor pomocou malých častí pre malé pohyblivé časti. Zatiaľ čo pri statickom pozadí sa môžete obmedziť na väčšie úseky.
Kodeky zvyčajne organizujú tieto sekcie do sekcií (alebo kúskov), makroblokov (alebo blokov kódovacieho stromu) a viacerých podsekcií. Maximálna veľkosť týchto oddielov sa líši, HEVC ju nastaví na 64x64, zatiaľ čo AVC používa 16x16 a pododdiely možno rozdeliť až na veľkosti 4x4.
Pamätáte si typy rámov z minulého článku?! To isté možno aplikovať na bloky, takže môžeme mať I-fragment, B-blok, P-makroblok atď.
Pre tých, ktorí chcú cvičiť, sledujte, ako je obrázok rozdelený na sekcie a podsekcie. Na to môžete použiť ten, ktorý už bol spomenutý v predchádzajúcom článku. (ten, ktorý je platený, ale s bezplatnou skúšobnou verziou, ktorá je obmedzená na prvých 10 snímok). Tu sú analyzované sekcie VP9:
2. krok – prognózovanie
Keď máme sekcie, môžeme im robiť astrologické predpovede. Pre predpovede INTER musí byť prenesená vektory pohybu a zvyšok a pre predpovedanie INTRA sa prenáša smer predpovede a zvyšok.
3. krok – transformácia
Keď už máme zvyškový blok (predpovedaný úsek → skutočný úsek), je možné ho transformovať tak, aby sme vedeli, ktoré pixely je možné zahodiť pri zachovaní celkovej kvality. Existuje niekoľko transformácií, ktoré poskytujú presné správanie.
Hoci existujú aj iné metódy, pozrime sa na ne podrobnejšie. diskrétna kosínusová transformácia (DCT - z diskrétna kosínusová transformácia). Hlavné funkcie DCT:
- Konvertuje bloky pixelov na rovnako veľké bloky frekvenčných koeficientov.
- Kondenzuje energiu, aby pomohla eliminovať priestorovú redundanciu.
- Poskytuje reverzibilitu.
2. februára 2017 Sintra R.J. (Cintra, RJ) a Bayer F.M. (Bayer FM) publikoval článok o transformácii podobnej DCT pre kompresiu obrazu, ktorá vyžaduje iba 14 dodatkov.
Nerobte si starosti, ak nerozumiete výhodám každej položky. Teraz poďme použiť konkrétne príklady, aby sme videli ich skutočnú hodnotu.
Zoberme si tento blok 8x8 pixelov:
Tento blok je vykreslený do nasledujúceho obrázka s rozmermi 8 x 8 pixelov:
Aplikujte DCT na tento blok pixelov a získajte blok 8x8 koeficientov:
A ak vykreslíme tento blok koeficientov, dostaneme nasledujúci obrázok:
Ako vidíte, nevyzerá to ako pôvodný obrázok. Môžete vidieť, že prvý koeficient je veľmi odlišný od všetkých ostatných. Tento prvý koeficient je známy ako DC koeficient, ktorý predstavuje všetky vzorky vo vstupnom poli, niečo ako priemer.
Tento blok koeficientov má zaujímavú vlastnosť: oddeľuje vysokofrekvenčné zložky od nízkofrekvenčných.
V obraze je väčšina výkonu sústredená pri nižších frekvenciách, takže ak prevediete obraz na jeho frekvenčné zložky a zahodíte vyššie frekvenčné koeficienty, môžete znížiť množstvo údajov potrebných na popis obrazu bez toho, aby ste obetovali príliš veľa kvality obrazu.
Frekvencia označuje, ako rýchlo sa signál mení.
Skúsme aplikovať poznatky získané v testovacom prípade prevedením pôvodného obrázku na jeho frekvenciu (blok koeficientov) pomocou DCT a následným vyradením časti najmenej dôležitých koeficientov.
Najprv ho prevedieme do frekvenčnej oblasti.
Ďalej vyradíme časť (67 %) koeficientov, hlavne pravú dolnú časť.
Nakoniec z tohto vyradeného bloku koeficientov zrekonštruujeme obraz (nezabudnite, že musí byť invertovateľný) a porovnáme ho s originálom.
Vidíme, že sa podobá na pôvodný obrázok, no oproti originálu je veľa rozdielov. Vyhodili sme 67,1875 % a stále sme dostali niečo, čo sa podobalo originálu. Bolo možné premyslenejšie vyradiť koeficienty, aby sme získali obraz ešte lepšej kvality, ale to je ďalšia téma.
Každý koeficient sa generuje pomocou všetkých pixelov
Dôležité: každý koeficient nie je priamo mapovaný na jeden pixel, ale je váženým súčtom všetkých pixelov. Tento úžasný graf ukazuje, ako sa prvý a druhý koeficient vypočítavajú pomocou váh jedinečných pre každý index.
Môžete sa tiež pokúsiť vizualizovať DCT tak, že sa pozriete na jednoduchú formáciu obrazu, ktorá je na nej založená. Tu je napríklad symbol A vygenerovaný pomocou každej váhy koeficientu:
4. krok - kvantovanie
Keď v predchádzajúcom kroku vyhodíme nejaké koeficienty, v poslednom kroku (transformácia) vykonáme špeciálnu formu kvantovania. V tejto fáze je prijateľné stratiť informácie. Alebo, jednoduchšie, budeme kvantovať koeficienty, aby sme dosiahli kompresiu.
Ako môžete kvantovať blok koeficientov? Jednou z najjednoduchších metód je rovnomerné kvantovanie, kedy zoberieme blok, vydelíme ho jednou hodnotou (10) a výsledok zaokrúhlime.
Môžeme obrátiť tento blok koeficientov? Áno, môžeme, vynásobením rovnakou hodnotou, ktorou sme delili.
Tento prístup nie je najlepší, pretože nezohľadňuje dôležitosť každého koeficientu. Dalo by sa použiť maticu kvantizátorov namiesto jednej hodnoty a táto matica by mohla využiť vlastnosť DCT kvantovaním väčšiny vpravo dole a menšiny vľavo hore.
Krok 5 - entropické kódovanie
Po kvantovaní údajov (bloky obrázkov, fragmenty, snímky) ich stále môžeme bezstratovo komprimovať. Existuje mnoho algoritmických spôsobov kompresie údajov. Na niektoré z nich sa rýchlo pozrieme, pre hlbšie pochopenie si môžete prečítať knihu Understanding Compression: Data Compression for Modern Developers ("").
Kódovanie videa pomocou VLC
Povedzme, že máme prúd postáv: a, e, r и t. V tejto tabuľke je uvedená pravdepodobnosť (v rozsahu od 0 do 1), ako často sa jednotlivé znaky vyskytujú v streame.
| a | e | r | t | |
|---|---|---|---|---|
| Pravdepodobnosť | 0,3 | 0,3 | 0,2 | 0,2 |
K tým najpravdepodobnejším môžeme priradiť jedinečné binárne kódy (najlepšie malé) a k tým menej pravdepodobným väčšie kódy.
| a | e | r | t | |
|---|---|---|---|---|
| Pravdepodobnosť | 0,3 | 0,3 | 0,2 | 0,2 |
| Binárny kód | 0 | 10 | 110 | 1110 |
Komprimujeme stream za predpokladu, že nakoniec minieme 8 bitov na každý znak. Bez kompresie by bolo potrebných 24 bitov na znak. Ak nahradíte každý znak jeho kódom, ušetríte!
Prvým krokom je zakódovanie znaku e, čo sa rovná 10, a druhý znak je a, ktorý sa pridáva (nie matematickým spôsobom): [10][0] a nakoniec tretí znak t, čo robí náš konečný komprimovaný bitový tok rovný [10][0][1110] alebo 1001110, ktorý vyžaduje iba 7 bitov (3,4-krát menej miesta ako originál).
Upozorňujeme, že každý kód musí byť jedinečný kód s predponou. vám pomôže nájsť tieto čísla. Aj keď táto metóda nie je bez nedostatkov, existujú video kodeky, ktoré stále ponúkajú túto algoritmickú metódu kompresie.
Kódovač aj dekodér musia mať prístup k tabuľke symbolov so svojimi binárnymi kódmi. Preto je potrebné zaslať aj tabuľku ako vstup.
Aritmetické kódovanie
Povedzme, že máme prúd postáv: a, e, r, s и ta ich pravdepodobnosť je uvedená v tejto tabuľke.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Pravdepodobnosť | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Pomocou tejto tabuľky vytvoríme rozsahy obsahujúce všetky možné znaky zoradené podľa najväčšieho čísla.
Teraz zakódujme prúd troch znakov: jesť.
Najprv vyberte prvý znak e, ktorý je v podrozsahu od 0,3 do 0,6 (okrem). Vezmeme tento podrozsah a znova ho rozdelíme v rovnakých pomeroch ako predtým, ale pre tento nový rozsah.
Pokračujme v kódovaní nášho streamu jesť. Teraz vezmite druhú postavu a, ktorý je v novom podrozsahu od 0,3 do 0,39, a potom zoberte náš posledný znak t a opakovaním toho istého procesu znova dostaneme konečný podrozsah od 0,354 do 0,372.
Potrebujeme len vybrať číslo v poslednom podrozsahu od 0,354 do 0,372. Vyberme si 0,36 (ale môžete si vybrať akékoľvek iné číslo v tomto podrozsahu). Iba s týmto číslom budeme môcť obnoviť náš pôvodný stream. Je to ako keby sme nakreslili čiaru v rámci rozsahov, aby sme zakódovali náš stream.
Opačná operácia (tj. dekódovanie) je rovnako jednoduché: s naším číslom 0,36 a naším počiatočným rozsahom môžeme spustiť rovnaký proces. Teraz však pomocou tohto čísla identifikujeme prúd zakódovaný pomocou tohto čísla.
Pri prvom rozsahu si všimneme, že naše číslo zodpovedá rezu, preto je to náš prvý znak. Teraz tento podrozsah opäť rozdelíme podľa rovnakého postupu ako predtým. Tu môžete vidieť, že 0,36 zodpovedá symbolu aa po zopakovaní procesu sme sa dostali k poslednému znaku t (tvorí náš pôvodný kódovaný stream jesť).
Kodér aj dekodér musia mať tabuľku pravdepodobnosti symbolov, preto je potrebné zaslať ju aj vo vstupných dátach.
Celkom elegantné, nie? Ktokoľvek prišiel s týmto riešením, bol sakramentsky šikovný. Niektoré video kodeky používajú túto techniku (alebo ju aspoň ponúkajú ako možnosť).
Cieľom je bezstratovo komprimovať kvantovaný bitový tok. V tomto článku určite chýba veľa podrobností, dôvodov, kompromisov atď. Ale ak ste vývojár, mali by ste vedieť viac. Nové kodeky sa snažia využívať rôzne entropické kódovacie algoritmy ako napr ANS.
Krok 6 - formát bitového toku
Po vykonaní tohto všetkého zostáva len rozbaliť komprimované snímky v kontexte vykonaných krokov. Dekodér musí byť výslovne informovaný o rozhodnutiach, ktoré urobil kodér. Dekodér musí byť vybavený všetkými potrebnými informáciami: bitová hĺbka, farebný priestor, rozlíšenie, predikčné informácie (vektory pohybu, smerová INTER predikcia), profil, úroveň, snímková frekvencia, typ snímky, číslo snímky a mnohé ďalšie.
Rýchlo sa pozrieme na bitstream H.264. Naším prvým krokom je vytvorenie minimálneho bitového toku H.264 (FFmpeg štandardne pridáva všetky možnosti kódovania ako napr. SEI NAL - čo to je, zistíme trochu ďalej). Môžeme to urobiť pomocou nášho vlastného úložiska a FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Tento príkaz vygeneruje nespracovaný bitový tok H.264 s jedným rámom, rozlíšením 64×64, s farebným priestorom YUV420. V tomto prípade je ako rám použitý nasledujúci obrázok.
H.264 bitový tok
Štandardné AVC (H.264) určuje, že informácie sa budú odosielať v makrorámcoch (v sieťovom zmysle), tzv nal (toto je úroveň sieťovej abstrakcie). Hlavným cieľom NAL je poskytnúť „web-friendly“ video prezentáciu. Tento štandard by mal fungovať na televízoroch (založený na streame), na internete (založený na paketoch).
Existuje synchronizačná značka na definovanie hraníc prvkov NAL. Každý synchronizačný token obsahuje hodnotu 0x00 0x00 0x01, okrem úplne prvého, ktorý sa rovná 0x00 0x00 0x00 0x01. Ak spustíme hexdump pre vygenerovaný bitový tok H.264 identifikujeme aspoň tri vzory NAL na začiatku súboru.
Ako bolo uvedené, dekodér musí poznať nielen obrazové údaje, ale aj detaily videa, snímku, farby, použité parametre a mnoho ďalšieho. Prvý bajt každého NAL definuje jeho kategóriu a typ.
| Identifikátor typu NAL | Popis |
|---|---|
| 0 | Neznámy typ |
| 1 | Kódovaný fragment obrázka bez IDR |
| 2 | Sekcia kódovaných údajov rezu A |
| 3 | Sekcia kódovaných údajov rezu B |
| 4 | Sekcia kódovaných údajov rezu C |
| 5 | Kódovaný fragment IDR obrazu IDR |
| 6 | Viac informácií o rozšírení SEI |
| 7 | Sada parametrov sekvencie SPS |
| 8 | Sada parametrov obrazu PPS |
| 9 | Prístupový oddeľovač |
| 10 | Koniec sekvencie |
| 11 | Koniec vlákna |
| ... | ... |
Typicky je prvým NAL bitového toku PLC. Tento typ NAL je zodpovedný za informovanie o bežných premenných kódovania, ako je profil, úroveň, rozlíšenie atď.
Ak preskočíme prvú synchronizačnú značku, môžeme dekódovať prvý bajt, aby sme zistili, ktorý typ NAL je prvý.
Napríklad prvý bajt po synchronizačnom tokene je 01100111, kde je prvý bit (0) je v poli forbidden_zero_bit. Ďalšie 2 bity (11) nám povie pole nal_ref_idc, čo udáva, či je tento NAL referenčným poľom alebo nie. A zvyšných 5 bitov (00111) nám povie pole nal_unit_type, v tomto prípade ide o blok SPS (7) NAL.
Druhý bajt (binárne=01100100, hex=0x64, decembra=100) v SPS NAL je pole profile_idc, ktorý zobrazuje profil, ktorý kódovač použil. V tomto prípade bol použitý obmedzený vysoký profil (tj vysoký profil bez obojsmernej podpory B-segmentu).
Ak sa pozriete na špecifikáciu bitstreamu H.264 pre SPS NAL nájdeme veľa hodnôt pre názov parametra, kategóriu a popis. Pozrime sa napríklad na polia pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Názov parametra | kategórie | Popis |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Ak vykonáme nejaké matematické operácie s hodnotami týchto polí, dostaneme rozlíšenie. Jeden môže reprezentovať 1920 x 1080 pomocou pic_width_in_mbs_minus_1 s hodnotou 119 ((119 + 1) * veľkosť_makrobloku = 120 * 16 = 1920). Opäť, aby sme ušetrili miesto, namiesto kódovania 1920 sme to urobili s 119.
Ak budeme pokračovať v kontrole nášho vytvoreného videa v binárnej forme (napríklad: xxd -b -c 11 v/minimal_yuv420.h264), potom môžete prejsť na posledný NAL, ktorým je samotný rám.
Tu vidíme jeho prvých 6 bajtových hodnôt: 01100101 10001000 10000100 00000000 00100001 11111111. Keďže je známe, že prvý bajt označuje typ NAL, v tomto prípade (00101) je fragment IDR (5) a potom ho môžete ďalej preskúmať:
Pomocou informácií o špecifikácii bude možné dekódovať typ fragmentu (typ_rezu) a číslo snímky (frame_num) okrem iných dôležitých oblastí.
Ak chcete získať hodnoty niektorých polí (ue(v), me(v), se(v) alebo te(v)), musíme fragment dekódovať pomocou špeciálneho dekodéra založeného na . Táto metóda je veľmi efektívna na kódovanie hodnôt premenných, najmä ak existuje veľa predvolených hodnôt.
zmysel typ_rezu и frame_num tohto videa je 7 (I-fragment) a 0 (prvá snímka).
Bitový tok možno považovať za protokol. Ak sa chcete dozvedieť viac o bitovom toku, mali by ste si pozrieť špecifikáciu ITU H.264. Tu je makro diagram znázorňujúci, kde sú obrazové dáta (YUV v komprimovanej forme).
Skúmať možno aj iné bitové toky, ako napr VP9, H.265 (HEVC) alebo dokonca náš nový najlepší bitstream AV1. Sú všetky podobné? Nie, ale keď pochopíte aspoň jeden, je oveľa jednoduchšie pochopiť zvyšok.
Chcete cvičiť? Preskúmajte bitový tok H.264
Môžete vygenerovať jednosnímkové video a použiť MediaInfo na preskúmanie bitového toku H.264. V skutočnosti vám nič nebráni pozrieť sa na zdrojový kód, ktorý analyzuje bitový tok H.264 (AVC).
Pre prax môžete použiť Intel Video Pro Analyzer (už som povedal, že program je platený, ale existuje bezplatná skúšobná verzia s limitom 10 snímok?).
Recenzia
Všimnite si, že mnoho moderných kodekov používa rovnaký model, ktorý sme práve študovali. Tu sa pozrime na blokovú schému video kodeku Thor. Obsahuje všetky kroky, ktorými sme prešli. Cieľom tohto príspevku je aspoň lepšie pochopiť inovácie a dokumentáciu v tejto oblasti.
Predtým sa počítalo, že na uloženie video súboru trvajúceho jednu hodinu v kvalite 139p a 720 fps bude potrebných 30 GB miesta na disku. Ak použijete metódy uvedené v tomto článku (medzisnímkové a interné predpovede, transformácia, kvantovanie, entropické kódovanie atď.), potom môžete dosiahnuť (na základe skutočnosti, že minieme 0,031 bitov na pixel), video s pomerne uspokojivá kvalita, zaberá iba 367,82 MB, nie 139 GB pamäte.
Ako dosahuje H.265 lepší kompresný pomer ako H.264?
Teraz, keď vieme viac o tom, ako kodeky fungujú, je jednoduchšie pochopiť, ako môžu novšie kodeky poskytnúť vyššie rozlíšenie s menším počtom bitov.
Ak porovnáme AVC и HEVC, je potrebné pripomenúť, že takmer vždy ide o voľbu medzi väčším zaťažením procesora a kompresným pomerom.
HEVC má viac možností sekcie (a podsekcie) ako AVC, viac smerov vnútornej predikcie, vylepšené kódovanie entropie a ďalšie. Všetky tieto vylepšenia boli vykonané H.265 schopný stlačiť o 50 % viac ako H.264.
Prvá časť:
Zdroj: hab.com