Mpeg4 h.264

A H.264/AVC a HD térhódításával nagy népszerűségre tett szert. Kiváló minőség érhető el vele és nagyon rugalmas. Többnyire mkv konténerben találkozhatunk vele, a HD lemezek rippelt verzióit letöltve, de trailer-ek, demók, saját készítésű videók sokasága is használja már ezt a remek szabványt. Megpróbálom kicsit összefoglalni, bemutatni érdekességeit, hatékonyságának kulcselemeit és rávilágítok arra, hogyan lehet felhasználni saját videók készítéséhez. Több részre osztom a cikket, így egy-egy fontos részt bővebben taglalhatok és talán áttekinthetőbb is lesz a struktúra.

Történelem, tények és számok – általános bevezető

A H.264 az ITU-T (International Telecommunication Union) telekommunikációs szabályozási területe „ajánlása” (szabványa, csupán a megnevezés ajánlás). Az ITU rendszerében a H (Audiovisual and multimedia systems) Audiovizuális és multimédia rendszerek kategória 264-es számú ajánlása (Advanced video coding for generic audiovisual services). Innen ered az elnevezés is: H.264.

Az MPEG-4 szintén egy szabvány, mégpedig videotömörítésre, olyan kiterjesztésekkel, mint az XviD vagy a DivX (Part 2). Ennek a 10-es része (Part 10) kifejezetten a HD (High Definition) videókra, az otthoni házimozik egyik alkalmazási területére koncentrál. MPEG-4 AVC néven is ismert, ami a JVT (Joint Video Team) alkotott meg több szervezetből tömörülve eggyé. Az MPEG-4 Part 10 alapvetően ISO/IEC szabvány, amit az ITU-val közösen alkottak meg. Közelebbről nézve a dolgot, a VCEG (Video Coding Experts Group), az ITU-T részéről és az ISO/IEC mozgóképpel foglalkozó egysége, az MPEG (Moving Picture Experts Group) fejlesztették ki. Jelen írás tehát egészen pontosan a következőkkel foglalkozik: ITU-T Recommendation H.264 | ISO/IEC International Standard ISO/IEC 14496-10 video coding. Mint látható, nemzetközi szervezetek fogtak össze a szabvány kidolgozására, de vajon miért volt erre szükség?

A 90-es évek elejétől kezdve felgyorsult a technológia, sorra jöttek az új hardverek, szoftverek és ezekkel együtt a video kódolás is fejlődésnek indult. Egymás után készültek el az újabbnál újabb szabványok, amelyek a mai napig érvényben vannak. Ezek: H.261, MPEG-1, MPEG2/H.262, H.263, MPEG-4 (Part 2). A H.264/AVC az egyik legújabb ilyen fejlesztés. A fejlesztők a kódolási hatékonyság, a komplexitás és az ár legjobb kombinációját próbálták megtalálni a VLSI technológiára alapozva.

Pályafutása 2000 körül kezdődött, az ITU-T H.26L projekten belül, amit a VCEG indított még 1998-ban. Az ISO/IEC MPEG csoportja 2001-ben készült el az MPEG-4 Part 2 szabványukkal és publikálás után mindkét tömörülés felfedezte, hogy hasonló cipőben járnak, ezért egyesítették erőiket, hogy befejezzék a szabványt. Számos teszt és kísérletezés után a már a H.26L projektben is megfogalmazott alapelveket kibővítve meghatároztak néhány következtetést az egész munkára vonatkozóan.

– Az addig szokásos DCT (Discrete Cosine Transform) kódolási sztenderd alkalmazása nem szükséges a mozgáskompenzációra, így új alapokat kell felépíteni.

– Költségelemzések és komplexitási vizsgálatok után ráébredtek, hogy a régen is alkalmazott kódoló eszközök, alkalmazások már nem elég hatékonyak, főleg a miatt sem, hogy ekkorra a VLSI fejlődése rohamossá vált.

– Szakítani kell a visszafelé kompatibilitás ábrándjával, ha növelni akarják a kódolás hatékonyságát és az új szintaxisnak teljesen függetlennek kell lennie az előzőektől.

