A második részben az enkódolás lépéseivel, a legfontosabb definíciókkal, azok használatával ismerkedünk meg. Ha valamely fogalom, kifejezés első használatakor nincs ott a definíciója, azt később fejtem ki bővebben. Az enkódolás is több részre oszlik, mert nem szeretném ömlengősre venni a dolgot.

Hogyan működik a H.264

Leegyszerűsítve a dolgot, a H.264 leír egy enkódolási és egy dekódolási folyamatot anélkül, hogy konkrét codec-et határozna meg a szabvány. Ez eléggé furcsának hangzik, hiszen így csak az enkódolt bitstream szintaxisa és a dekódolás metódusa van meghatározva, de az MPEG-1, MPEG-2 és MPEG-4 szabványok esetében is hasonlóan jártak el a tervezéskor. Gyakorlatilag azt határozták meg, hogy a használt enkóder és dekóder milyen funkcionális elemekből építkezhet. Az alapvető elemek (prediction, transform, quantization, entropy encoding) különböznek az előző szabványokban használtaktól (MPEG1, MPEG2, MPEG4, H.261, H.263), de az igazi eltérés a részletekben rejlik. Fogalmilag a VCL (Video Coding Layer) és a NAL (Network Abstraction Layer) közé helyezi magát a H.264. Ez utóbbiról később kicsit bővebben is esik majd szó. A VCL tartalmazza a jelfeldolgozás funkcióit, mint a mozgás kompenzált előrejelzést, a transzformációt, quantization-t, loop filtert, a modern codec-ek hagyományait követve ebben.

Tulajdonképpen azt is mondhatnánk, hogy az dekódolás majdnem ugyanolyan lépésekből áll, mint az enkódolás, csak visszafelé. Nézzük meg a lépéseket kicsit részletesebben, hogy lássuk, mi is zajlik a háttérben.

Enkódolás

A bemenő bitstream, fogalmak

Minden videó keretekből áll és szabvány szerint 25-30 jelenik meg belőlük másodpercenként. Így látjuk a mozgóképet. Minden keret ún. Macroblock-okból (MB) áll, amik 16x16 pixelt (képpontot) foglalnak magukba alapesetben. Kódolás során az azonos felosztású blokkokat más kereteknél is felhasználhatjuk. Egy kép „luminance” vagy luma komponense ezeknek a kereteknek a felhasználásával mintavételeződik, a „chrominance” vagy chroma komponens pedig vízszintesen és függőlegesen történő (Cb, Cr) mintavételezéssel áll elő. Egy képet így egész számú szeletekre (slices) lehet bontani.

A H.264 video stream diszkrét csomagokból épül fel, ún. NAL-okból (Network Abstraction Layer).
/Talán furcsának tűnik a NAL egységek használata, de ennek segítségével csomagorientált multiplexelt környezetben vagy byte-stream alapú hálózatokon is használható a szabvány. Az Annex B (B melléklet) hivatott meghatározni a NAL egységek byte-stream alapú hálózatokon történő átvitelét, ha valakit érdekel a téma. Itt most ezzel nem foglalkozok mélyebben. Talán egy későbbi cikkben visszatérhetek rá, ha van igény erre./
Minden slice egy vagy több NAL-t tartalmazhat. A NAL-oknak több típusa van. Ilyen a header, jelzés, hozzáadott adat. Egy normál stream egy kerete egy szeletet (slice) és egy NAL-t tartalmaz, ám ez a dekódoláskor egy egész keret elvesztését is eredményezheti, ha valamilyen hiba lép fel.

A H.264 engedélyezi az interlaced enkódolást is. Ebben a módban minden keretet két részre osztunk és vagy térbeli vagy időbeli interleaving-gel enkódolunk. A színes képek kódolására az YCbCr-t használunk (mint az előző szabványok esetében is), ami azt jelenti, hogy a képet luma (fényerő) és chroma (szín) síkokra osztjuk fel.

A H.264 több slice típust határoz meg. Ezek:
- I slice: „Intra” szelet, ami egy teljes állóképet ír le, de önmagára csak hivatkozást tartalmaz. Egy stream állhat ugyan csupán I szeletek sorozatából, de nem használatos, viszont minden stream első keretének I szeletnek kell lennie.

- P slice: „Predicted” szelet, amely egy vagy több, már kódolt keret alapján építi fel egy képet, mintegy előre jelezve annak tartalmát (prediction). Nem feltétlenül az aktuális képet tartalmazza, mert ún. „maradékot” (residual) is adhatunk még hozzá, erről szintén később lesz még szó.

- B slice: „Bi-deirectional Predicted” szelet. Hasonlóan működik, mint a P slice, ám ebben az esetben már esetleges „jövőbeli” I és P szeletek is használhatóak referenciaként. Két mozgásvektort használ többnyire minden blokkhoz. Használatának feltétele, hogy később kódoljuk, mint a következő I és P szeleteket.

- SI és SP slice: Nem használatosak, video stream-ek közötti átjárást biztosítanak.

