Az előző írásokban már megismerhettük a H.264 enkódolására használatos x264 főbb opcióinak jelentését, használatát, most pedig megpróbálom kicsit összefoglalni, milyen forrásanyaghoz milyen beállításokat érdemes használni. Sorra veszünk még néhány hasznos opciót az x264 CLI paraméterei közül a még optimálisabb végeredmény érdekében. Egy jó tanács a kódoláshoz és a cikkhez: Einstein óta tudjuk, hogy attól függ! :)

Az x264 beállításai különböző forrástípusokra

Forrástípusok

Nyilvánvaló, hogy nem ugyanaz vonatkozik egy akció dús, mozgásban gazdag filmre, egy animációra vagy egy kevésbé részlet gazdag videóra. Éles határt nagyon nehéz lenne meghúzni és kategorizálni a különböző forrásanyagokat, erre nem is teszek kísérletet, hanem inkább csak bizonyos könnyen megkülönböztethető jegyeik alapján megnézzük, mivel lehet optimalizálni a kódolást ezekre a típusokra.
Tehát akkor nézzük a típusokat:

1. Gyors mozgás: ide tartoznak azok az akciófilmek, amelyek rengeteg gyors mozgást tartalmaznak, nagyon sok a vágás, átmenet, röviden, eseménydúsak. Akciófilmek, pörgős vígjátékok, a nem csak sötétben játszódó horrorok, néhány természetfilm kategóriája.

2. Lassú mozgás: kevés mozgás jellemzi ezeket a filmeket, néhány helyszínnel, sok homogén felülettel. Tipikusan drámák, a szinte csak sötétben játszódó filmek tartoznak ide, valamint a nem túl változatos képet nyújtó természetfilmek.

3. Animáció: nem nagyon kell ragozni, egyértelmű.

4. Zajos filmek: a dokumentumfilmek, amelyek eredeti felvételeket tartalmaznak, régi filmek, művészfilmek tartoznak ide, melyeknél a képek sok zajt tartalmaznak.
Nagyjából ezek a besorolások, de sokszor egyénileg kell eldönteni adott filmre vonatkoztatva, hogy milyen kategóriába is sorolhatóak, ám általánosan elmondható, hogy amilyen kategóriába illő jelenetből a legtöbb van, azt alkalmazhatjuk legnagyobb sikerrel.

Általános tippek

Első és legfontosabb, hogy az x264 nem XviD, DivX klón, teljesen más. Ha ezeknél már van egy bevett beállításmintánk, akkor azokra jók azok, de ne keverjük a kettőt. Fontos különbség, hogy az x264 esetében a minimum 2 menetes enkódolás indokolt a legtöbb esetben. Mit jelent ez?

A több menetes kódolás annyit tesz, hogy első menetben a kódoló végigmegy a forráson, készít magának egy logot, a beállított paraméterek alapján, hogy hogyan kódolna egyes részeket, felméri, hol mennyi a homogén felület, ahol nyugodtan lehet kisebb bitrátát alkalmazni minőségromlás nélkül és aztán a második menetben ez alapján már jól el tudja osztani a rendelkezésre álló bitrátát a tényleges kódolásnál. Egy menetes kódolást esetleg mobil eszközökre kódolásnál érdemes használni. Három menetes kódolást ritkán alkalmazunk, feljebb pedig szinte egyáltalán nem szokás menni. Már a három menet is nagyon megnöveli a kódolási időt.

A kódolási idő, sebesség mindig keresztmetszet és legtöbb esetben a minőséggel fordítottan arányos. A lényeg, hogy előre lőjük be magunknak, hogy kb. milyen minőséget szeretnénk elérni. A losslesss kódolás a leglassabb és a legnagyobb vasat igénylő mód, de tapasztalat útján lehet a későbbiekben már elsőre is jó arányt elérni különböző videóinkhoz.

