A H.264 varázslat

A H.264 egy videotömörítési kodek szabvány. Mindenütt megtalálható - internetes videó, Blu-ray, telefonok, biztonsági kamerák, drónok, minden. Most minden a H.264-et használja.

A H.264 egy figyelemre méltó technológia. Több mint 30 éves munka eredménye egyetlen céllal: A teljes mozgású videó továbbításához szükséges sávszélesség csökkentése.

Technikailag nagyon érdekes. Ez a bejegyzés magas színvonalú betekintést nyújt néhány részletbe - remélem, hogy nem unom túlságosan a bonyodalmakat. Vegye figyelembe azt is, hogy az itt kifejtett fogalmak közül sok általában a videotömörítésre vonatkozik, és nem csak a H.264-re.

Egy egyszerű, tömörítetlen videofájl 2D pufferek tömbjét fogja tartalmazni, amelyek pixeladatokat tartalmaznak az egyes képkockákhoz. Tehát ez egy 3D (2 térbeli dimenzió és 1 időbeli) bájt tömb. Minden pixel tárolása 3 bájtot igényel - egy-egy bájt a három elsődleges színhez (piros, zöld és kék).

1080p @ 60 Hz = 1920x1080x60x3 =>

370 MB/sec nyers adat.

Ezzel szinte lehetetlen foglalkozni. Csak egy 50 GB-os Blu-ray lemez fér el

2 perc. Nem lehet gyorsan bárhová mozgatni. Még az SSD-knek is gondjai vannak, amikor ezt egyenesen a RAM-ról a Lemezre dobják [^ 1].

Szóval igen. Tömörítésre van szükségünk.

Igen, erre válaszolok. De először hadd mutassak neked valamit. Itt van az Apple honlapja:

Rögzítettem ennek a kezdőlapnak a képernyőjét, és két fájlt készítettem:

Eh. Mit? Ezek a fájlméretek váltakoznak.

Nem, igazuk van. A 300 képkocka hosszú H.264 videó 175 KB. A videó egyetlen képkockája PNG-ben 1015 KB.

Úgy tűnik, hogy a videóban 300-szoros adatmennyiséget tárolunk. De a fájlméret ötödik. Úgy tűnik tehát, hogy a H.264 1500x olyan hatékony, mint a PNG.

Hogyan is lehetséges ez? Rendben, mi a trükk?

Nagyon sok trükk van! A H.264 minden olyan trükköt felhasznál, amire csak gondolhat (és rengeteg tételt nem tud). Menjünk át a fontosakon.

Leeső súly

Képzelje el, hogy autót épít utcai versenyzéshez. Gyorsabban kell mennie. Mi az első dolog, amit csinálsz? Hullott egy kis súlyt. Az Ön autója 3000 fontot nyom. Kidobja azokat a dolgokat, amelyekre nincs szüksége. Azok a hátsó ülések? pfft. Chuck azokat. Az a mélynyomó? Elmúlt. Nincs zene neked. Légkondíciónálás? Igen, ártsd el. Terjedés? Ti.nem. Várjon! Erre szükségünk lesz.

Mindent eltávolít, kivéve a fontos dolgokat.

Ezt a koncepciót a bitek eldobására, amelyre nincs szükség helytakarékosságra, hívják veszteséges tömörítés. A H.264 veszteséges kodek - kevésbé fontos biteket dob el, és csak a fontos biteket tartja meg.

A PNG a veszteségmentes kodek. Ez azt jelenti, hogy semmit sem dobnak el. Bitről bitre az eredeti forráskép visszaállítható egy PNG kódolású képből.

Fontos bitek? Honnan tudja az algoritmus, hogy milyen bitek vannak a keretemben?

Kevés nyilvánvaló módszer van a képek kivágására. Lehet, hogy a jobb felső negyed mindig haszontalan. Tehát talán nullázhatjuk ezeket a képpontokat, és eldobhatjuk azt a negyedet. Csak a szükséges tér 3/4-ét használnánk fel.

2200 font most. Vagy talán kivághatunk egy vastag szegélyt a keret szélei körül, a fontos dolgok egyébként középen vannak. Igen, meg tudnád csinálni ezeket. De a H.264 nem ezt teszi.

A H.264, más veszteséges képalgoritmusokhoz hasonlóan, elveti a részletes információkat. Itt van egy közelkép az eredetihez képest az eldobott képhez képest.

