K první části:
Co je? Video kodek je část softwaru/hardwaru, která komprimuje a/nebo dekomprimuje digitální video.
Za co? Přes určitá omezení jak z hlediska šířky pásma, tak i
a pokud jde o prostor pro ukládání dat, trh vyžaduje stále vyšší kvalitu videa. Pamatujete si, jak jsme v minulém příspěvku počítali požadované minimum pro 30 snímků za sekundu, 24 bitů na pixel, s rozlišením 480x240? Přijímali jsme 82,944 Mbit/s bez komprese. Komprese je v současnosti jediným způsobem, jak obecně přenášet HD/FullHD/4K na televizní obrazovky a internet. Jak je toho dosaženo? Nyní se krátce podíváme na hlavní metody.
Překlad byl vytvořen s podporou EDISON Software.Jsme zasnoubeni a .
Kodek vs kontejner
Častou chybou nováčků je záměna kodeku digitálního videa a kontejneru digitálního videa. Kontejner je určitý formát. Obálka obsahující video (a možná i zvuk) metadata. Komprimované video lze považovat za užitečné zatížení kontejneru.
Přípona souboru videa obvykle označuje typ kontejneru. Například soubor video.mp4 je pravděpodobně kontejner MPEG-4 Část 14a soubor s názvem video.mkv je s největší pravděpodobností . Chcete-li si být zcela jisti formátem kodeku a kontejneru, můžete použít nebo .
Trocha historie
Než se dostaneme k Jak?, pojďme se trochu ponořit do historie, abychom trochu lépe porozuměli některým starším kodekům.
Video kodek H.261 se objevil v roce 1990 (technicky - v roce 1988) a byl vytvořen pro provoz s rychlostí přenosu dat 64 Kbps. Již používalo nápady, jako je podvzorkování barev, makrobloky atd. Standard video kodeků byl zveřejněn v roce 1995 H.263který se vyvíjel do roku 2001.
První verze byla dokončena v roce 2003 H.264 / AVC. Téhož roku společnost TrueMotion vydala svůj bezplatný ztrátový video kodek s názvem VP3. Google koupil společnost v roce 2008 a vydal VP8 ve stejném roce. V prosinci 2012 společnost Google vydala VP9a je podporován na přibližně ¾ trhu prohlížečů (včetně mobilních zařízení).
AV1 je nový bezplatný a open source video kodek vyvinutý společností Aliance pro otevřená média (AOMedia), která zahrnuje nejznámější společnosti, jako jsou: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel a Cisco. První verze kodeku, 0.1.0, byla zveřejněna 7. dubna 2016.
Narození AV1
Na začátku roku 2015 na tom Google pracoval VP10Xiph (který je ve vlastnictví Mozilly) pracoval na Daalaa Cisco vytvořilo svůj vlastní bezplatný video kodek s názvem Thor.
pak MPEG LA poprvé oznámené roční limity pro HEVC (H.265) a poplatek 8x vyšší než za H.264, ale brzy opět změnili pravidla:
žádný roční limit,
poplatek za obsah (0,5 % z příjmů) a
jednotkový poplatek je asi 10krát vyšší než u H.264.
Aliance pro otevřená média byl vytvořen společnostmi z různých oblastí: výrobci zařízení (Intel, AMD, ARM, Nvidia, Cisco), poskytovatelé obsahu (Google, Netflix, Amazon), tvůrci prohlížečů (Google, Mozilla) a další.
Společnosti měly společný cíl – bezplatný video kodek. Poté se objeví AV1 s mnohem jednodušší patentovou licencí. Timothy B. Terryberry předvedl úžasnou prezentaci, která se stala původem současného konceptu AV1 a jeho licenčního modelu.
Budete překvapeni, že můžete analyzovat kodek AV1 prostřednictvím prohlížeče (zájemci mohou přejít na).
Univerzální kodek
Podívejme se na hlavní mechanismy, které jsou základem univerzálního video kodeku. Většina těchto pojmů je užitečná a používá se v moderních kodecích jako např VP9, AV1 и HEVC. Varuji vás, že mnoho vysvětlených věcí bude zjednodušeno. Někdy budou k demonstraci technologií použity příklady ze skutečného světa (jako u H.264).
1. krok – rozdělení obrázku
Prvním krokem je rozdělení rámu na několik sekcí, podsekcí a dále.
Proč? Důvodů je mnoho. Když obraz rozdělíme, můžeme přesněji předpovědět pohybový vektor použitím malých částí pro malé pohyblivé části. Zatímco u statického pozadí se můžete omezit na větší úseky.
Kodeky obvykle organizují tyto sekce do sekcí (nebo kousků), makrobloků (nebo bloků kódovacího stromu) a více podsekcí. Maximální velikost těchto oddílů se liší, HEVC ji nastaví na 64x64, zatímco AVC používá 16x16, a pododdíly lze rozdělit až na velikosti 4x4.
Pamatujete si typy rámů z minulého článku?! Totéž lze aplikovat na bloky, takže můžeme mít I-fragment, B-blok, P-makroblok atd.
Pro ty, kteří si chtějí procvičit, sledujte, jak je obrázek rozdělen na sekce a podsekce. K tomu můžete použít již zmíněný v předchozím článku. (ta, která je placená, ale s bezplatnou zkušební verzí, která je omezena na prvních 10 snímků). Zde analyzované sekce VP9:
2. krok – prognózování
Jakmile budeme mít oddíly, můžeme pro ně dělat astrologické předpovědi. Pro Předpovědi INTER musí být převedeny vektory pohybu a zbytek a pro předpovědi INTRA je vysílán směr předpovědi a zbytek.
3. krok – transformace
Jakmile máme zbytkový blok (predikovaný řez → skutečný řez), je možné jej transformovat tak, abychom věděli, které pixely lze vyřadit při zachování celkové kvality. Existují některé transformace, které poskytují přesné chování.
I když existují i jiné metody, podívejme se na ně podrobněji. diskrétní kosinusová transformace (DCT - z diskrétní kosinusová transformace). Hlavní funkce DCT:
- Převádí bloky pixelů na stejně velké bloky frekvenčních koeficientů.
- Kondenzuje energii a pomáhá eliminovat prostorovou redundanci.
- Poskytuje reverzibilitu.
2. února 2017 Sintra R.J. (Cintra, RJ) a Bayer F.M. (Bayer FM) publikoval článek o transformaci podobné DCT pro kompresi obrazu, která vyžaduje pouze 14 dodatků.
Nedělejte si starosti, pokud nerozumíte výhodám každého bodu. Nyní se podívejme na konkrétní příklady, abychom viděli jejich skutečnou hodnotu.
Vezměme tento blok 8x8 pixelů:
Tento blok je vykreslen do následujícího obrázku 8 x 8 pixelů:
Aplikujte DCT na tento blok pixelů a získejte blok 8x8 koeficientů:
A pokud vykreslíme tento blok koeficientů, dostaneme následující obrázek:
Jak vidíte, nevypadá jako původní obrázek. Můžete vidět, že první koeficient je velmi odlišný od všech ostatních. Tento první koeficient je známý jako DC koeficient, který představuje všechny vzorky ve vstupním poli, něco jako průměr.
Tento blok koeficientů má zajímavou vlastnost: odděluje vysokofrekvenční složky od nízkofrekvenčních.
V obraze je většina výkonu soustředěna na nižších frekvencích, takže pokud převedete obraz na jeho frekvenční složky a zahodíte vyšší frekvenční koeficienty, můžete snížit množství dat potřebných k popisu obrazu, aniž byste obětovali příliš mnoho kvality obrazu.
Frekvence označuje, jak rychle se signál mění.
Zkusme aplikovat poznatky získané v testovacím případě převedením původního obrázku na jeho frekvenci (blok koeficientů) pomocí DCT a následným vyřazením části nejméně důležitých koeficientů.
Nejprve jej převedeme do frekvenční oblasti.
Dále vyřadíme část (67 %) koeficientů, především pravou dolní část.
Nakonec z tohoto vyřazeného bloku koeficientů zrekonstruujeme obraz (nezapomeňte, že musí být invertibilní) a porovnáme jej s originálem.
Vidíme, že se podobá původnímu obrázku, ale je zde mnoho rozdílů od originálu. Vyhodili jsme 67,1875 % a stále jsme dostali něco, co se podobalo originálu. Bylo možné promyšleněji vyřadit koeficienty pro získání obrazu ještě lepší kvality, ale to je další téma.
Každý koeficient je generován pomocí všech pixelů
Důležité: každý koeficient není přímo mapován na jeden pixel, ale je váženým součtem všech pixelů. Tento úžasný graf ukazuje, jak se první a druhý koeficient vypočítávají pomocí vah jedinečných pro každý index.
Můžete se také pokusit vizualizovat DCT tak, že se podíváte na jednoduchý obrazový útvar založený na něm. Zde je například symbol A vygenerovaný pomocí každé váhy koeficientu:
4. krok - kvantování
Poté, co v předchozím kroku vyhodíme některé koeficienty, v posledním kroku (transformaci) provedeme speciální formu kvantování. V této fázi je přijatelné ztratit informace. Nebo jednodušeji, budeme kvantovat koeficienty, abychom dosáhli komprese.
Jak můžete kvantovat blok koeficientů? Jednou z nejjednodušších metod je jednotné kvantování, kdy vezmeme blok, vydělíme ho jednou hodnotou (10) a výsledek zaokrouhlíme.
Můžeme tento blok koeficientů obrátit? Ano, můžeme, vynásobením stejnou hodnotou, kterou jsme dělili.
Tento přístup není nejlepší, protože nebere v úvahu důležitost každého koeficientu. Dalo by se použít matici kvantizátorů místo jedné hodnoty a tato matice by mohla využívat vlastnost DCT kvantováním většiny vpravo dole a menšiny vlevo nahoře.
Krok 5 - entropické kódování
Jakmile jsme kvantovali data (bloky obrázků, fragmenty, snímky), můžeme je stále bezeztrátově komprimovat. Existuje mnoho algoritmických způsobů, jak komprimovat data. Na některé z nich se rychle podíváme, pro hlubší pochopení si můžete přečíst knihu Understanding Compression: Data Compression for Modern Developers ("").
Video kódování pomocí VLC
Řekněme, že máme proud postav: a, e, r и t. V této tabulce je uvedena pravděpodobnost (v rozsahu od 0 do 1), jak často se jednotlivé znaky objevují v proudu.
| a | e | r | t | |
|---|---|---|---|---|
| Pravděpodobnost | 0,3 | 0,3 | 0,2 | 0,2 |
K těm nejpravděpodobnějším můžeme přiřadit unikátní binární kódy (nejlépe malé), k těm méně pravděpodobným pak větší kódy.
| a | e | r | t | |
|---|---|---|---|---|
| Pravděpodobnost | 0,3 | 0,3 | 0,2 | 0,2 |
| Binární kód | 0 | 10 | 110 | 1110 |
Proud komprimujeme za předpokladu, že nakonec utratíme 8 bitů za každý znak. Bez komprese by bylo potřeba 24 bitů na znak. Pokud nahradíte každý znak jeho kódem, získáte úspory!
Prvním krokem je zakódování znaku e, což se rovná 10, a druhý znak je a, který je přidán (nikoli matematickým způsobem): [10][0] a nakonec třetí znak t, což činí náš konečný komprimovaný bitový tok roven [10][0][1110] nebo 1001110, který vyžaduje pouze 7 bitů (3,4krát méně místa než originál).
Upozorňujeme, že každý kód musí být jedinečný kód s předponou. vám pomůže tato čísla najít. Ačkoli tato metoda není bez nedostatků, existují video kodeky, které tuto algoritmickou metodu komprese stále nabízejí.
Jak kodér, tak dekodér musí mít přístup k tabulce symbolů se svými binárními kódy. Proto je také nutné odeslat tabulku jako vstup.
Aritmetické kódování
Řekněme, že máme proud postav: a, e, r, s и ta jejich pravděpodobnost je uvedena v této tabulce.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Pravděpodobnost | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Pomocí této tabulky vytvoříme rozsahy obsahující všechny možné znaky seřazené podle největšího čísla.
Nyní zakódujme proud tří znaků: jíst.
Nejprve vyberte první znak e, který je v podrozsahu od 0,3 do 0,6 (nezahrnuje). Vezmeme tento podrozsah a znovu ho rozdělíme ve stejných poměrech jako předtím, ale pro tento nový rozsah.
Pokračujme v kódování našeho streamu jíst. Nyní vezměte druhou postavu a, který je v novém podrozsahu od 0,3 do 0,39, a poté vezměte náš poslední znak t a opakováním stejného procesu znovu dostaneme konečný dílčí rozsah od 0,354 do 0,372.
Potřebujeme vybrat číslo v posledním podrozsahu od 0,354 do 0,372. Zvolme 0,36 (ale můžete si vybrat jakékoli jiné číslo v tomto podrozsahu). Pouze s tímto číslem budeme schopni obnovit náš původní stream. Je to, jako bychom nakreslili čáru v rámci rozsahů, abychom zakódovali náš proud.
Opačná operace (tj. dekódování) je stejně jednoduché: s naším číslem 0,36 a naším počátečním rozsahem můžeme spustit stejný proces. Nyní však pomocí tohoto čísla identifikujeme proud zakódovaný pomocí tohoto čísla.
U prvního rozsahu si všimneme, že naše číslo odpovídá řezu, proto je to náš první znak. Nyní tento podrozsah znovu rozdělíme stejným postupem jako dříve. Zde vidíte, že 0,36 odpovídá symbolu a, a po zopakování procesu jsme dospěli k poslednímu znaku t (vytvářející náš původní kódovaný stream jíst).
Kodér i dekodér musí mít tabulku pravděpodobností symbolů, je tedy nutné ji posílat i ve vstupních datech.
Docela elegantní, že? Kdo přišel s tímto řešením, byl zatraceně chytrý. Některé video kodeky tuto techniku používají (nebo ji alespoň nabízejí jako možnost).
Cílem je bezeztrátově komprimovat kvantovaný bitový tok. V tomto článku jistě chybí spousta podrobností, důvodů, kompromisů atd. Ale pokud jste vývojář, měli byste vědět více. Nové kodeky se snaží používat různé entropické kódovací algoritmy jako např LET.
Krok 6 – formát bitového toku
Po provedení tohoto všeho zbývá pouze rozbalit komprimované snímky v kontextu provedených kroků. Dekodér musí být výslovně informován o rozhodnutích učiněných kodérem. Dekodér musí být vybaven všemi potřebnými informacemi: bitová hloubka, barevný prostor, rozlišení, predikční informace (vektory pohybu, směrová INTER predikce), profil, úroveň, snímková frekvence, typ snímku, číslo snímku a mnoho dalšího.
Rychle se podíváme na bitstream H.264. Naším prvním krokem je vytvoření minimálního bitového toku H.264 (FFmpeg ve výchozím nastavení přidává všechny možnosti kódování, jako je SEI NAL - co to je, zjistíme o něco dále). Můžeme to udělat pomocí našeho vlastního úložiště a FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Tento příkaz vygeneruje nezpracovaný bitstream H.264 s jedním rámečkem, rozlišením 64×64, s barevným prostorem YUV420. V tomto případě je jako rámeček použit následující obrázek.
Bitový tok H.264
Standardní AVC (H.264) určuje, že informace budou odesílány v makrorámcích (ve smyslu sítě), tzv nal (toto je úroveň abstrakce sítě). Hlavním cílem NAL je poskytovat „web-friendly“ videoprezentaci. Tento standard by měl fungovat na televizorech (založený na streamu), internetu (založený na paketech).
Existuje synchronizační značka, která definuje hranice prvků NAL. Každý synchronizační token obsahuje hodnotu 0x00 0x00 0x01, kromě úplně prvního, který se rovná 0x00 0x00 0x00 0x01. Pokud spustíme hexdump pro generovaný bitový tok H.264 identifikujeme alespoň tři vzory NAL na začátku souboru.
Jak bylo řečeno, dekodér musí znát nejen obrazová data, ale také detaily videa, snímek, barvy, použité parametry a mnoho dalšího. První bajt každého NAL definuje jeho kategorii a typ.
| Identifikátor typu NAL | popis |
|---|---|
| 0 | Neznámý typ |
| 1 | Kódovaný fragment obrázku bez IDR |
| 2 | Kódovaná datová sekce řezu A |
| 3 | Kódovaná datová sekce řezu B |
| 4 | Kódovaná datová sekce řezu C |
| 5 | Kódovaný fragment IDR obrazu IDR |
| 6 | Další informace o rozšíření SEI |
| 7 | Sada parametrů sekvence SPS |
| 8 | Sada parametrů obrazu PPS |
| 9 | Přístupový oddělovač |
| 10 | Konec sekvence |
| 11 | Konec vlákna |
| ... | ... |
Typicky je první NAL bitového toku PLC. Tento typ NAL je zodpovědný za informování o běžných proměnných kódování, jako je profil, úroveň, rozlišení atd.
Pokud přeskočíme první synchronizační značku, můžeme dekódovat první bajt, abychom zjistili, který typ NAL je první.
Například první bajt po synchronizačním tokenu je 01100111, kde je první bit (0) je v poli forbidden_zero_bit. Další 2 bity (11) nám říká pole nal_ref_idc, což udává, zda je tento NAL referenčním polem nebo ne. A zbývajících 5 bitů (00111) nám říká pole typ_nal_unit_type, v tomto případě se jedná o blok SPS (7) NAL.
Druhý bajt (dvojitý=01100100, hex=0x64, prosince=100) v SPS NAL je pole profile_idc, který ukazuje profil, který kodér použil. V tomto případě byl použit omezený vysoký profil (tj. vysoký profil bez obousměrné podpory B-segmentu).
Když se podíváte na specifikaci bitstreamu H.264 pro SPS NAL najdeme mnoho hodnot pro název parametru, kategorii a popis. Podívejme se například na pole pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Název parametru | kategorie | popis |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Pokud s hodnotami těchto polí provedeme nějaké matematické operace, získáme rozlišení. Jeden může reprezentovat 1920 x 1080 pomocí pic_width_in_mbs_minus_1 s hodnotou 119 ((119 + 1) * velikost_makrobloku = 120 * 16 = 1920). Opět, abychom ušetřili místo, místo kódování 1920 jsme to udělali s 119.
Pokud budeme pokračovat v kontrole našeho vytvořeného videa v binární podobě (například: xxd -b -c 11 v/minimal_yuv420.h264), pak můžete přejít na poslední NAL, což je samotný rám.
Zde vidíme jeho prvních 6 bajtových hodnot: 01100101 10001000 10000100 00000000 00100001 11111111. Protože je známo, že první bajt označuje typ NAL, v tomto případě (00101) je fragment IDR (5) a pak jej můžete dále prozkoumat:
Pomocí informací o specifikaci bude možné dekódovat typ fragmentu (slice_type) a číslo snímku (číslo_rámce) mimo jiné důležité obory.
Chcete-li získat hodnoty některých polí (ue(v), me(v), se(v) Nebo te(v)), musíme fragment dekódovat pomocí speciálního dekodéru založeného na . Tato metoda je velmi účinná pro kódování hodnot proměnných, zvláště když existuje mnoho výchozích hodnot.
Hodnoty slice_type и číslo_rámce tohoto videa je 7 (I-fragment) a 0 (první snímek).
Bitový tok lze považovat za protokol. Pokud se chcete dozvědět více o bitstreamu, měli byste se podívat na specifikaci ITU H.264. Zde je makro diagram ukazující, kde jsou obrazová data (YUV v komprimované formě).
Lze zkoumat další bitstreamy, jako např VP9, H.265 (HEVC) nebo dokonce náš nový nejlepší bitstream AV1. Jsou si všechny podobné? Ne, ale jakmile pochopíte alespoň jeden, je mnohem snazší porozumět zbytku.
Chcete cvičit? Prozkoumejte bitový tok H.264
Můžete vygenerovat jeden snímek videa a použít MediaInfo k prozkoumání bitového proudu H.264. Ve skutečnosti vám nic nebrání se dokonce podívat na zdrojový kód, který analyzuje bitový tok H.264 (AVC).
Pro praxi můžete použít Intel Video Pro Analyzer (už jsem řekl, že program je placený, ale existuje bezplatná zkušební verze s limitem 10 snímků?).
Recenze
Všimněte si, že mnoho moderních kodeků používá stejný model, který jsme právě studovali. Zde se podívejme na blokové schéma video kodeku Thor. Obsahuje všechny kroky, kterými jsme prošli. Smyslem tohoto příspěvku je alespoň lépe porozumět inovacím a dokumentaci v této oblasti.
Dříve se počítalo s tím, že pro uložení videosouboru o délce jedné hodiny v kvalitě 139p a 720 fps bude potřeba 30 GB místa na disku. Pokud použijete metody popsané v tomto článku (mezirámcové a interní predikce, transformace, kvantizace, entropické kódování atd.), můžete dosáhnout (na základě skutečnosti, že utratíme 0,031 bitů na pixel), videa uspokojivá kvalita, zabírá pouze 367,82 MB, nikoli 139 GB paměti.
Jak H.265 dosahuje lepšího kompresního poměru než H.264?
Nyní, když víme více o tom, jak kodeky fungují, je snazší pochopit, jak mohou novější kodeky poskytovat vyšší rozlišení s menším počtem bitů.
Pokud srovnáte AVC и HEVC, je třeba připomenout, že se téměř vždy jedná o volbu mezi větší zátěží CPU a kompresním poměrem.
HEVC má více možností sekce (a podsekce) než AVC, více směrů vnitřní predikce, vylepšené kódování entropie a další. Všechna tato vylepšení byla provedena H.265 schopný stlačit o 50 % více než H.264.
K první části:
Zdroj: www.habr.com