Ez az egyesülés felgyorsította a fejlesztést és a H.26L alapjain meg is kezdődött a munka, megalakult a JVT 2001 végén. 2003-ra zárták le a projektet és rögtön be is vezette mind az ITU-T és mind az ISO/IEC szabványai közé. Ekkor kisebb káosz alakult ki, mert legalább 6 féle elnevezés keringett ugyanarról a dologról – H.264, H.26L, ISO/IEC 14496-10, JVT, MPEG-4 AVC és az MPEG-4 Part 10. Legelterjedtebb neve a H.264/AVC lett. Ezt követően a JVT neki is látott a kiterjesztések, mint a FRExt (Fidelity Range Extensions) kidolgozásának, ami magasabb felbontást, jobb minőséget és még sok mást tett hozzá a szabványhoz. Több kiterjesztés készült, amiknek köszönhetően bekerült az alap profilok mellé még öt új és több opcióval bővítették az eredeti elképzeléseket.

Manapság a HD egyre nagyobb népszerűségre tesz szert, amihez jelentősen hozzájárul, hogy az ilyen tartalmak kódolására, dekódolására készülő eszközök jobbak, gyorsabbak és megfizethető árat kezdenek elérni, ezzel mind szélesebb réteg előtt tárva ki a lehetőség ajtaját. A HD és az SD (Standard Definition) abban nem különbözik, hogy hogyan érhető el. Maga a média elérhető adathordozókon, rögzített tárolókon, letölthető formában. Ami viszont lényeges különbség, hogy drámaian megnövekedett a minőség. Ez viszont bizonyos dolgokban egészen nagy különbségeket eredményez a két technológia között:
– Nagyobb adathalmazt kell feldolgozni, ami akár hatszor több renderelést igényel, mint az SD esetében.

– Sokkal összetettebb algoritmusokat használ a dekódolásra (pl.: CABAC) és a lejátszásra (de-interlacing)

– Megnövekedett az energiaigény ezen folyamatok kiszolgálására (laptopok esetében lényegesebb és a hordozható eszközöknél)

– Más adatvédelmi eljárásokat kell alkalmazni

Az SD tartalmak, mint a DVD sokkal kevesebb pixelt tartalmaznak, mint a HD-sek. Az alábbi táblázat mutatja, hogy mennyivel több pixelt kell renderelni egy HD film esetében, mint egy hagyományos DVD-t nézve.
1. Forrás: ATI

Ugyanígy a bitráta is nagyban eltér az eddig alkalmazott DVD-k esetében alkalmazottaktól.

Látható, hogy akár négyszer nagyobb is lehet egy Blu-Ray bitrátája, mint egy DVD-é. A hatékonyabb, de jóval bonyolultabb kódolási eljárások azonban erősebb hardvert követelnek, mialatt sokkal jobb tömörítési arányt érnek el az MPEG-2-nél jobb minőségben, összehasonlítva azzal.

A több magot tartalmazó processzorok, az egyre fejlettebb, hardveres dekódolási képességekkel is bíró videokártyák (UVD2, Purevideo HD), az egyre nagyobb sávszélességű memóriák jóvoltából a HD nagyon nagy népszerűségnek örvend, ami a H.264 enkódolására és dekódolására létrehozott szoftverek, interop-ok, frontend-ek gombamód szaporodásán is látszik.

Láthatjuk tehát, hogy a H.264 a gyakorlatban, összehasonlítva az MPEG-2-vel vagy az MPEG-4 Visual-lal ugyanazon a bitrátán jobb minőséget eredményez és kisebb bitrátán is tudja ugyanazt a minőséget produkálni. Például egy DVD-n kb. 2 órányi MPEG-2 fér el, amíg H.264-et használva ez akár 4 órányi anyag is lehet, ugyanolyan minőségben. Ennek a hatalmas javulásnak azonban ára is van. A H.264 sokkal számításigényesebb, mint elődei. Kifinomultabb tömörítési eljárásai többet követelnek meg a hardvertől és szoftvertől egyaránt.

Alkalmazási lehetőségei igen széles skálán mozognak, rugalmasságának köszönhetően. A televíziózásban egymás után állnak át a csatornák a HD adások sugárzására, de terjednek a HD formátumú DVD-k is (Blu-Ray), a jó tömörítési arányt kihasználva megjelent a formátum a hordozható eszközökön is, valamint alkalmas videokonferenciák, internetes tartalmak átvitelére és természetesen a hadászatban is alkalmazzák.

