x264
je svobodná knihovna pro
enkódování H.264/AVC video proudů.
Pře zahájením enkódování budete muset
nastavit její podporu v MEncoderu.
Začněte prosím prohlídkou sekce
x264
man stránky
MPlayeru.
Tato sekce je zamýšlena jako doplněk manuálové stránky.
Zde naleznete tipy, které volby budou nejspíše zajímat většinu lidí.
Man stránka je více uhlazená, ale také více vyčerpávající a
občas nabízí mnohem lepší technické detaily.
Tato příručka pokrývá dvě hlavní kategorie enkódovacích voleb:
Volby které mění dobu enkódování za kvalitu
Volby které mohou být použitelné pro naplnění různých osobních preferencí a speciálních požadavků
Nakonec jen vy můžete rozhodnout, které volby jsou nejlepší pro vaše účely. Rozhodování v první kategorii voleb je nejjednodušší: stačí když zhodnotíte zda změny kvality ospravedlní rychlostní rozdíly. Druhá skupina voleb může být mnohem subjektivnější záležitostí a v úvahu může přijít více faktorů. Poznamenejme, že některé volby "osobních preferencí a speciálních požadavků" mohou také značně ovlivnit kvalitu nebo rychlost enkódování, ale to není jejich hlavní funkce. Několik voleb "osobních preferencí" může dokonce způsobit změny, po kterých se někomu zdá být výsledek lepší a jinému horší.
Než budeme pokračovat, poznamenejme, že tento návod používá jediné měřítko
kvality: celkový PSNR.
Stručné vysvětlení co je to PSNR, naleznete
ve Wikipedii pod heslem PSNR.
Celkové PSNR je poslední hlášené PSNR číslo při zařazení volby
psnr
v x264encopts
.
Kdykoli píšeme o PSNR, je jedním z předpokladů tohoto sdělení
to, že jsou použity shodné datové toky.
Téměř všechny komentáře v tomto návodu předpokládají, že enkódujete dvouprůchodově. Při porovnávání voleb jsou zde dva hlavní důvody pro použití dvouprůchodového enkódování. Zaprvé, dvouprůchodové enkódování vám získá zhruba 1dB PSNR, což je znatelný rozdíl. Zadruhé, testování voleb pomocí přímého porovnání kvality v jednoprůchodových výsledcích je pochybné, jelikož se datový tok značně liší s každým enkódováním. Není vždy snadné určit, zda se změnila kvalita díky změně voleb, nebo z větší části odpovídají změnám datového toku.
subq:
Z voleb, které umožňují vyměnit čas za kvalitu, jsou obvykle nejdůležitější
subq
a frameref
(viz níže).
Máte-li zájem ovlivnit jak rychlost, tak kvalitu, jsou to první volby,
které byste měli zvážit.
Ve smyslu rychlosti se spolu volby frameref
a
subq
velmi silně ovlivňují.
Zkušenosti ukazují, že při jednom referenčním snímku si
subq=5
vezme asi o 35% více času než
subq=1
.
Při 6 referenčních snímcích naroste spomalení nad 60%.
Vliv subq
na PSNR se zdá být poměrně stálý,
bez ohledu na počet referenčních snímků.
Typicky subq=5
získá 0.2-0.5 dB
celkového PSNR přes subq=1
.
To je obvykle již viditelné.
Režim subq=6
je pomalejší a vede k vyšší kvalitě
za rozumnou cenu.
Oproti subq=5
obvykle získává 0.1-0.4 dB
celkového PSNR za cenu ztráty rychlosti 25%-100%.
Narozdíl od ostatních úrovní subq
nezávisí chování
subq=6
tolik na frameref
a me
. Místo toho závisí efektivita subq=6
hlavně na počtu použitých B-snímků. Při běžném použití
to znamená, že subq=6
má velký vliv jak na rychlost, tak na
kvalitu v komplexních, velmi pohyblivých scénách, ale nemusí mít takový vliv
ve scénách s malým pohybem. Poznamenejme, že stále doporučujeme nastavit
bframes
na nenulovou hodnotu (viz níže).
subq=7
je nejpomalejší, s nejvyšší kvalitou.
V porovnání s subq=6
, obvykle získá 0.01–0.05 dB
globálního PSNR za zpomalení v rozmezí 15%–33%.
Jelikož je poměr získané kvality ku ztrátě rychlosti docela malý, měli byste
tuto volbu používat pouze pokud chcete ušetřit každý možný bit a doba
enkódování není problém.
frameref:
Výchozí nastavení frameref
je 1, ale nemělo by to být bráno
tak, že je rozumné nastavovat jej na 1.
Pouhé zvýšení frameref
na 2 získá okolo
0.15dB PSNR s 5-10% spomalením, což je zřejmě dobrý obchod.
frameref=3
získá kolem 0.25dB PSNR navíc k
frameref=1
, což již může být viditelný
rozdíl.
frameref=3
je asi o 15% pomalejší než
frameref=1
.
Naneštěstí se zisk rychle vytrácí.
Při frameref=6
můžete očekávat zisk pouze
0.05-0.1 dB nad frameref=3
při dodatečném
15% zpomalení.
Nad frameref=6
je zisk kvality obvykle velmi malý
(ačkoli byste měli mít na paměti, že se to může výrazně lišit v závislosti
na zdrojovém materiálu).
V poměrně typickém případě zlepší frameref=12
celkový PSNR o pouhé 0.02dB nad frameref=6
,
při spomalení o 15%-20%.
Při tak vysokých hodnotách frameref
lze říct pouze
jedinou dobrou věc, a to že jejich další zvyšování téměř nikdy
nesníží PSNR, ale další zisk kvality
je stěží měřitelný, natož viditelný.
Zvýšení frameref
na nemístně vysokou hodnotu
může a
obvykle taky sníží
efektivitu kódování, pokud vypnete CABAC.
Se zapnutým CABAC (výchozí chování) se zdá být možnost nastavit
frameref
"příliš vysoko" příliš vzdálená na to,
abyste se tím museli trápit a v budoucnu mohou optimalizace
tuto možnost zcela vyloučit.
Pokud vám záleží na rychlosti, bývá vhodným kompromisem použít
nízké hodnoty subq
a frameref
v prvním průchodu a zvýšit je ve druhém.
Typicky to má zanedbatelný záporný vliv na konečnou kvalitu:
Pravděpodobně stratíte méně než 0.1dB PSNR, což by měl být až příliš
malý rozdíl, než aby byl vidět.
Odlišné hodnoty frameref
však mohou místy ovlivnit
volbu typu snímku.
Nejspíš to budou ojedinělé případy, ale chcete-li si být zcela jisti,
zjistěte, jestli vaše video obsahuje buď blýskavé vzory přes celou obrazovku,
nebo rozsáhlé krátkodobé změny, které by mohly vynutit I-snímek.
Nastavte frameref
pro první průchod tak, aby byl
dostatečně velký pro pokrytí doby bliknutí (nebo změny).
Například, pokud scéna přepíná tam a zpět mezi dvěma obrázky přes tři snímky,
nastavte frameref
pro první průchod na 3 a více.
Tento případ je nejspíš zcela ojedinělý v hraných filmech, ale občas se
vyskytuje v záznamech z videoher.
me:
Tato volba je určena pro výběr metody vyhledávání pohybu.
Změnou této volby jednoduše měníte poměr kvalita-versus-rychlost.
Volba me=dia
je jen o málo procent rychlejší než
výchozí vyhledávání za cenu pod 0.1dB globálního PSNR.
Výchozí nastavení (me=hex
) je rozumným kompromisem
mezi rychlostí a kvalitou. Volba me=umh
získá o trošku méně
než 0.1dB globální PSNR, při spomalení, které se liší v závislosti na
frameref
. Při vysokých hodnotách
frameref
(řekněme 12 nebo tak), je me=umh
asi o 40% pomalejší než výchozí me=hex
. Při
frameref=3
, klesne způsobené spomalení na
25%-30%.
Volba me=esa
používá tak rozsáhlé vyhledávání, že je příliš
pomalá pro praktické využití.
partitions=all: Tato volba zapíná použití bloků 8x4, 4x8 a 4x4 v predikovaných makroblocích (navíc k výchozím blokům). Její aktivace vede k poměrně stálé 10%-15% ztrátě rychlosti. Tato volba je poměrně neužitečná ve zdroji obsahujícím pouze pomalý pohyb, naproti tomu u některých zdrojů s rychlým pohybem, přesněji zdrojů s velkým množstvím malých pohyblivých objektů, můžete očekávat zisk okolo 0.1dB.
bframes:
Použitelnost B-snímků je ve většině ostatních kodeků diskutabilní.
V H.264 se to změnilo: jsou zde nové techniky a typy bloků pro použití
v B-snímcích.
Obvykle i naivní algoritmus pro výběr B-snímku může zajistit znatelný
zisk PSNR.
Také je zajímavé, že pokud vypnete adaptivní rozhodování o B-snímku
(nob_adapt
), zvýší obvykle enkódování s
bframes
o trochu rychlost enkódování.
S vypnutým adaptivním rozhodováním o B-snímku
(x264encopts
- volba nob_adapt
),
optimální hodnota tohoto nastavení nebývá obvykle vyšší než
bframes=1
, jinak mouhou utrpět velmi pohyblivé scény.
Se zapnutým adaptivním rozhodováním o B-snímku (výchozí chování),
je obvykle bezpečné použít vyšší hodnoty; enkodér se pokusí snížit
použití B-snímků ve scénách, kde by snížily kompresi.
Enkodér zřídka použije více než 3 nebo 4 B-snímky;
nastavení této volby na vyšší hodnotu bude mít jen nepatrný vliv.
b_adapt: Poznámka: Výchozí je zapnuto.
Je-li tato volba zapnuta, bude enkodér používat rychlou
heuristiku pro snížení počtu B-snímků ve scénách, kde by jejich
použitím příliš nezískaly.
Můžete použít b_bias
pro nastavení jak přátelský
bude enkodér k B-snímkům.
Spomalení působené adaptivními B-snímky je nyní spíše malé, ale
stejně tak potenciální zisk kvality.
Obvykle však nijak neškodí.
Poznamenejme, že ovlivňuje rychlost a rozhodování o typu snímku pouze
v prvním průchodu.
b_adapt
a b_bias
nemají žádný vliv
v následných průchodech.
b_pyramid: Pokud používáte >=2 B-snímky, můžete také zapnout tuto volbu; jak říká man stránka, dostanete malé zvýšení kvality bez ztráty rychlosti. Poznamenejme, že tato videa nelze číst dekodéry založenými na libavcodec staršími než 5. března 2005.
weight_b: V typických případech tato volba nepřináší velký zisk. V prolínacích nebo stmívacích scénách však vážená predikce umožňuje poměrně velkou úsporu datového toku. V MPEG-4 ASP bývá stmívání obvykle nejlépe kódováno jako série velkých I-snímků; použití vážené predikce v B-snímcích umožňuje změnit alespoň některé z nich na rozumně menší B-snímky. Spomalení enkódování se zdá být minimální, pokud nějaké je. Rovněž, v rozporu s tím, co si někteří lidé mohou myslet, požadavky dekodéru na CPU nejsou váženou predikcí ovlivněny, ostatní možnosti jsou stejně náročné.
Naneštěstí má aktuálně algoritmus adaptivního rozhodování o B-snímcích
výraznou tendenci vyvarovat se B-snímků při stmívání.
Dokud se to nezmění, bude dobré přidat
nob_adapt
do x264encopts, pokud očekáváte, že stmívání
bude mít znatelný vliv ve vašem konkrétním klipu.
threads:
Tato volba umožňuje vytvořit více vláken pro enkódování na více procesorech.
Jejich počet si můžete nastavit ručně, nebo raději nastavte
threads=auto
a ponechte
x264
detekovat kolik máte procesorů
k dispozici a zvolit vhodný počet vláken.
Pokud máte víceprocesorový stroj, měli byste tuto volbu uvážit, jelikož dokáže
lineárně zvýšit rychlost podle počtu procesorových jader
(okolo 94% na jádro) při velmi malém snížení kvality (asi 0,005dB pro duální procesor
a okolo 0,01dB pro čtyřprocesorový stroj).
Dvouprůchodové enkodování: Výše jsme doporučovali vždy používat dvouprůchodové enkódování, ale stále existují důvody proč jej nepoužít. Například pokud zachytáváte TV vysílání a enkódujete v reálném čase, nemáte jinou možnost, než použít jeden průchod. Jeden průchod je samozřejmě rychlejší než dva; pokud použijete stejné volby v obou průchodech, pak je dvouprůchodové enkódování téměř dvakrát pomalejší.
Stále jsou však velmi dobré důvody pro použití dvouprůchodového režimu. Volič datového toku v jednoprůchodovém režimu není oduševnělý a často dělá nerozumné volby, protože nevidí celkový obraz. Předpokládejme, že máte například dvouminutové video skládající se ze dvou částí. První polovina je vysoce pohyblivá scéna dlouhá 60 sekund, která samostatně vyžaduje kolem 2500kbps, aby vypadala slušně. Hned za ní následuje méně náročná 60 sekundová scéna, která vypadá dobře při 300kbps. Vyžádáte si 1400kbps, což je teoreticky dostatečné pro pokrytí obou scén. Jednoprůchodový volič datového toku v tom případě učiní několik "chyb". První blok může skončit těžce překvantizovaný, takže bude nepoužitelně a zbytečně čtverečkovaný. Druhá část bude velmi podkvantizovaná; to může vypadat dobře, ale spotřeba bitů na tento vzhled je nerozumně vysoká. Čeho se dá ještě hůře vyvarovat je problém přechodu mezi těmito scénami. První sekundy málo pohyblivé poloviny budou těžce překvantizovány, protože volič toku stále očekává nároky na datový tok, se kterými se potýkal v první polovině videa. Tato "chybová doba" překvantizované málo pohyblivé scény bude vypadat neskutečně špatně a skutečně použije méně než 300kbps, které by potřebovala, aby vypadala dobře. Existují způsoby pro zmírnění nástrah jednoprůchodového enkódování, ale ty mohou tíhnout ke zvyšování nepřesnosti datového toku.
Víceprůchodový volič datového toku nabízí velké výhody oproti jednomu
průchodu. Díky statistikám generovaným v prvním průchodu může enkodér
určit, s rozumnou přesností, bitovou náročnost enkódování každého snímku
při jakémkoli kvantizéru. To umožňuje mnohem racionálnější, lépe naplánovanou
spotřebu bitů mezi drahými (hodně pohyblivými) a levnými (málo pohyblivými)
scénami. Několik nápadů jak upravit tuto spotřebu podle svého naleznete níže
viz qcomp
.
Navíc dva průchody nemusí trvat dvakrát tak dlouho jako jeden. Můžete upravit
volby prvního průchodu pro nejvyšší rychlost a nižší kvalitu.
Pokud si dobře zvolíte své volby, můžete mít velmi rychlý první průchod.
Výsledná kvalita ve druhém průchodu bude trochu horší, protože predikce
velikosti je méně přesná, ale rozdíl v kvalitě je obvykle příliž malý, aby
byl vidět. Zkuste např. přidat
subq=1:frameref=1
do x264encopts
prvnímu průchodu. Pak ve druhém průchodu použijte pomalejší volby pro
vyšší kvalitu:
subq=6:frameref=15:partitions=all:me=umh
Tříprůchodové enkódování?
x264 nabízí možnost provádět větší počet následných průchodů.
Pokud zadáte pass=1
v prvním průchodu a pak použijete
pass=3
v následujícím průchodu, pak tento průchod
jak načte statistiky z předchozího, tak zapíše své vlastní. Další průchod
po něm pak bude mít velmi dobrou základnu pro vysoce přesnou predikci
velikosti snímků při zvoleném kvantizéru. V praxi se celková kvalita
z toho vzešlá blíží nule a je možné, že třetí průchod bude mít horší
celkový PSNR než jeho předchúdce. Při běžném použití tři průchody pomůžou,
pokud dostanete buď špatnou predikci datového toku, nebo špatně vypadající
přechody mezi scénami po použití pouze dvou průchodů.
To se nejspíš může stát v extrémně krátkých klipech. Je rovněž několik
zvláštních případů, ve kterých jsou tři a více průchodů dobré pro
pokročilé uživatele, ale pro stručnost se zde těmito případy zabývat nebudeme.
qcomp:
qcomp
mění poměr počtu bitů alokovaných "drahým"
velmi pohyblivým snímkům k "levným" málo pohyblivým snímkům. V jednom
extrému, qcomp=0
vede k čistě konstantnímu datovému toku.
Což typicky činí velmi pohyblivé scény velmi ošklivé, zatímco scény
s malým pohybem vypadají perfektně, ale spotřebovávají mnohem větší datový
tok, než by potřebovaly k tomu, aby ještě vypadaly skvěle.
Ve druhém extrému, qcomp=1
, dostanete téměř konstantní
kvantizační parametr (QP). Konstantní QP nevypadá špatně, ale většina
lidí soudí, že je rozumnější snížit trochu datový tok v extrémně
náročných scénách (kde snížení kvality není tak vidět) a realokovat je
do scén, které je snadnější enkódovat při excelentní kvalitě.
Výchozí hodnota qcomp
je 0.6, což může být, podle
některých lidí poněkud málo (běžně se rovněž používá 0.7-0.8).
keyint:
keyint
je výhradně pro výměnu míry převinutelnosti
za efektivitu kódování. Výchozí hodnota keyint
je 250.
V materiálu 25 snímků za sekundu to zajišťuje schopnost převíjení
s 10 sekundovou přesností. Pokud soudíte, že bude důležité a užitečné
být schopen převíjet s přesností 5 sekund, nastavte
keyint=125
;
to ovšem trochu sníží kvalitu/datový tok. Pokud vám jde jen o kvalitu, nikoli
převinutelnost, můžete si nastavit mnohem vyšší hodnoty
(rozumějte že zisk z toho klesá a může být neznatelný až žádný).
Video proud bude stále mít převíjecí body, pokud jsou zde nějaké změny scény.
deblock: Tato věc začíná být trochu kontroverzní.
H.264 definuje jednoduchou deblokovací proceduru I-bloků, která používá
přednastavených sil a prahů závislých na QP daného bloku.
Výchozí je, že bloky s vysokým QP jsou filtrovány silně a bloky s nízkým QP
nejsou deblokovány vůbec.
Přednastavené síly definované standardem jsou dobře zvoleny a
vyváženy tak, že jsou optimální z hlediska PSNR pro libovolné
video, které zkoušíte enkódovat.
Volba deblock
umožňuje nastavit offsety přednastaveným
deblokovacím prahům.
Zdá se, že si mnoho lidí myslí, že je dobré snížit sílu deblokovacího filtru o vysokou hodnotu (řekněme, -3). To však není téměř nikdy dobrý nápad a v mnoha případech lidé, kteří to dělají, nerozumí dobře tomu, jak pracuje výchozí deblokování.
První a nejdůležitější věc, kterou byste měli vědět o in-loop deblokovacím filtru, je, že výchozí prahy jsou téměř vždy optimální z hlediska PSNR. V řídkých případech, kdy nejsou, je ideální offset plusmínus 1. Úprava deblokovacích parametrů o větší hodnotu téměř zaručeně poškodí PSNR. Zesílení filtru setře více detailů; oslabení filtru povede k zvýšené viditelnosti blokování.
Rozhodně je hloupost snižovat deblokovací prahy pokud má vaše video převážně nízkou plošnou komplexnost (čili málo detailů nebo šumu). In-loop filtr odvádí téměř výbornou práci v ukrývání artefaktů, které se mohou vyskytnout. Pokud má zdroj vysokou plšnou komplexnost, pak jsou artefakty méně viditelné. To proto, že kroužkování vypadá podobně jako detail nebo šum. Lidské oko snadno rozpozná, pokud je odstraněn detail, ale ne už tak snadno pozná, že je šum reprezentován špatně. Když příjde na subjektivní kvalitu, pak jsou detaily a šum do jisté míry zaměnitelné. Oslabením deblokovacího filtru nejspíše zvýšíte chybu, přidáním kroužkových artefaktů, ale oko si toho nevšimne, jelikož je zamění za detaily.
Ani to však neospravedlňuje
oslabení deblokovacího filtru.
Obecně dostanete kvalitnější šum pomocí postprocesingu.
Pokud vaše H.264 videa vypadají příliš neostře nebo rozmazaně, zkuste si
pohrát s -vf noise
při přehrávání.
Volba -vf noise=8a:4a
by měla skrýt většinu středně silných
artefaktů.
Téměř určitě to bude vypadat lépe, než výsledky, které byste mohli dosáhnout
pohráváním si s deblokovacím filtrem.
Následující nastavení jsou příklady nastavení různých kombinací voleb enkodéru, které ovlivňují poměr rychlost versus kvalita při shodném cílovém datovém toku.
Veškerá nastavení byla testována na video vzorku 720x448 @30000/1001 snímků za sekundu, cílový datový tok byl 900kbps a prováděly se na AMD-64 3400+ při 2400 MHz v režimu 64 bitů. Každá kombinace nastavení má uvedenu změřenou rychlost enkódování (ve snímcích za sekundu) a ztrátu PSNR (v dB) oproti nastavení "velmi vysoká kvalita". Rozumějte však že, v závislosti na vašem zdrojovém materiálu, typu počítače a pokrokům ve vývoji, můžete dospět k velmi odlišným výsledkům.
Popis | Volby | Rychlost [fps] | Relativní ztráta PSNR [dB] |
---|---|---|---|
Velmi vysoká kvalita | subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid=normal:weight_b | 6 | 0 |
Vysoká kvalita | subq=5:8x8dct:frameref=2:bframes=3:b_pyramid=normal:weight_b | 13 | -0.89 |
Rychlé enkódování | subq=4:bframes=2:b_pyramid=normal:weight_b | 17 | -1.48 |