Fontos még a tömörítés mértéke. Természetesen arra törekszünk, hogy elfogadható méret mellett a lehető legjobb minőséggel közelítsük az eredeti forrásanyag minőségét. Azt nem árt szem előtt tartani, hogy bár az x264 alkalmas nagyon kis méretben nagyon jó minőségre, azért nem kell túlzásba esni. Egy 2 órás anyagot nem ildomos 200 MB-ra tömöríteni, de lehet olyan beállításokat találni, amivel egy másfél órás mozifilm dvd-ről rippelve minimum olyan képet adhat 400 - 450 MB méretben, mint egy dupla ekkora avi.

Mint azt már az előző cikkben is említettem, ahhoz, hogy a DXVA-s, vagyis hardveres támogatással rendelkező VGA-nk előnyeit ki is tudjuk használni, az kell, hogy a Level 4.1-et használjuk a HD-s cuccainkhoz, ha meg SD videó a cél, akkor a Level 3.1-et.

Ha QuickTime kompatibilissé szeretnénk tenni a munkánkat, akkor néhány dologról le kell mondanunk. Ez nyilván az iPod-on való használatot is érinti. Tipikusan az mbaff és a b-pyramid opciók használatával már meg is törjük a kompatibilitást, de például akkor is, ha jelentősen eltérünk attól, amit a használni kívánt, amúgy kompatibilis, profil megkövetel.

Midig érdemes előre átnézni a forrást és megismerni a felépítését, megbecsülni, milyen jelenetekből van a legtöbb és az alapján kalkulálni. Esetleg kis sample részeket vághatunk ki a tipikus kereteket tartalmazó jelenetekből és azokon tesztelni, hogy rövidebb legyen a kódolási idő.

Kicsit konkrétabban a kódolásról

Először is kell valamilyen forrásanyag, amin tesztelhetünk. Ne válasszunk egy már tömörített videót, mert akkor nem biztos, hogy minden opció változásának hatását látni fogjuk. Nagyon jó mpeg2 példaanyagok találhatóak itt:
http://www.w6rz.net/

Ha már megvan a tesztalany, akkor lássunk is neki. 2 menetes (2 pass) kódolást fogunk alkalmazni, aminél mindkét menethez külön meg kell adnunk a beállításokat. Ez érthető is, hiszen nem pontosan ugyanazt végzik a menetek. Először menjünk végig az ismeretlen opciókon, aztán kielemezzük, mennyire jó vagy nem jó ez a beállítás.

Még egy fontos megjegyzés. Elnevezésben lehetnek különbségek a paraméterek között, vagyis vannak szinonimák, amiknek a hatása, értéke ugyanaz lesz, csak a nevük más.

Ezek a következők:
• deterministic == n-deterministic
• level == level-idc
• ref == frameref
• min-keyint == keyint-min
• filter == deblock
• analyse == partitions
• weightb == weight-b
• direct == direct-pred
• merange == me-range
• mvrange == mv-range
• mvrange-thread == mv-range-thread
• subme == subq
• b-rdo == brdo
• qp == qp_constant
• qpmin == qp-min
• qpmax == qp-max
• qpstep == qp-step
• ipratio == ip-factor
• pbratio == pb-factor
• cplxblur == cplx-blur

Sok gyors mozgást, átmenetet, vágást tartalmazó filmek

Tipikus akciófilmek. Gyors mozgás, sok, változó helyszín, jelenet, kevés homogén felület jellemzi ezeket. Alapos prediction, kis blokkméret, jól beállított szűrés szükséges hozzájuk. A jó minőség elérése sokszor a méret nagyobb mértékű növekedését eredményezi. Egy példán keresztül nézzük meg, milyen opciókat alkalmazhatunk sikerrel.

dchard fórumozó társunktól kaptam 1-2 minta cli beállítást, tesztelésünk alatt használjuk ezeket. Köszönöm utólag is. Néhány opciót még hozzáteszünk, néhányat átírunk.

Első menet (first pass):
x264.exe –pass 1 –bitrate xxxx –stats „.stats” –level 4.1 –bframes 3 –b-pyramid –direct auto –deblock -3:-3 –subme 1 –analyse none –aq-strength 0.5 –aq-sensitivity 13 –qcomp 1 –me dia –threads auto –thread-input –cqmfile „prestige_cqm.cfg” –progress –no-psnr –no-ssim –output NUL „xxxxx.avs”