Látja, hogy a tömörített nem mutatja-e a lyukakat a hangszórórácsokban a MacBook Pro-ban? Ha nem nagyít, akkor észre is veszi a különbséget. A jobb oldali kép súlya: 7% akkora, mint az eredeti - és a képet még a hagyományos értelemben sem tömörítettük. Képzelje el, hogy autója mindössze 200 fontot nyomott!

7% wow! Hogyan dobhatja el az ilyen részleteket?

Ehhez szükségünk van egy gyors matematika órára.

Információs entrópia

Most eljutunk a lédús darabokhoz! Ha szójáték! Ha részt vett egy információelméleti órán, akkor emlékezhet az információ-entrópiára. Az információs entrópia az egyes információk ábrázolásához szükséges bitek száma. Ne feledje, hogy nem egyszerűen egyes adatkészletek mérete. A minimális bitszámot kell felhasználni az adatkészletben található összes információ megjelenítésére.

Például, ha az adatkészlet egyetlen érme dobás eredménye, 1 bit entrópiára van szükség. Ha két érme dobása van rekordon, akkor 2 bitre lesz szüksége. Van értelme?

Tegyük fel, hogy van valami furcsa érme - tízszer dobta fel, és valahányszor a fejére száll. Hogyan írnád le ezt az információt valakinek? Nem mondanád, hogy HHHHHHHHHH. Csak azt mondanád, hogy "10 dobás, minden fej" - bam! Csak tömörített néhány adatot! Könnyen. Órákig megspóroltam neked a mindfuck előadásokat. Ez nyilvánvalóan túlegyszerűsítés, de néhány adatot átalakított ugyanazon információ másik rövidebb ábrázolásává. Csökkentette az adatokat redundancia. Az adatkészlet információs entrópiája nem változott - most konvertált a reprezentációk között. Ezt a típusú kódolót an-nak hívják entrópia kódoló - ez egy általános célú veszteségmentes kódoló, amely bármilyen típusú adatra használható.

Frekvenciatartomány

Most, hogy megértette az információs entrópiát, térjünk át az adatok átalakítására. Néhány alapvető egységben ábrázolhatja az adatokat. Ha binárisat használ, akkor 0 és 1 van. Ha hexát használ, akkor 16 karakter van. Könnyedén átalakulhat a két rendszer között. Lényegében egyenértékűek. Eddig jó? Rendben!

Most némi fantázia! Képzelje el, hogy bármely olyan adatsort átalakíthat, amely térben (vagy időben) változik - például egy kép fényerejének értékét - egy másik koordináta-térbe. Tehát tegyük fel, hogy x-y koordináták helyett frekvencia koordinátáink vannak. A freqX és a freqY a tengely. Ezt hívják a frekvenciatartomány reprezentáció. Van egy másik mindfuck matematikai tétel [^ 2], amely kimondja, hogy ezt megteheti bármilyen adat esetén, és tökéletes veszteségmentes átalakulást érhet el, amíg a freqX és a freqY elég magas.

Oké, de mi a frekvencia, az a frekvencia és a frekvencia?

A freqX és a freqY néhány más alapegység. Csakúgy, mint amikor binárisról hexára váltunk, más alapegységünk van, az ismert X-Y-ről a freqX-re és a freqY-re váltunk. Az „A” hatszög másképp néz ki, mint az „1010” bináris. Mindkettő ugyanazt jelenti, de néz különböző. Tehát a képünk a frekvenciatartományban így néz ki:

A MacBook pro finom grilljének nagy információtartalma van a kép magasabb frekvenciájú elemeiben. Finoman változó tartalom = nagy frekvenciájú komponensek. A szín és a fényerő bármilyen fokozatos változása - például a színátmenet - a kép alacsony frekvenciájú alkotóeleme. Bármi a kettő között esik. Tehát finom részletek = magas frekvencia. Gyengéd gradiensek = alacsony frekvencia Van értelme?

A frekvenciatartomány ábrázolásában az alacsony frekvenciájú komponensek a kép közepe közelében vannak. A magasabb frekvenciájú komponensek a kép széle felé mutatnak.

Oké. Kindának van értelme. De miért tegye mindezt?

Mert most ezt a frekvenciatartomány-képet készítheti, majd eltakarja az éleket - dobja el azokat az információkat, amelyek a nagyfrekvenciás komponensekkel együtt tartalmazzák az információkat. Most, ha visszaállítasz a szokásos x-y koordinátákra, azt találod, hogy a kapott kép hasonlít az eredetihez, de elveszített néhány finom részletet. De most a kép csak a tér töredékét foglalja el. Annak szabályozásával, hogy mekkora a maszkja, most már pontosan beállíthatja, hogy a kimeneti képek milyen részletesek legyenek.

