Az első rész:
Mi van? A videokodek egy olyan szoftver/hardver, amely tömöríti és/vagy kicsomagolja a digitális videót.
Miért? Bizonyos korlátok ellenére mind a sávszélesség, mind a
az adattárhely tekintetében pedig egyre jobb minőségű videót követel a piac. Emlékszel, hogyan számoltuk ki az utolsó bejegyzésben a szükséges minimumot 30 képkocka/másodperc, 24 bit/pixel esetén, 480x240-es felbontás mellett? 82,944 Mbit/s-ot kaptunk tömörítés nélkül. Jelenleg a tömörítés az egyetlen módja a HD/FullHD/4K átvitelének a televízió képernyőjére és az internetre. Hogyan érhető el ez? Most pedig nézzük meg röviden a fő módszereket.
A fordítás az EDISON Software támogatásával készült.Részt veszünk És .
Codec vs Container
Az újoncok gyakori hibája, hogy összekeveri a digitális videokodeket és a digitális videotárolót. A konténer egy bizonyos formátum. Videó (és esetleg hang) metaadatokat tartalmazó burkoló. A tömörített videó konténer hasznos tehernek tekinthető.
Általában a videofájl kiterjesztése jelzi a tároló típusát. Például a video.mp4 fájl valószínűleg egy tároló MPEG-4 14 rész, és a legvalószínűbb egy video.mkv nevű fájl . Ahhoz, hogy teljesen biztos legyen a kodek és tároló formátumban, használhatja vagy .
Egy kis történelem
Mielőtt rátérnénk Hogyan?, vessünk egy kicsit a történelembe, hogy jobban megértsünk néhány régebbi kodeket.
Videokodek H.261 1990-ben jelent meg (technikailag - 1988-ban), és 64 Kb/s adatátviteli sebességre jött létre. Már használt olyan ötleteket, mint a szín almintavétele, makroblokkok stb. A videokodek szabvány 1995-ben jelent meg H.263, amely 2001-ig fejlődött.
Az első verzió 2003-ban készült el H.264 / AVC. Ugyanebben az évben a TrueMotion kiadta ingyenes, veszteséges videokodekjét VP3. A Google 2008-ban vásárolta meg a céget, és kiadta VP8 ugyanabban az évben. 2012 decemberében a Google kiadta VP9, és a böngészőpiac körülbelül ¾-én támogatott (beleértve a mobileszközöket is).
AV1 egy új ingyenes és nyílt forráskódú videokodek, amelyet a Szövetség a nyílt médiáért (AOMedia), amely magában foglalja a leghíresebb cégeket, mint például: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel és Cisco. A kodek első verziója, a 0.1.0 7. április 2016-én jelent meg.
AV1 születése
2015 elején a Google ezen dolgozott VP10A Xiph (amely a Mozilla tulajdona) dolgozott Daala, és a Cisco elkészítette saját ingyenes videokodekjét Thor.
Akkor MPEG LA évre bejelentett éves limitek először HEVC (H.265) és nyolcszor magasabb díj, mint a H.8 esetében, de hamarosan ismét megváltoztatták a szabályokat:
nincs éves limit,
tartalmi díj (a bevétel 0,5%-a), ill
az egységdíj körülbelül 10-szer magasabb, mint a H.264.
Szövetség a nyílt médiáért különböző területeken működő cégek hozták létre: berendezésgyártók (Intel, AMD, ARM, Nvidia, Cisco), tartalomszolgáltatók (Google, Netflix, Amazon), böngészőkészítők (Google, Mozilla) és mások.
A cégeknek közös célja volt: jogdíjmentes videokodek. Ezután megjelenik AV1 sokkal egyszerűbb szabadalmi engedéllyel. Timothy B. Terryberry lenyűgöző előadást tartott, amely a jelenlegi AV1 koncepció és licencmodelljének eredete lett.
Meg fog lepődni, ha megtudja, hogy az AV1 kodeket egy böngészőn keresztül is elemezheti (az érdeklődők a).
Univerzális kodek
Nézzük meg az univerzális videokodek alapjául szolgáló fő mechanizmusokat. Ezen fogalmak többsége hasznos, és a modern kodekekben használatosak, mint pl VP9, AV1 и HEVC. Figyelmeztetem, hogy sok elmagyarázott dolog leegyszerűsödik. Néha valós példákat (mint a H.264 esetében) használnak a technológiák bemutatására.
1. lépés - a kép felosztása
Az első lépés a keret felosztása több részre, alszakaszra és tovább.
Miért? Sok oka van. Amikor felosztunk egy képet, pontosabban megjósolhatjuk a mozgásvektort, ha kis szakaszokat használunk kis mozgó alkatrészekhez. Statikus háttér esetén nagyobb részekre korlátozhatja magát.
A kodekek általában ezeket a szakaszokat szakaszokba (vagy csonkokba), makroblokkokba (vagy kódolófa blokkokba) és több alszakaszba rendezik. Ezeknek a partícióknak a maximális mérete változó, a HEVC 64x64-re állítja be, míg az AVC 16x16-ot használ, az alpartíciók pedig 4x4-es méretre oszthatók fel.
Emlékszel a keretek típusaira az előző cikkből?! Ugyanez alkalmazható blokkokra is, így lehet I-töredékünk, B-blokkunk, P-makroblokkunk stb.
Aki gyakorolni szeretne, nézze meg, hogyan oszlik a kép részekre és alszakaszokra. Ehhez használhatja az előző cikkben már említettet. (az, amelyik fizetős, de ingyenes próbaverzióval, amely az első 10 képkockára korlátozódik). Az itt elemzett szakaszok VP9:
2. lépés - előrejelzés
Ha megvannak a szakaszok, akkor asztrológiai előrejelzéseket készíthetünk hozzájuk. Mert INTER előrejelzések át kell adni mozgásvektorok és a maradékot, és az INTRA előrejelzéshez továbbítja előrejelzési irány és a maradék.
3. lépés - átalakulás
Ha már van egy maradék blokk (jósolt szakasz → valós szakasz), akkor azt úgy alakíthatjuk át, hogy tudjuk, mely pixeleket lehet eldobni az általános minőség megőrzése mellett. Vannak olyan átalakítások, amelyek a pontos viselkedést biztosítják.
Bár vannak más módszerek is, nézzük meg őket részletesebben. diszkrét koszinusz transzformáció (DCT - innen diszkrét koszinusz transzformáció). A DCT fő funkciói:
- A képpontok blokkjait azonos méretű frekvenciaegyüttható blokkokká alakítja.
- Kondenzálja az energiát, hogy segítsen kiküszöbölni a térbeli redundanciát.
- Visszafordíthatóságot biztosít.
2. február 2017. Sintra R.J. (Cintra, RJ) és a Bayer F.M. (Bayer FM) publikált egy cikket a képtömörítés DCT-szerű átalakításáról, amely mindössze 14 kiegészítést igényel.
Ne aggódjon, ha nem érti az egyes tételek előnyeit. Most pedig használjunk konkrét példákat, hogy lássuk valódi értéküket.
Vegyük ezt a 8x8-as pixelblokkot:
Ez a blokk a következő 8 x 8 pixeles képpé jelenik meg:
Alkalmazza a DCT-t erre a pixelblokkra, és kap egy 8x8-as együtthatóblokkot:
És ha ezt az együtthatóblokkot rendereljük, a következő képet kapjuk:
Amint látja, nem úgy néz ki, mint az eredeti kép. Látható, hogy az első együttható nagyon különbözik az összes többitől. Ezt az első együtthatót DC-együtthatónak nevezik, amely a bemeneti tömb összes mintáját reprezentálja, valami olyan, mint egy átlag.
Ennek az együtthatóblokknak van egy érdekes tulajdonsága: elválasztja a magas frekvenciájú összetevőket az alacsony frekvenciájúaktól.
Egy képen az energia nagy része alacsonyabb frekvenciákon összpontosul, így ha a képet a frekvenciakomponenseire alakítja át, és elveti a magasabb frekvencia együtthatókat, csökkentheti a kép leírásához szükséges adatmennyiséget anélkül, hogy túl sok képminőséget áldozna.
A frekvencia azt jelenti, hogy a jel milyen gyorsan változik.
Próbáljuk meg a tesztesetben megszerzett tudást úgy alkalmazni, hogy az eredeti képet DCT segítségével a frekvenciájára (együtthatóblokkokra) konvertáljuk, majd a legkevésbé fontos együtthatók egy részét eldobjuk.
Először átalakítjuk a frekvenciatartományba.
Ezután az együtthatók egy részét (67%) eldobjuk, főleg a jobb alsó részt.
Végül ebből az eldobott együtthatóblokkból rekonstruáljuk a képet (ne feledjük, megfordíthatónak kell lennie), és összehasonlítjuk az eredetivel.
Látjuk, hogy hasonlít az eredeti képre, de sok eltérés van az eredetitől. 67,1875%-ot dobtunk ki, és mégis kaptunk valamit, ami hasonlít az eredetire. Lehetett átgondoltabban elvetni az együtthatókat, hogy még jobb minőségű képet kapjunk, de ez a következő téma.
Minden együttható az összes képpont felhasználásával jön létre
Fontos: minden együttható nincs közvetlenül leképezve egy pixelre, hanem az összes képpont súlyozott összege. Ez a csodálatos grafikon megmutatja, hogyan számítják ki az első és a második együtthatót az egyes indexek egyedi súlyozásával.
Megpróbálhatja úgy is megjeleníteni a DCT-t, hogy megnéz egy egyszerű képalkotást az alapján. Például itt van az A szimbólum, amelyet az egyes együtthatósúlyok felhasználásával generálnak:
4. lépés - kvantálás
Miután az előző lépésben kidobtunk néhány együtthatót, az utolsó lépésben (transzformáció) egy speciális kvantálási formát hajtunk végre. Ebben a szakaszban elfogadható az információ elvesztése. Vagy egyszerűbben, kvantifikáljuk az együtthatókat a tömörítés eléréséhez.
Hogyan lehet kvantálni egy együttható blokkot? Az egyik legegyszerűbb módszer az egységes kvantálás, amikor veszünk egy blokkot, elosztjuk egy értékkel (10-zel), és az eredményt kerekítjük.
Megfordíthatjuk ezt az együtthatóblokkot? Igen, meg tudjuk szorozni ugyanazzal az értékkel, amellyel elosztottuk.
Ez a megközelítés nem a legjobb, mert nem veszi figyelembe az egyes együtthatók fontosságát. Egyetlen érték helyett kvantálómátrixot is használhatunk, és ez a mátrix kihasználhatja a DCT tulajdonságot úgy, hogy kvantálja a jobb alsó és a bal felső kisebb részét.
5. lépés - entrópia kódolás
Ha már kvantáltuk az adatokat (képblokkok, töredékek, keretek), akkor is veszteségmentesen tömöríthetjük azokat. Számos algoritmikus módszer létezik az adatok tömörítésére. Rövid pillantást vetünk néhányra, a mélyebb megértéshez olvassa el a Understanding Compression: Data Compression for Modern Developers című könyvet ("").
Videó kódolás VLC használatával
Tegyük fel, hogy van egy sor karakterünk: a, e, r и t. Ez a táblázat mutatja be annak valószínűségét (0 és 1 között), hogy milyen gyakran jelennek meg az egyes karakterek egy adatfolyamban.
| a | e | r | t | |
|---|---|---|---|---|
| valószínűség | 0,3 | 0,3 | 0,2 | 0,2 |
A legvalószínűbbekhez egyedi bináris kódokat (lehetőleg kicsiket), a kevésbé valószínűekhez pedig nagyobb kódokat rendelhetünk.
| a | e | r | t | |
|---|---|---|---|---|
| valószínűség | 0,3 | 0,3 | 0,2 | 0,2 |
| Bináris kód | 0 | 10 | 110 | 1110 |
Tömörítjük az adatfolyamot, feltételezve, hogy végül 8 bitet költünk minden karakterre. Tömörítés nélkül 24 bitre lenne szükség karakterenként. Ha minden karaktert lecserélsz a kódjára, megtakarítást érhetsz el!
Az első lépés a karakter kódolása e, ami egyenlő 10-zel, a második karakter pedig a, amely hozzáadódik (nem matematikai módon): [10][0], és végül a harmadik karakter t, ami a végső tömörített bitfolyamunkat egyenlővé teszi a [10][0][1110] vagy 1001110, amely mindössze 7 bitet igényel (3,4-szer kevesebb helyet, mint az eredeti).
Felhívjuk figyelmét, hogy minden kódnak egyedi kódnak kell lennie előtaggal. segít megtalálni ezeket a számokat. Bár ez a módszer nem mentes a hibáitól, vannak olyan videokodekek, amelyek továbbra is ezt az algoritmikus módszert kínálják a tömörítéshez.
Mind a kódolónak, mind a dekódolónak hozzá kell férnie egy szimbólumtáblázathoz a bináris kódjaikkal. Ezért bemenetként táblázatot is kell küldeni.
Aritmetikai kódolás
Tegyük fel, hogy van egy sor karakterünk: a, e, r, s и t, és ezek valószínűségét ez a táblázat mutatja be.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| valószínűség | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
A táblázat segítségével az összes lehetséges karaktert tartalmazó tartományokat fogjuk felépíteni, a legnagyobb szám szerint rendezve.
Most kódoljunk egy három karakterből álló adatfolyamot: eszik.
Először válassza ki az első karaktert e, amely a 0,3 és 0,6 közötti altartományban van (nem beleértve). Ezt az altartományt vesszük, és újra felosztjuk ugyanolyan arányban, mint korábban, de erre az új tartományra.
Folytassuk az adatfolyamunk kódolását eszik. Most vegyük a második karaktert a, amely az új 0,3 és 0,39 közötti altartományban van, majd vegyük az utolsó karakterünket t és ugyanezt a folyamatot még egyszer megismételve megkapjuk a végső 0,354 és 0,372 közötti résztartományt.
Csak ki kell választanunk egy számot az utolsó altartományban 0,354 és 0,372 között. Válasszunk 0,36-ot (de bármely más számot is választhat ebben az altartományban). Csak ezzel a számmal tudjuk visszaállítani az eredeti adatfolyamunkat. Olyan, mintha egy vonalat húznánk a tartományon belül, hogy kódoljuk az adatfolyamunkat.
A fordított művelet (azaz dekódolás) ugyanolyan egyszerű: a 0,36-os számunkkal és a kezdeti tartományunkkal ugyanezt a folyamatot futtathatjuk. De most, ezzel a számmal, azonosítjuk az ezzel a számmal kódolt adatfolyamot.
Az első tartománynál észrevesszük, hogy a számunk megfelel a szeletnek, ezért ez az első karakterünk. Most ismét felosztjuk ezt az altartományt, ugyanazt a folyamatot követve, mint korábban. Itt látható, hogy a 0,36 a szimbólumnak felel meg a, és a folyamat megismétlése után az utolsó karakterhez érkeztünk t (az eredeti kódolt adatfolyamunkat alkotva eszik).
Mind a kódolónak, mind a dekódolónak rendelkeznie kell egy szimbólumvalószínűségi táblázattal, ezért a bemeneti adatokban is szükséges elküldeni.
Elég elegáns, nem? Aki ezt a megoldást kitalálta, az rohadt okos volt. Egyes videokodekek ezt a technikát használják (vagy legalábbis opcióként kínálják).
Az ötlet egy kvantált bitfolyam veszteségmentes tömörítése. Bizonyára ebből a cikkből rengeteg részlet hiányzik, indokok, kompromisszumok stb. De ha Ön fejlesztő, többet kell tudnia. Az új kodekek különböző entrópia kódolási algoritmusokat próbálnak használni, mint pl Éves.
6. lépés - bitfolyam formátum
Mindezek elvégzése után hátra van a tömörített képkockák kicsomagolása az elvégzett lépések keretében. A dekódolót kifejezetten tájékoztatni kell a kódoló által hozott döntésekről. A dekódert el kell látni minden szükséges információval: bitmélység, színtér, felbontás, előrejelzési információk (mozgásvektorok, irány INTER előrejelzés), profil, szint, képkocka sebesség, képkocka típusa, képkocka száma és még sok más.
Gyorsan megnézzük a bitfolyamot H.264. Első lépésünk egy minimális H.264 bitfolyam létrehozása (az FFmpeg alapértelmezés szerint minden kódolási lehetőséget hozzáad, mint pl. SEI NAL - kicsit távolabb megtudjuk, mi ez). Ezt saját tárolónk és FFmpeg segítségével tehetjük meg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Ez a parancs nyers bitfolyamot generál H.264 egy kerettel, 64×64 felbontással, színtérrel YUV420. Ebben az esetben a következő kép kerül felhasználásra keretként.
H.264 bitfolyam
Standard AVC (H.264) határozza meg, hogy az információ makrokeretekben kerüljön elküldésre (hálózati értelemben), ún nal (ez egy hálózati absztrakciós szint). A NAL fő célja egy "webbarát" videó prezentáció biztosítása. Ennek a szabványnak működnie kell TV-ken (folyam-alapú), interneten (csomag-alapú).
Van egy szinkronizációs jelző a NAL elemek határainak meghatározásához. Minden szinkronizálási token tartalmaz egy értéket 0x00 0x00 0x01, kivéve a legelsőt, ami egyenlő 0x00 0x00 0x00 0x01. Ha elindítjuk hexdump a generált H.264 bitfolyamhoz legalább három NAL mintát azonosítunk a fájl elején.
Mint elhangzott, a dekódernek nemcsak a képadatokat kell ismernie, hanem a videó részleteit, a keretet, a színeket, a használt paramétereket és még sok minden mást is. Minden NAL első bájtja határozza meg a kategóriáját és típusát.
| NAL típusú azonosító | Leírás |
|---|---|
| 0 | Ismeretlen típus |
| 1 | Kódolt képrészlet IDR nélkül |
| 2 | Kódolt szelet adatrész A |
| 3 | Kódolt szelet adatrész B |
| 4 | Kódolt szelet adatrész C |
| 5 | Egy IDR-kép kódolt IDR-részlete |
| 6 | További információ a SEI bővítményről |
| 7 | SPS szekvencia paraméter beállítása |
| 8 | PPS képparaméterek készlete |
| 9 | Hozzáférési elválasztó |
| 10 | Sorozat vége |
| 11 | A szál vége |
| ... | ... |
Általában a bitfolyam első NAL-ja PLC. Ez a típusú NAL felelős az olyan általános kódolási változókról való tájékoztatásért, mint a profil, szint, felbontás stb.
Ha kihagyjuk az első szinkronizálási jelölőt, akkor dekódolhatjuk az első bájtot, hogy megtudjuk, melyik NAL típus az első.
Például a szinkronizálási token utáni első bájt az 01100111, ahol az első bit (0) az f mezőben találhatóorbidden_zero_bit. Következő 2 bit (11) elárulja a terepet nal_ref_idc, amely jelzi, hogy ez a NAL referenciamező-e vagy sem. És a maradék 5 bit (00111) elárulja a terepet nal_unit_type, ebben az esetben az SPS blokk (7) NAL.
második bájt (kétkomponensű=01100100, hex=0x64, december=100) az SPS NAL-ban a mező profile_idc, amely a kódoló által használt profilt mutatja. Ebben az esetben korlátozott magas profilt használtunk (azaz magas profilt kétirányú B-szegmens támogatás nélkül).
Ha megnézed a bitfolyam specifikációt H.264 Az SPS NAL esetében sok értéket találunk a paraméternévhez, kategóriához és leíráshoz. Például nézzük a mezőket pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Paraméter neve | Kategória | Leírás |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Ha ezeknek a mezőknek az értékeivel végrehajtunk néhány matematikai műveletet, akkor felbontást kapunk. Az egyik 1920 x 1080-as felbontást képviselhet pic_width_in_mbs_minus_1 119 értékkel ((119 + 1) * macroblock_size = 120 * 16 = 1920). A helytakarékosság kedvéért az 1920-as kódolás helyett a 119-el csináltuk.
Ha továbbra is bináris formában ellenőrizzük a létrehozott videónkat (pl.: xxd -b -c 11 v/minimal_yuv420.h264), akkor ugorhat az utolsó NAL-ra, ami maga a keret.
Itt látjuk az első 6 bájt értékeit: 01100101 10001000 10000100 00000000 00100001 11111111. Mivel az első bájt köztudottan a NAL típust jelzi, ebben az esetben (00101) egy IDR-töredék (5), majd tovább kutathatja:
A specifikációs információk segítségével dekódolható lesz a töredéktípus (szelet_típus) és keretszám (keret_szám) más fontos területek között.
Néhány mező értékének lekéréséhez (ue(v), me(v), se(v), vagy te(v)), dekódolnunk kell a töredéket egy speciális dekóder segítségével . Ez a módszer nagyon hatékony a változóértékek kódolására, különösen akkor, ha sok alapértelmezett érték van.
jelentés szelet_típus и keret_szám ebből a videóból 7 (I-töredék) és 0 (első képkocka).
A bitfolyam felfogható protokollnak. Ha többet szeretne tudni a bitfolyamról, nézze meg a specifikációt ITU H.264. Itt van egy makró diagram, amely megmutatja, hol vannak a képadatok (YUV tömörített formában).
Más bitfolyamok is vizsgálhatók, mint pl VP9, H.265 (HEVC) vagy akár az új legjobb bitfolyamunk AV1. Mindegyik hasonló? Nem, de ha legalább egyet megért, sokkal könnyebb megérteni a többit.
Akarsz gyakorolni? Fedezze fel a H.264 bitfolyamot
Létrehozhat egyetlen képkockás videót, és a MediaInfo segítségével megvizsgálhatja a bitfolyamot H.264. Valójában semmi sem akadályozza meg, hogy még a bitfolyamot elemző forráskódot is megnézze H.264 (AVC).
Gyakorlásra használhatod az Intel Video Pro Analyzert (mondtam már, hogy fizetős a program, de van ingyenes próbaverzió, 10 képkocka limittel?).
Értékelés
Vegye figyelembe, hogy sok modern kodek ugyanazt a modellt használja, amelyet az imént vizsgáltunk. Itt nézzük meg a videokodek blokkdiagramját Thor. Ez tartalmazza az összes lépést, amelyen keresztülmentünk. Ennek a bejegyzésnek az a lényege, hogy legalább jobban megértse az újításokat és a dokumentációt ezen a területen.
Korábban úgy számoltak, hogy 139 GB lemezterületre lenne szükség egy egy órán át tartó, 720p minőségben és 30 fps-es videófájl tárolására. Ha az ebben a cikkben tárgyalt módszereket (kockák közötti és belső előrejelzések, transzformáció, kvantálás, entrópiakódolás stb.) alkalmazza, akkor (az alapján, hogy pixelenként 0,031 bitet költünk) egy videót érhet el kielégítő minőség, csak 367,82 MB-ot foglal el, nem 139 GB memóriát.
Hogyan ér el a H.265 jobb tömörítési arányt, mint a H.264?
Most, hogy többet tudunk a kodekek működéséről, könnyebb megérteni, hogyan tudnak az újabb kodekek nagyobb felbontást biztosítani kevesebb bittel.
Ha összehasonlítjuk AVC и HEVC, érdemes megjegyezni, hogy ez szinte mindig a nagyobb CPU-terhelés és a tömörítési arány közötti választás.
HEVC több szakasz (és alszakasz) opcióval rendelkezik, mint AVC, több belső előrejelzési irány, továbbfejlesztett entrópiakódolás stb. Mindezek a fejlesztések megtörténtek H.265 50%-kal több tömörítésre képes, mint H.264.
Az első rész:
Forrás: will.com