Van pár dolog benne, ami magyarázatra szorul, de azért vegyük elő az előző cikket is, szükség lesz rá.

--pass 1 -> egyértelmű, first pass jelölése. Így tudjuk megkülönböztetni a meneteket egymástól. Értéke egy egész szám, ami az aktuális menet beállításaira vonatkozik.

--bitrate xxxx -> adott bitráta, értéke egész szám lehet (4 jegyű, ennél több értelmetlen lenne). Nem feltétlenül arányos a minőség javulása a bitrate növelésével, így egy 40Mbps forrást nem szükséges 20-30 körül kódolni, elegendő 10Mbps alatt maradni vele, mérettől és igénytől függően. Általában 2500Kbps alatt szoktunk dvdrip-eket készíteni.

--stats „stats” -> statisztikát készíthetünk adott fájlnévvel. Ez alapján dolgozik majd a második menet is.

--deblock -3:-3 -> a deblock filter erősségét lehet befolyásolni, eltolni vele. Alapbeállításként nem kell megadni egyáltalán, csak ha változtatni akarunk. Az esetek 99%-ában az alapbeállítás az indokolt és optimális megoldás a blokkosodás szűrésére. Ha mégis el akar térni valaki, akkor sem szabad nagy mértékben eltolni a szűrőt, mert ez biztosan romláshoz vezet.

-- analyse none -> az előző cikkben partitions néven volt említve.

--aq-strength 0.5 és –aq-sensitivity 13 -> Ezek az opciók nem részei az alap szabványnak, újabban kerültek bele, így lehetnek kompatibilitási problémák használatukkal! Quantization érzékenységet és erősséget lehet állítani velük, vagyis azt, hogy egy keret különböző részeit hogyan vizsgálja a kódoló. Pl. a blokkosodás csökkenthető a sima felületeknél. Általában a 0.5 és 10, valamint a 0.5 és 5 párost alkalmazzák, de sokan nem szeretnek 10 alá menni és 12-13 körül használják. Én nem szoktam használni, mert 2 pass kódolásnál kevés értelmét látom, főleg az elsőben. Az aq-strength értéke lebegőpontos és a sensitivity értéke pedig egész szám lehet.

-qcomp 1 -> a magas bitrátát és az alacsony bitrátát igénylő jeleneteknél a bitráta arányát szabályozza. A 0-s érték nem ajánlott soha, mert ez azt jelenti, hogy a bitráta konstans, ami a nagy igényű részeknél jelentősen ront, a kevés mozgású részeknél viszont pazarol. Alapértelmezésben 0.6, de leginkább 0.7 vagy 0.8 az elterjedt értéke. 1-nél már kicsit ésszerűtlenül közelít a konstans kvantáláshoz (QP).

--threads auto -> Több CPU esetén a szálak elosztásáért felel. Jobb nem bántani, az auto a legmegfelelőbb.

--no-psnr -> Bizonyos zajcsökkentési számításokat kapcsolhatunk ki/be ezzel az opcióval. Érdemes kikapcsolni (no-psnr). Időt és energiát spórolunk vele.

--no-ssim -> hasonló, mint az előző, ssim számítások kihagyása. Érdemes kihagyni ezeket is a kódolásból.

„xxx.avs” -> avisynth fájl elérési útja. Erről majd még lesz szó bővebben.

Első menetnek ez így egész jó, bár ebbe a menetbe nem kell --aq-strength 0.5 és –aq-sensitivity 13 értékeket beállítani. Így egy egész gyors első menetet kapunk, amit a GUI-kban sokszor turbo first pass-ként emlegetnek. Ennek tipikus elemei:
–subme 1–ref 1 –analyse none –me dia –threads auto

Elég nagy hiba szerintem, főleg az első menetbe berakni a –deblock -3:-3 opciót. Ennyire eltolni a szűrőt szintén nem érdemes, mert minőségromlást jelent. Kíváncsiságból leteszteltem és rosszabb képet ad akkora eltolás, mint az alap 0:0. Maradjon csak alapon, ha nincs különösebb indokunk kimozdítani. Más források is óva intenek a -3:-3 használatától.