Itt van ismét a laptop részlete a kezdőlapon. Most kivételével körkörös maszkot alkalmaztak.

A számok az adott kép információ-entrópiáját képviselik, mint az eredeti töredékét. Még 2% -nál sem fogja észrevenni a különbséget, hacsak nem ezen a nagyítási szinten van. 2%! - az autód súlya most 60 kg!

Tehát így hízol le. Ezt a folyamatot veszteséges tömörítésben nevezzük kvantálás[^ 3].

Oké. Lenyűgöző, azt hiszem. Mi mást kapott?

Chroma alminta.

Az emberi/szem agyi rendszer nem túl alkalmas a finomabb részletek színes megoldására. A fényerő kisebb eltéréseit nagyon könnyen képes észlelni, de a színeket nem. Tehát valamilyen módon el kell vetni a színes információkat, hogy még nagyobb súlyt lehessen adni.

Egy TV-jelben az R + G + B színadatok Y + Cb + Cr-re alakulnak át. Az Y a fényerő (lényegében fekete-fehér fényerő), a Cb és Cr pedig a szín (komponens) komponensek. Az RGB és az YCbCr az információ-entrópia szempontjából egyenértékű.

Miért bonyolítja feleslegesen? Az RGB nem elég jó neked?

Még mielőtt színes televíziónk lenne, csak Y jelünk volt. Amikor a színes tévék csak elkezdtek megjelenni, a mérnököknek ki kellett találniuk az RGB színátvitel módját Y-vel együtt. Két külön adatfolyam használata helyett bölcsen úgy döntöttek, hogy a színes információkat Cb-be és Cr-ba kódolják, és továbbítják ezeket a Y információk. Így a BW tévék csak az Y komponenst néznék. A színes tévék ezen felül megvizsgálják a színkomponenseket, és belsõ módon átalakítják RGB -vé.

De nézze meg a trükköt: az Y komponens teljes felbontásban lesz kódolva. A C komponensek csak negyed felbontással. Mivel a szem/agy szörnyű a színvariációk észlelésében, megúszhatja ezt. Ezzel a felével csökkenti a teljes sávszélességet, nagyon kis vizuális különbséggel. Fél! Az autója most 30 fontot nyom!

Ezt a folyamatot a színinformációk egy részének elvetésére hívják Chroma alminta[^ 4]. Noha nem jellemző a H.264-re és maga évtizedek óta létezik, szinte univerzálisan használják.

Ezek a nagy súlyú redőnyök a veszteséges tömörítéshez. Kereteink most aprók - mivel a legtöbb részletinformációt és a színes információk felét elvetettük.

Várjon. Ez az? Tehetnénk még valamit?

Igen. A súlycsökkenés csak az első lépés. Eddig csak egyetlen térben kerestük a térbeli területeket. Itt az ideje, hogy felfedezzük az időbeli tömörítést - ahol a keretek egy csoportját nézzük az időben.

Mozgáskompenzáció

A H.264 egy mozgáskompenzációs tömörítési szabvány.

Képzelje el, hogy tenisz mérkőzést néz. A kamera egy bizonyos szögben van rögzítve. Az egyetlen dolog, ami mozog, a labda oda-vissza. Hogyan kódolná ezeket az információkat? Azt csinálod, amit mindig is csinálsz, igaz? 3D pixeltömbje van, két dimenzióval térben és egy időben. Jobb?

Nem. Miért tennéd? A kép nagy része egyébként is ugyanaz. A bíróság, a háló, a tömeg, mind statikus. Az egyetlen igazi akció a labda mozgása. Mi lenne, ha csak egy statikus kép jelenhetne meg mindenről a háttérben, majd csak egy labda mozgóképe? Nem spórolna meg sok helyet? Látod, hová megyek ezzel? Szerezd meg? Látod, merre tartok? Mozgásbecslés?