Az SPS (Sequence Parameter Set) és a PPS (Picture Parameter Set) tartalmazza az alap stream fejlécét (header). Ezek a paraméter beállítások a saját NAL-jaikban tárolódnak és mindenek külön azonosítója van, ezért a H.264-ben egyszerre több stream-et is használhatunk. A fejlécek nagyon fontos információkat tartalmaznak.

Az SPS főbb paraméterei:
- Profil és szint (level) jelzés - a H.264 Annex A (A melléklet) szerint meghatározott profil/szint kombinációk szerint.
- Információ a képelrendezés dekódolási eljárásáról.
- Hivatkozott keretek száma
- Az előforduló levágásról információ, engedélyezve a nem csak 16 többszöröseiben meghatározott keretméretet.
- VUI (Video Usability Information) információk – képarány, színséma. (Annex E)

A PPS főbb paraméterei:
- Entropy coding módját jelző flag.
- Információ a slice felosztásáról (partitioning) és a macroblock-ok elrendezéséről.
- Max. hivatkozási kép lista index
- Súlyozott prediction – bi-directional prediction – használatát jelző flag
- Luma/chroma quantization paraméter offset és más kezdő quantization paraméterek
- Inter-predicted macroblock használatát jező flag (kényszerített intra előrejelzés).

Chroma subsampling

A kép tömörítésénél információt vesztünk, de hogy ez ne legyen feltűnő, olyan információt kell találnunk, ami nem zavaró az összkép és a minőség szempontjából. Mivel szemünk érzékenyebb a fény (luma) változására, mint a színek (chroma) változásaira, ezért a tömörítés során a színeken lehet spórolni. Minden pixelnek eltároljuk a fényerejét, de a színét nem mindegyiknek tartjuk meg. Az eltárolás gyakoriságát számkóddal jelöljük. Az első szám azt mutatja meg, mekkora pixelblokkra vonatkozik a másik kettő. A második azt jelzi, hogy egy ilyen blokkban vízszintesen hányszor tároljuk el a színeket. A harmadik általában ugyanaz, mint a második, vagy nulla, ha a függőleges mintavétel feleakkora.

- 4:1:1. A szám azt jelzi, hogy 4 pixelből álló blokkunk van és minden negyedik pixelnek tároljuk le a színét. Ezt használják az NTSC DV tömörítésnél.

- 4:2:2. Itt már 2 színértéket tárolunk 4 képpontonként.

- 4:2:0. Itt már vertikálisan is nézzük a pixeleket és egy 2x2-es blokkhoz tárolunk 1 színértéket. A PAL DV tömörítés és az MPEG2 használja a DVD-ken.

- 4:4:4. Minden képponthoz tartozik szín- és fényerőérték is, nincs tömörítés.

Az eljárás szemléltetésére itt egy kép, ami segíthet a megértésben: LINK

Prediction

A prediction becslés, előrejelzés más, már enkódolt információk alapján az aktuális adathalmazra. Jobban körüljárva a módjait érthetőbbé válik a jelentősége.

1. Intra prediction

Intra kódolásnál a képen belüli térbeli redundanciákat használjuk ki. Mindenképp ezt kell alkalmaznunk, ha egy bitfolyam kezdőképét kódoljuk, hiszen ekkor még nincs előző keret. Az alapesetben létrejövő I-picture (I-kép) különböző macroblock-jaira közvetlenül alkalmazzuk a transzformációt, ami nagyméretű adathalmazt hoz létre. A H.264 bevezette a szomszédos blokkok viszonyára alapuló intra kódolást. Ennek lényege, hogy az aktuális blokk fölötti és baloldali szomszédját, ami már enkódolva van, veszi alapul (P blokk) és az alapján csupán a már feldolgozott és az aktuális közötti különbség lesz letárolva (residual). A P blokk tulajdonképpen vehető előnézetnek is, amit a már kódolt blokkokból képeztünk.

Az Intra kódolásnak három alapesete lehetséges:
- Teljes MB (macroblock) prediction 16x16 luma vagy chroma blokkmérethez
- 8x8 luma prediction (a FRExt kiterjesztés óta használható)
- 4x4 luma prediction

4x4 luma prediction

4x4 pixel méretű luma blokkokat használ. A prediction alapjai a bal oldali és a fenti szomszédos pixelek lesznek. A szabványban meghatározott 9 útvonal (0-8) bejárásával valósul meg az aktuális kép előrejelzése. Az útvonalakat a következő ábra mutatja:

Az enkóder kiválaszthatja a prediction mode-ot, hogy ezzel is csökkentse a különbséget (residual) a P blokk és a kódolandó blokk között. A SAE (Sum of Absolute Errors), az összes abszolút hiba összege, alapján eldönthető, melyik mód eredményezte a legkevésbé eltérő blokkot.

16x16 prediction

Ennél a módnál full MB előrejelzésről beszélünk. Alkalmazhatunk luma vagy chroma prediction-t is, de chroma mindig csak 16x16 lehet (4:4:4), mert a többinél már más formátumú lesz – 8x8 chroma 4:2:0 MB, 8x16 chroma 4:2:2 MB lenne.