A következő írásban már kicsit részletesebben belemegyünk a szabvány metódusainak működésébe és sematikusan áttekintjük, hogyan is érhető el nagyon jó minőségű kódolás.

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 16×16 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 2×2-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 16×16 luma vagy chroma blokkmérethez
– 8×8 luma prediction (a FRExt kiterjesztés óta használható)
– 4×4 luma prediction

4×4 luma prediction

4×4 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.

16×16 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 16×16 lehet (4:4:4), mert a többinél már más formátumú lesz – 8×8 chroma 4:2:0 MB, 8×16 chroma 4:2:2 MB lenne.

A 4×4-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 16×16 mód ideális homogén, kevésbé változatos területekre, mint hátterek, ég, hasonlók.

8×8 luma prediction

A FRExt kiterjesztés megalkotásával került be az addigi módok közé. A 4×4 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 4×4 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 16×16 blokkmérettől egészen a 4×4-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 8×4-es luma mellé egy 4×2-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.

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.

Az elméleti rész befejezése után az eddigiek gyakorlati hasznával is foglalkozunk, hogy végre tiszta legyen a kép. Megpróbálok nem elveszni a matematikai és kódelméleti dolgokban… remélem, sikerül is.

A kép összeáll

Láthattuk az előző észben, hogy egy kereten belül és más keretek felhasználásával is kódolhatunk. Maradjunk még egy kicsit ennél a témánál.

Transzformálás, digitalizálás (transform, quantization)

Nem újdonság egyik lépés sem a kódolásban, de van néhány dolog, amiben a H.264 az első. Az transzformáció és az inverz transzformáció is integer (egész szám) alapú lett az eddigi idealizált trigonometrikus módszerek helyett. Ennek legnagyobb előnye, hogy így nem lesznek eltérések az enkódoló és a dekódoló között a kerekítések miatt. Támogatott lett a 4×4-es transzformációs méret a 8×8 mellett, ami a kisebb méretből adódóan kevesebb hibát eredményez a minőségben.

A macroblock mérete maradt 16×16, de ez felosztható4×4 vagy 8×8 blokkokra, amikhez T4x4 vagy T8x8 mátrixokat rendelhetünk. A 8×8 transzformáció csak a már amlített FRExt kiterjesztéssel jött, de komplexitása még így is kisebb, mint a hagyományos 8×8 IDCT esetén.

Egy 16×16-os intra prediction blokk minden 4×4-es luma blokk DC együtthatója másodlagosan egy Hadamard transzformáción megy át. Chroma esetén minden mintát így kódolnak. A lényeg, hogy a transzformálás után minden együttható előáll, amit viszont digitalizálni (quantization) kell (nem a legjobb kifejezés, de ez áll a legközelebb az angol jelentéshez.) egy ún. quantization control paraméter segítségével, amit minden MB esetén módosíthatunk. A paraméter 52 lehetséges értéket vehet fel az alap 8 bit/dekódolt minta felállásban, amit a FRExt még plusz 6 lépéssel megnövelt, köszönhetően a nagyobb bitmélységnek. A lépésköz a H.264-nél nem egyenesen arányos a paraméter értékével, mint más szabványoknál, hanem növelésenként változik.

Entrópia kódolás (Entropy coding)

A kifejezés annyit takar, hogy lehetőleg veszteségmentesen helyettesítsük az adatot annak kódolt előfordulásával a prediction, transzformáció és a quantiztion alapján, az adat méretének csökkentésével. Alapvetően két módja létezik: a VLC (Variable Length Coding) és a BAC (Binary Arithmetic Coding). A H.264-ben mindkettőnek definiálták a környezethez alkalmazkodó (Context Adaptive) változatát is, létrehozva a CAVLC és a CABAC módokat.

VLC, UVLC, CAVLC

Az alapötlet a VLC-hez a következő: minden adatelem eltérő gyakorisággal tűnik fel kódoláskor, így a sűrűbben előfordulókhoz rövidebb kódot, míg a ritkábbakhoz hoszabb kódot rendelünk. Ezt az eljárást nevezik Huffman kódolásnak (aki jártas a kódelméletben, ismerheti is) és a Huffman a legismertebb típusa a VLC-nek. A szintatikai elemkek közül azokat, amelyek nem tartoznak a residual paramétereihez, egy ún. UVLC (Universal VLC) eljárás kódolja Ex-Golomb kódolással, mivel általában ugyanazokat a változókat takarják minden kódolásnál. A residual kódolására 12 táblát definiáltak a hatékonyság növelése érdekében. Ezek mérete, a választás közöttük az aktuális környezettől (context) függnek a CAVLC használatakor, ami növeli a hatékonyságot és a gyorsaságot, mert nem lesz túlzottan összetett a kódolás.