A béna poénokat félretéve, pontosan ezt teszi a H.264. A H.264 makro-blokkokra bontja a képet - általában 16x16 pixeles blokkokra, amelyeket mozgásbecsléshez fog használni. Egy statikus képet kódol - amelyet általában annak hívnak I-frame(Belső keret). Ez egy teljes keret - tartalmazza az összes bitet, amelyre szükség van a keret elkészítéséhez. És akkor a következő képkockák is P-keretek(megjósolt) vagy B-keretek(kétirányú előrejelzés). A P-keretek olyan keretek, amelyek mozgásvektort kódolnak az előző képkockák mindegyikének makró-blokkjaihoz. Tehát a dekódolónak P-keretet kell készítenie az előző képkockák alapján. A videofolyamat utolsó I-képkockájával kezdődik, majd végigvonul minden következő képkockán - összeadva a mozgásvektor deltáit, amíg halad az aktuális képkockáig.

A B-képkockák még érdekesebbek, ahol az előrejelzés kétirányúan történik, mind a múltbeli, mind a jövőbeli képkockákból. Tehát el tudja képzelni, miért van az Apple honlapjának videója annyira tömörítve. Mert valójában csak három I-képkocka van, amelyekben a makróblokkok körül mozognak.

Tegyük fel, hogy videót játszott a YouTube-on. Kihagyta a párbeszéd utolsó néhány másodpercét, ezért néhány másodpercet visszagörget. Észrevette, hogy nem azonnal kezdi el lejátszani az éppen kiválasztott időkódot. Néhány pillanatig szünetel, majd játszik. Ezeket a képkockákat már pufferolja a hálózattól, mivel te csak lejátszottad, akkor miért szünetelt?

Igen, ez idegesíti a szart. Miért teszi ezt?

Mivel arra kérted a dekódert, hogy ugorjon valamilyen tetszőleges keretre, a dekódolónak át kell dolgoznia az összes számítást - kezdve a legközelebbi I-képkockáktól és hozzáadva a mozgásvektor deltáit az éppen használt kerethez - és ez számítási szempontból drága, és ezért a rövid szünet. Remélhetőleg most kevésbé fog bosszantani, tudván, hogy valójában kemény munkát végez, és nem csak azért ül, hogy csak bosszantsa.

Mivel csak a mozgásvektor-deltákat kódolja, ez a technika rendkívül mozgásterű videókhoz rendkívül helytakarékos, némi számítás árán.

Most mind a térbeli, mind az időbeli tömörítést átfogtuk! Eddig a kvantálásban megtakarítottunk egy helyet. A Chroma almintavétel tovább felezte a szükséges helyet. Ezen felül van mozgáskompenzációnk, amely csak 3 tényleges keretet tárol a

300, ami abban a videóban volt.

Nagyon jól néz ki nekem. Most mi?

Most lezárjuk és lezárjuk az üzletet. Egy hagyományos veszteségmentes entrópia kódolót használunk. Mert miért ne? Pofozzunk csak rá jó mérlegelés céljából.

Entrópia kódoló

Az I-keretek a veszteséges lépések után felesleges információkat tartalmaznak. A P és B keretek mindegyik makró blokkjának mozgásvektorai - egész csoportjaik vannak ugyanazokkal az értékekkel -, mivel több makro blokk ugyanolyan mértékben mozog, amikor a kép a tesztvideónkba pásztázik.

Egy entrópia kódoló gondoskodik erről a redundanciáról. És mivel ez egy általános célú veszteségmentes kódoló, nem kell aggódnunk, hogy milyen kompromisszumokat hoz létre. Vissza tudjuk állítani az összes beírt adatot.

És kész! Ennek lényege, hogy a H.264-hez hasonló videotömörítési kodekek működnek. Ezek a trükkök.

Jólvan szuper! De kíváncsi vagyok, hogy most mennyit nyom az autónk.

Az eredeti videót furcsa 1232x1154 felbontással rögzítették. Ha itt alkalmazzuk a matematikát, a következőket kapjuk:

5 mp @ 60 kép/mp = 1232x1154x60x3x5 => 1,2 GB
Tömörített videó => 175 KB

Ha ugyanazt az arányt alkalmazzuk a 3000 fontos autónkra, akkor megkapjuk 0,4 font mint a végső súly. 6,5 uncia!

Igen. Ez varázslat!

Nyilvánvalóan jelentősen leegyszerűsítem a több évtizedes intenzív kutatást ezen a területen. Ha többet szeretne megtudni, a Wikipédia Oldal elég leíró.

Megjegyzéseid vannak? Tévedtem valamit? Nem rajong a béna poénokért? Megsértődött a káromkodás miatt? Használat HackerNews vagy Reddit amiért hangot adott a véleményének!