A 4x4-hez képest itt négy mód közül választhatunk:
- Mode 0: vertikális, a felső minták alapján működik
- Mode 1: horizontális, a bal oldali minták alapján működik
- Mode 2: DC, átlagol
- Mode 3: „plane”, átlósan veszi mindkét szomszédos blokk mintáit.

A 16x16 mód ideális homogén, kevésbé változatos területekre, mint hátterek, ég, hasonlók.

8x8 luma prediction

A FRExt kiterjesztés megalkotásával került be az addigi módok közé. A 4x4 módhoz teljesen hasonlóan működik, viszont a nagyobb blokkmérettel a teljesítmény növelhető.

Mikor melyik módot használjuk?

Azt érdemes tudni, hogy az intra módok közül a 4x4 fogja a legnagyobb mennyiségű adatot produkálni és ebben a módban elég szoros a blokkok közötti viszony. Ha például egy blokkot két olyan blokkból becslünk meg, amelyek 2-es módot használtak, akkor erre a blokkra is 2-es mód lesz érvényben.
Minden aktuális blokkhoz meghatározható (a dekóder és enkóder által) egy most_probable_mode (legvalószínűbb mód), ami a környező blokkok alapján, azok minimumát fogja alkalmazni a módok közül. Ha ez a flag ki van kapcsolva (értéke 0), akkor a remaining_mode_selector lép érvénybe, ami, ha az előző paraméternél kisebb, akkor ez fog érvényesülni, különben eggyel növelt értéke.

2. Inter prediction

Az inter prediction a motion estimating (mozgásbecslés) és a motion compensation (mozgáskompenzáció) felé mozdul el. Itt már nem egy kereten belüli blokkokat, hanem keretek közötti viszonyokat figyelünk. A lényeg az egyes keretek közötti átmenet.

Fa struktúrájú mozgáskompenzáció

Az AVC a 16x16 blokkmérettől egészen a 4x4-es luma mintaméretig engedélyezi a mozgáskompenzációt. Egy MB luma komponense 4 féle módon osztható fel, amik szintén tovább oszthatóak.

Minden terület egy-egy saját mozgásvektort (motion vector - MV) követel meg és minden vektort kódolni kell. Ha nagyobb területeket választunk, kisebb lesz a vektor mérete, de a residual sokkal több eltérést tartalmazhat. A kisebbeknél az eltérés jóval kisebb lehet, de akkor viszont több mozgásvektort kell átvinni, vagyis nagyobb adathalmazt kell kódolni ezekből. A területek megválasztása jelentős befolyással bír a tömörítésre. A nagyobb partíciókat akkor érdemes használni, ha a képrészlet nagy része homogén és a részletgazdagabb területekre kell kisebb területeket kijelölni.
A chroma (Cb és Cr) komponensek ugyanúgy osztódnak fel, mint a luma, de pont fele lesz a méret, mint az előzőnél, mert a komponens is pont fele lesz. Tehát egy 8x4-es luma mellé egy 4x2-es chroma fog társulni. Épp emiatt, ha a chroma komponenst is alkalmazzuk, akkor a mozgásvektorok is feleződnek.
Az AVC ki tudja választani a „legjobb” partícióméretet automatikusan, hogy a lehető legkevesebb legyen a residual és a vektorok mérete. Erre egy példa a következő kép:

Sub-pixel mozgásvektorok

Minden kijelölt rész a hivatkozott keretből ugyanilyen méretű felosztását becsüli meg az aktuális keretnek. Az eltolódás a kettő között (mzgásvektor) ¼ pixel a luma komponensnél. A luma és chroma komponensek a hivatkozott képen ezekben az al-pixel pozíciókban nem létezik, ezért ezeket a környező képpontok alapján be kell szúrni oda. Ez a módszer növeli ugyan az összetettséget, de jobb tömörítést biztosít, mint a fél- vagy egész-pixel megoldások. Ha a forrás video 4:2:0 mintavételezést tartalmaz, akkor 1/8 pixel mintákat kell alkalmazni a chroma komponensek esetében, amik a luma komponensekhez hasonlóan interpolálódnak a környező minták alapján.

Motion vector prediction

A mozgásvektorok enkódolása megnöveli a feldolgozandó bitek számát, ám sokszor nagyban hasonlítanak a szomszédos vektorokra. Egy előrejelzett vektor (MVp - predicted) egy másik, már kiszámított vektor alapján jön létre ezért elegendő az aktuális és a predicted közötti különbséget (MVD) kódolni és átvinni. Nyilván a predicted függvénye a motion compensation (MC) partícióméretének és a rendelkezésre álló környező vektoroknak. Az „alap” vektor a MB vektorainak mediánja. Ha valamiért az adott MB nem vihető át (skipped), akkor létrejön egy MV, ami egy általános16x16 felosztású MB-hez tartozik és azt visszük át.

A következő részre még maradt egy kis elmélet, de utána gyakorlati dolgokat fogok majd írni a használattal kapcsolatban.