CABAC

A CABAC tömörítésben kb. 10%-ot hoz a CAVLC-hez képest, ám jóval összetettebb annál, így nagyobb számítási teljesítményt igényel.

Első lépésként a környezetre jellemző modellt választ, miután feltérképezte a szintaxis elemeit. Minden elemtípushoz (mozgásvektor, transzformációs együtthatók, stb.) más modellt kell alkalmazni. Ha egy érték nem bináris érték, akkor úgynevezett „bin”-ekbe mapp-eli ezeket az értékeket a könnyebb felhasználás érdekében. Ha ez kész, előáll a bináris fa és kész a binarizáció (a VLC is használ ilyen fát). Ezután minden bin-t a BAC motor enkódol az előfordulási valószínűségének vizsgálata után (probability estimation lépés). Minden környezethez, amit az elején választ az eljárás, előre beállított becslő (estimation) paraméterei vannak. Ha az enkódolás megtörtént, akkor frissíti a valószínűségét az éppen kódolt elemnek az előző lépéshez, ezzel statisztikát vezetve minden elem előfordulásáról.

Matematikai és kódolási szempontból az entrópia kódolás ennél többet hordoz magában, de itt most erre nem térnék ki helytakarékosság és az érthetőség megtartása miatt.

Kicsit inkább vegyük jobban szemügyre a B-slice-eket. Azt ugye már megállapítottuk, hogy ezek csakis inter prediction esetén érdekesek, hiszen külön kereteket használ és már azt is tudjuk, hogy két irányban is kereshetnek hivatkozási kereteket maguknak. Erről az előző részben volt szó. Két mozgásvektort használ és két becslést készít az adott MB részhez vagy sub-MB részhez időbeli becsléskor a „jövő” és a „múlt” felhasználásával. Vegyünk egy példát.

A video első kerete I-frame lesz, mivel mé nincs másik, amit referenciaként felhasználhatnánk. Ezt követi egy P-frame, ami az első alapján már használható, majd egy B és egy újabb P. Így a B-keretünk mindkét mellette lévő P-frame-et hivatkozásnak tekintheti, ezért nevezzük kétirányúnak (bidirectional). A szabvány azonban ennél is tovább megy. Egy B-frame maga is lehet hivatkozás, vagyis multi-reference is létrejöhet. Egy keret több másikból vehet mintát, miközben maga is lehet hivatkozás. Az alábbi kép egy másik lehetséges „forgatókönyvet” mutat be.

Deblocking (Loop) Filter

Szót kell még ejtenünk erről a filterről, ami a minőséget nagyon nagy mértékben meghatározza. Ahogy a neve is sugallja, a blokkokkal van összefüggésben. Minden blokk szélén a szomszédos pixelek tartalmazhatnak hibákat, amik olyanok lesznek a képen, mintha kis tüskék állnának ki egyes részeken a képből. Ezeket szűrni kell és erre találták ki a deblocking filtert. Ha a quantization step-et megnöeljük, nagyobb lépésközzel digitalizálunk, a filter veszít hatékonyságából, ha viszont túl kicsi, a filter kikapcsolja önmagát.

Profilok, szintek (level)

A szabvány alapjában véve három fő profilt határoz meg:
• Baseline Profile
o I/P slices
o Multiple reference frames
o In-loop deblocking
o CAVLC entropy coding

• Main Profile
o Baseline Profile elemei alapvetően
o B slices
o CABAC entropy coding
o Interlaced coding – PAFF/MBAFF
o Weighted prediction – egyfajta súlyozás annak érdekében, hogy a residual mérete még kisebb legyen. Globális változókat alkalmazhatunk mozgáskompenzációnál, így nem kell többször ugyanazt átvinnünk.

• High Profile
o Main Profile elemei alapvetően
o 8×8 transform option
o Custom quantization matrices – ezek olyan felhasználók által készíthető mátrixok, amelyek felülírják az alap quantization metódust. Lényegében bizonyos médiatípusokhoz lehet optimalizálni őket.