Ezt követően jöhet a második menet:
x264.exe --pass 2 --bitrate xxxx --stats ".stats" --level 4.1 --ref 6 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --trellis 1 --aq-strength 0.5 --aq-sensitivity 13 --qcomp 1 --me umh --threads auto --thread-input --cqmfile "prestige_cqm.cfg" --progress --no-psnr --no-ssim --output "xxxxx.mkv" "xxxxx.avs"

A bitrátát érdemes 1500Kbps környékére kalibrálni, esetleg 200 is indokolt lehet, ha a film extra részlet gazdag.

Ha pl. sok éjszakai jelenet van a filmben, akkor nem érdemes túl magasra tenni, mert a sok sötét elfedi az esetleges „spórolást” a minőség tekintetében. Ilyenkor a deblock maradhat 0:0, hiszen nem annyira lényeges, ha kicsit több az összemosódott MB. Vannak viszont kivételek is. Például a Silent Hill című filmben, a sötétség érkezése sokáig kivehetetlen volt a mozis felvételeken, annyira sötét a jelenet. Sok release-ben csak az öngyújtó fénye látszott, ahogy szaladgál a képen. Az ilyen és ehhez hasonló részek már igencsak erős és éles deblock-ot kérnek, -2:-2 extrém esetben vagy -2:-1.

A sok lassított jelenet (mint pl.:a Wanted c. film) éles képet követel meg, ami viszont egyrészt magasabb bitrátát, másrészt kicsit mínuszba eltolt deblock-ot igényel. Legyen mondjuk -2:-1 vagy -1:-1. Ekkor a kép élesebb lesz, kevesebb az összemosódás. Nem keverendő a lasítás a lassú mozgással, mert a lassítás mindig élesebb képet, az élek kisebb mértékű blokkosodását, szintén az élekkel kapcsolatban a fűrészfogak eltüntetését és a színek jó átvitelét igénylik, ami sokszor elég sok tesztelés eredményeként áll elő.

Nos, miután sikerült még néhány paramétert megismernünk, nézzük, ezek a beállítások hogyan változnak a többi forrástípusnál.

Animáció, rajzfilm, anime kódolása

Vegyük először a rajzfilmeket, amelyek alapvetően nem igényelnek mind egyéni beállításokat. Egész jó sablont alakíthatunk ki magunknak a tapasztalatok alapján, ami az animációs filmek nagy hányadára jól alkalmazható is.

Ennél a típusnál a két legfontosabb dolog a deblock és a custom mátrixok használata. A deblock, ahogy láttuk is, alapból 0:0 értéket vesz fel. Legtöbb esetben ez megfelel, nem kell hozzányúlni, de a tapasztalat azt mutatja, rajzfilmeknél érdemes kicsit eltolni, mégpedig pozitív irányba. 1:1, 1:2 már jó lehet, nem kell magasra menni, mert torzulást eredményezhet. Negatív irányba soha ne menjünk ennél a típusnál, mert főleg a színek sínylik meg kódolás közben. Rajzolt filmeknél az elmosódás inkább jótékony hatású, mint negatív.

A saját mátrixok (custom quantization matrices, CQM) alapelve nem bonyolult, de megfelelő kialakításuk hosszas tesztelést és mélyebb ismereteket, jó hardvert követel. Ezek a mátrixok alapértékként simák, nem tartalmaznak „hullámzást”, ám a CQM-ek már korántsem így néznek ki. Egy-egy blokkméretre megadva írják le a felbontáshoz szükséges paramétereket. Itt most nem mennék bele mélyebben, de érdemes
ITT és
ITT körülnézni. Animált filmeknél *.mp4 guy mátrixai jól alkalmazhatóak.

A bitráta kérdésében az arany középút érvényesül, vagyis legyen a kiindulási alap 1000Kbps. Természetesen egy Dragon Ball Z ennél többet igényel, mert rengeteg mozgás, váltás van benne, de pl. A vándorló palota viszont nem.

Az újabb cgi-s animációs filmeknél, mint a L’ecsó is vagy a Kung Fu Panda, elég sok szín, igényes mozgás található, viszont a tanmese részeknél, dialógusoknál szinte alig-alig képződik a képek között residum. Ilyenkor azért mégis érdemesebb a gyors részekre koncentrálni, még ha kicsit pazarlóan is járunk el a lassabb részeknél, hiszen a gyorsabbakból van több.

