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ý.

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.