Ezeket egészítette ki a FRExt 4 új profillal, amelyet a wikipédia szépen leír.

A Main és a High azok, amelyeket az átlag, pc-n nézendő filmek enkódolására használunk, Baseline profilt alkalmazhatunk mobil eszközökre való kódoláskor és ha nagyon profi dolgot akarunk véghez vinni, akkor merhetünk nekiállni a magasabbaknak, már van hozzá megfelelő vasunk is… 🙂

A szinteket (level) tekintve inkább nem foglalnám a helyet velük, mert a wikipédián elég részletesen össze vannak szedve a jellemzőik. Annyit mindenképp érdemes tudni, hogy a 4 és 4.1-es szintek, vagyis a HD formats jelölésűek azok, amelyeket valóban ki tudnak használni az ATI és nVidia kártyáinak hardveresen gyorsító megoldásai.

Sok dolgot lehetne még részletesebben magyarázni és még jó néhány dolgot lehetne egyáltalán megemlíteni, mint a szín transzformációt, hibakiküszöbölési módszereket, stb., de ezt most nem teszem. Ha van igény ilyesmire, akkor szívesen írok még a témában, de most inkább térjünk át a gyakorlatra.

Enkóderek, opciók, CLI

A H.264 szabványra épülő legismertebb és legjobb enkóder az x264 (http://x264.nl/ ). Ez egy apró command line alkalmazás, ami első ránézésre használhatatlannak tűnhet, de nagyon is használható. Rengeteg frontend, GUI készült már hozzá, amelyek, kiegészülve a konvertáláshoz is szükséges alkalmazásokkal, dll-ekkel már teljes értékű enkódoló, konvertáló programokká lettek.

Két féle alkalmazás van a neten: a modulárisak és az all-in-one, egybe építettek. A modulárisak összegyűjtik a kódoláshoz szükséges alkalmazásokat, dll-eket és ezekhez adnak közös felületet, míg a másik csoportba azok a szoftverek tartoznak, amelyek maguk képesek minden művelet elvégzésére. A modulárisak általában a következőket igénylik, telepítik: x264, Nero AAC encoder, BeSweet, mp4box, AviSynth, ha több funkciósak.

Néhány szóban be is mutatnék néhányat:

StaxRip: ez a kiváló alkalmazás nem csupán x264 kimeneti formátumot tud, hanem XviD és DivX formátumokat is MKV, AVI, MP4, DIVX konténerekben. Moduláris felépítésű, ám telepítéskor mindent frissít, telepít illetve ellenőrizhető, hogy mindenből a megfelelő verzió van-e meg. Előnye, hogy open source alkalmazás, tehát ingyenes és még a forrást is megosztják velünk. Kezelése nem bonyolult. Elérhető itt: http://planetdvb.net/staxrip

MeGUI: szintén nyílt kódú alkalmazás, a moduláris kategóriából. Rendkívül népszerű, kezelése egyszerű. Elérhető itt: http://sourceforge.net/projects/megui

AutoMKV: ez az első kategóriába tartozó alkalmazás az előbb említettekhez hasonlóan egyszerű, egész sok beállítási lehetőséget ad és a profilok is könnyen szerkeszthetőek benne. Szintén ingyenes szoftver. Elérhető itt: http://automkv.a.wiki-site.com/index.php/Main_Page

MainConcept™ H.264/AVC Pro: a MainConcept cég vérbeli profi a codec-ek terén. Saját codec SDK-t is fejlesztettek, amit a kihívást kedvelők ki is próbálhatnak. H.264 enkóderük szintén a profizmust tükrözi. Alkalmazásuk az 5.1-es level-t is ismeri, amivel már 288 Mbps is elérhető és támogatják a több CPU-s rendszereket. Sajnos egy ilyen program már nem ingyenes, de érdemes kipróbálni. Ez már a második kategóriába tartozik, mindent egymaga végez. Elérhető itt: http://www.mainconcept.com/site/prosumer-products-4/h264avc-pro-20178/information-20198.html

HandBrake: kissé furcsa neve ellenére igen komoly tudással bíró enkóder alkalmazás. Érdekessége, hogy command line és GUI is rendelkezésünkre áll. Ingyenes, de nem moduláris program. Kezelése egyszerű. Elérhető itt: http://handbrake.fr/

Nos, az alkalmazások bemutatása után nézzük mindennek az alapját, az x264-et, illetve ennek enkódolási opcióit. A következőkben lesz igazán hasznos, amiket eddig írtam, mert maguk a paraméterek és ezek értékei önmagukban nem túl beszédesek. Ezek többsége a GUI-kon meg is jelenik és szerkeszthető vagy egy xml-ben tárolódik és azt megnyitva lehet szerkeszteni.

Álljon itt először a hardveres támogatás (DXVA) előfeltétele mind HD, mind SD VGA által hardveresen támogatott tartalmakra vonatkozóan. Itt most nem egy opciót, hanem a használathoz szükséges és legoptimálisabb beállításokat vázolom.

Az x264 általános hívása:
x264 [opciók] –o „kimeneti fájl” „bemenő fájl” [szélességxmagasság]

HD tartalmakhoz:

–level 4.1 –ref 4 –mixed-refs –bframes 3 –b-pyramid –b-rdo –bime –weightb –direct auto –filter -2,-1 –subme 6 –trellis 1 –partitions p8x8,b8x8,i4x4,i8x8 –8x8dct –me umh

–level 4.1 -> egyértelmű, level 4.1-et fog használni.

–ref 4 -> 4 referencia kerettel fog dolgozni legfeljebb. Nem érdemes magasra tenni, mert lassul a kódolás, igaz, javul a minőség. Általában 3-5 ajánlott, de ott, ahol sok az ismétlődés (pl. animációk), használhatunk 8-at is akár.

–mixed-refs -> nagyobb kontrolt ad a hivatkozások tekintetében. Akkor érdemes használni leginkább, ha magas ref értéket állítunk be. (ide példaként tettem be)

–bframes 3 -> I és P keretek között maximum hány B-frame álljon egymás után. 3 a leginkább javasolt érték. Ennél több nem szükséges.

–b-pyramid -> bekapcsolja az opciót, amely azt engedélyezi, hogy a b-frame-ek egymásra is hivatkozhatnak. Alapesetben kapcsoljuk be, ha 2 vagy több értéket adtunk meg a –bframes ’x’ paraméterben.

–b-rdo -> rate-distortion optimization bekapcsolása. Az RDO megkeresi intra és inter kódolás esetén a legjobb beállításokat az adott blokkhoz, kerethez. Minimum 1 B-frame használata szükséges.

–bime -> a prediction mozgás alapon történik a B-frame-ek használatakor, ha bekapcsoljuk. Érdemes mindig használni.

–weightb -> a súlyozott becslés használatát engedélyezi. Érdemes mindig bekapcsolni, növeli a hatékonyságot. Minimum 1 B-frame használata szükséges.

–direct auto -> a tömörítés hatékonyságát növeli, ha bekapcsoljuk. Lehetséges értékei: auto, spatial, temporal. Az auto használata javasolt, a többit nagyon ritkán használják.

–filter -2,-1 -> a loop filter-hez kapcsolódik ez a paraméter. Magát a filtert nem kell bekapcsolni, azt csak kikapcsolni lehet a –nf paraméterrel, de nem használatos egyáltalán, hogy kikapcsoljuk. Ennek a paraméternek a két értéke az erősség és a küszöbérték. Beállításával dől el, mit tekint ’block’-nak (hiba) az x264 és mit nem. Ha túl magasra tesszük, akkor mindent javítani akar, ami rontja a minőséget (elmosott lesz a kép). Alapesetben 0/0 az érték, ezt érdemes megtartani. Ha nem elegendő a minőség, akkor érdemes játszani a variációkkal. -2 alá és 3 fölé nem érdemes menni.

–subme 6 -> fontos beállítás, ami az enkódernek azt határozza meg, hogyan használja a motion estimation-t. Értéke 1 és 7 között lehet, de leginkább a 6 használatos. 1 a leggyorsabb, 7 a legjobb minőség.

–trellis 1 -> a minőséget javítja, de lelassítja az enkódolást. Érdemes kikapcsolva hagyni, hacsak nincs gyors gépünk és semmiképp nem használható 1 pass enkódolásban. Értékei: 0 (kikapcsolva), 1 (2 pass enkódolásnál használatos), 2 (legjobb minőség, de sokat lassít).

–partitions p8x8,b8x8,i4x4,i8x8 -> meghatározható, milyen MB partition-ok (felosztások) használhatóak adott keretekhez. Értékei: i8x8,i4x4,p8x8,p4x4,b8x8,all. All-t választva minden 4×4 és minden 8×8 eset használható lesz. Ha p4x4-et akarunk használni, akkor a p8x8-at is be kell írnunk.

–8x8dct -> Az előzőhöz kapcsolódik, de külön paramétert kapott. Ha az előbbieknéál i8x8-at is beállítottunk, akkor használható.

–me umh -> motion estimation method. Az egyes bitráták és kerettípusok szerint meghatározható a mozgásbecslés módja. Értékei: ‘dia’, ‘hex’, ‘umh’, ‘esa’. Dia: Diamond – a leggyorsabb sebességre törekszik a minőség rovására, hex: Hexagon – a sebesség még mindig fontosabb, de a minőség is megjelenik igényként, muh: Multi Hex – a leggyakoribb beállítás, balansz a sebesség és a minőség között, esa: Exhaustive – teljességgel felesleges beállítás, gyakorlatilag pixelenként számítja a mozgást, nagyon lassít.

SD tartalmakhoz:

–level 3.1 –ref 8 –mixed-refs –bframes 3 –b-pyramid –b-rdo –bime –weightb –direct auto –filter -2,-1 –subme 6 –trellis 1 –partitions p8x8,b8x8,i4x4,i8x8 –8x8dct –me umh

Egyebek:

Fontos: használjunk mindig multi-pass enkódolást, ha nem szeretnénk rossz minőséget kapni. 2 pass már elegendő pl.: egy turbo first pass kíséretében. Így az 1. folyamat gyorsabb lesz, de a minőség nem romlik.

–no-cabac -> Alapesetben CABAC entrópia kódolást használ az x264. Ha mégis szeretnénk CAVLC-t használni, akkor ezt ez az opció vezérli, de nem ajánlott.

–bitrate 2000 -> meghatározhatjuk a bitsebességet is, de ezt a GUI-k alkalmas textBox-aiban is megtehetjük.

–output „OutputFile.mkv” „SourceVideo.avs” -> összevontam a két paramétert, amelyek a bemenő és kimeneti fájlok elérési útját tartalmazzák.
A felbontást általában a ki/bemenő fájlok után adjuk meg, a következő formában: 720×576.

–cqmfile fájlnév -> ha saját quantization mátrixunk van (high profil-ban), akkor használhatjuk. Ilyenkor egy fájlban meg kell határoznunk a mátrixokat, például így:
INTRA4X4_LUMA =
6,16,22,28,
16,24,32,40,
22,32,48,72,
28,40,72,112

–progress -> folyamatjelzőt engedélyez kódolás közben. A frontend alkalmazások általában jól logolnak, nem kell küllön beállítani.

Nagyjából ezek azok a paraméterek, opciók, amiket leggyakrabban használunk kódoláskor. Olyan bevett beállítás, természetesen, nem létezik, amivel a legjobb minőséget kapjuk minden esetben, de általánosságban ezekkel jó minőség érhető el. A kódolási iső sok tényezőtől függ, mint láthattuk, de legtöbbször egy XviD enkódolása gyorsabban lefut. Mindenképpen érdemes megnézni pl.: a PH!-s teszteket, melyik CPU hogyan teljesít. Kijelenthető, hogy a videokódolás x264-gyel kihasználja már a 4 magot is! Átlagos akciófilmeknél, ahol sok a gyors mozgás, a fenti beállítások jól alkalmazhatóak és a bit rate elegendő 1200-1500 körül (esetleg 2000-ig el lehet menni). A teszteléshez érdemes max. negyed órás filmrészleteket használni a hosszú kódolási idő miatt. A felbontásokkal is el lehet játszadozni a mobil eszközöktől a HD-ig. Ehhez itt egy kis segítség:

Azt hiszem, ennyi jó tanács elegendő is ahhoz, hogy elkezdhesse mindenki próbálgatni az enkódert CLI módban vagy a GUI-kat. Remélem, nem lett összecsapott és nem hagytam ki semmi fontosat. Sok szerencsét hozzá!

Az információ forrása: logout.hu