Találtam példabeállításokat is, amelyek nagyon jó minőséget produkálnak, de ezek nem lesznek kompatibilisek QuickTime és iPod eszközökkel.

First pass:
--pass 1 --bitrate 1000 --stats ".stats" --bframes 3 --b-pyramid --filter 1,2 --subme 1 --analyse none --vbv-maxrate 2500 --me dia --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output NUL "path/to/avs/script.avs"

second pass:
--pass 2 --bitrate 1000 --stats ".stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter 1,2 --trellis 1 --analyse all --8x8dct --vbv-maxrate 2500 --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "path/to/output/file.264" "path/to/avs/script.avs"

Új paraméterek:
--vbv-maxrate 2500 -> nem koonstans bitrátás kódolásnál lehet szabályozni a helyi maximális bitráta értéket ezzel a paraméterrel.

Dokumentumfilmek, zajos filmek

Ennél a típusnál a minőségi paramétereken engedhetünk kicsit. Nem feltétlenül szükséges például elmozdítanunk a deblock értékét 0:0-ról, hiszen már maga a forrás sem tökéletes minőségű. Ám ha élesíteni szeretnénk kicsit rajta, akkor esetleg -2:-1 érték beállítható, de ennél lejjebb ne menjünk. A –ref értékét érdemes 6-ra állítani, --me umh a második menetben, szokás szerint és a subme értékét 5-7 között belőni. Nyilván nem szükséges a 4.1 level alkalmazása, elegendő a 3.1.

Alkalmazhatunk CQM-et is, de ezek közül se válasszunk high profil-osat, mert feleslegesen terhelnénk vele a gépet és vennénk el időt magunktól, hiszen nem sokat javítana a minőségen.

Bitráta tekintetében nyugodtan maradhatunk az 1000Kbps környékén, nem indokolt feljebb emelni. Mivel ezek jellemzően rövidebb alkotások, a méret lesz a fontosabb, így akár 700-1000Kbps között is mozoghatunk.

Lassabb, kevés váltást, sok homogén felületet és hasonló képet tartalmazó filmek

Az ilyen filmek többségükben több egymáshoz nagyon hasonló keretet tartalmaznak, így a prediction egész jó eredményt fog szolgáltatni gyorsabb végrehajtással.

Bitráta tekintetében 1000Kbps szintén lehet egy célérték, esetleg 1200. A deblock értékét nem érdemes elmozdítani 0:0 értékről, de vannak, akik az állandó -2:-1-re esküsznek. Szerintem nem annyira látható ilyen forrásnál a különbség, nem lesz annyival élesebb.

Általánosságban az első példa cli alkalmazható a tett kiegészítésekkel. Egész hatékony tömörítés és jó minőség érhető el –ref 2 --subme 5 –bframes 3 értékekkel.

Ezeknél a filmeknél a méretben előnyben lehetünk, mert sok olyan prediction lesz, amiknek az eredménye nagyon kisméretű residum és mozgásvektor lesz, így ezeknél a típusoknál egy –weightb beállítás jótékonyan segíthet a sok hasonló MV miatt is. –me muh alkalmazható, de próbálkozhatunk a „dia” értékkel is.

Végszó

Láthatjuk tehát, hogy a paraméterek megválasztása a kódoláshoz nem konfekció szerint működik, szinte minden forrásanyag külön paraméterlistát igényel. Tipizálhatóak is és ezekre jó közelítéssel adható is útmutatás, de személyenként eltérő, mit tartunk fontosank, mennyire zavar 1-2 hiba, gyengébb beállítás.

Nos, próbálgassátok a beállításokat GUI-kkal vagy cli-ben és úgyis a tapasztalat lesz az, ami a végén meghatározza az optimális beállításokat. Sok GUI tartlamaz lehetőséget a cli szerkesztésére, érdemes átnézni, javítani, mielőtt elindítjuk a kódolást.

Jó szórakozást mindenkinek! :)