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 4x4-es transzformációs méret a 8x8 mellett, ami a kisebb méretből adódóan kevesebb hibát eredményez a minőségben.

A macroblock mérete maradt 16x16, de ez felosztható4x4 vagy 8x8 blokkokra, amikhez T4x4 vagy T8x8 mátrixokat rendelhetünk. A 8x8 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 8x8 IDCT esetén.

Egy 16x16-os intra prediction blokk minden 4x4-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. Működésének lépéseit a következő ábra mutatja:

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 4x4 és minden 8x8 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: 720x576.

--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á!