<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>10.5. Enkódování x264 kodekem</title><link rel="stylesheet" href="default.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="MPlayer - Multimediální přehrávač"><link rel="up" href="encoding-guide.html" title="Kapitola 10. Enkódování s MEncoderem"><link rel="prev" href="menc-feat-xvid.html" title="10.4. Enkódování pomocí kodeku Xvid"><link rel="next" href="menc-feat-video-for-windows.html" title="10.6. Enkódování rodinou kodeků Video For Windows"><link rel="preface" href="howtoread.html" title="Jak číst tuto dokumentaci"><link rel="chapter" href="intro.html" title="Kapitola 1. Představení"><link rel="chapter" href="install.html" title="Kapitola 2. Instalace"><link rel="chapter" href="usage.html" title="Kapitola 3. Použití"><link rel="chapter" href="cd-dvd.html" title="Kapitola 4. Použití CD/DVD"><link rel="chapter" href="tv.html" title="Kapitola 5. TV"><link rel="chapter" href="radio.html" title="Kapitola 6. Rádio"><link rel="chapter" href="video.html" title="Kapitola 7. Výstupní video zařízení/rozhraní"><link rel="chapter" href="ports.html" title="Kapitola 8. Porty"><link rel="chapter" href="mencoder.html" title="Kapitola 9. Základní použití MEncoderu"><link rel="chapter" href="encoding-guide.html" title="Kapitola 10. Enkódování s MEncoderem"><link rel="chapter" href="faq.html" title="Kapitola 11. Často Kladené Dotazy (FAQ)"><link rel="appendix" href="bugreports.html" title="Příloha A. Jak hlásit chyby"><link rel="appendix" href="skin.html" title="Příloha B. Formát skinů MPlayeru"><link rel="subsection" href="menc-feat-x264.html#menc-feat-x264-encoding-options" title="10.5.1. Enkódovací volby x264"><link rel="subsection" href="menc-feat-x264.html#menc-feat-x264-example-settings" title="10.5.2. Příklady nastavení enkódování"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">10.5. Enkódování <code class="systemitem">x264</code> kodekem</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="menc-feat-xvid.html">Předcházející</a> </td><th width="60%" align="center">Kapitola 10. Enkódování s <span class="application">MEncoder</span>em</th><td width="20%" align="right"> <a accesskey="n" href="menc-feat-video-for-windows.html">Další</a></td></tr></table><hr></div><div class="sect1" title="10.5. Enkódování x264 kodekem"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="menc-feat-x264"></a>10.5. Enkódování <code class="systemitem">x264</code> kodekem</h2></div></div></div><p> <code class="systemitem">x264</code> je svobodná knihovna pro enkódování H.264/AVC video proudů. Pře zahájením enkódování budete muset <a class="link" href="codec-installation.html#x264" title="2.5.2. x264">nastavit její podporu v <span class="application">MEncoder</span>u</a>. </p><div class="sect2" title="10.5.1. Enkódovací volby x264"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-x264-encoding-options"></a>10.5.1. Enkódovací volby x264</h3></div></div></div><p> Začněte prosím prohlídkou sekce <code class="systemitem">x264</code> man stránky <span class="application">MPlayer</span>u. 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. </p><div class="sect3" title="10.5.1.1. Úvodem"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-intro"></a>10.5.1.1. Úvodem</h4></div></div></div><p> Tato příručka pokrývá dvě hlavní kategorie enkódovacích voleb: </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Volby které mění dobu enkódování za kvalitu </p></li><li class="listitem"><p> Volby které mohou být použitelné pro naplnění různých osobních preferencí a speciálních požadavků </p></li></ol></div><p> 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ší. </p><p> 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 <a class="ulink" href="http://en.wikipedia.org/wiki/PSNR" target="_top">ve Wikipedii pod heslem PSNR</a>. Celkové PSNR je poslední hlášené PSNR číslo při zařazení volby <tt class="option">psnr</tt> v <tt class="option">x264encopts</tt>. Kdykoli píšeme o PSNR, je jedním z předpokladů tohoto sdělení to, že jsou použity shodné datové toky. </p><p> 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. </p></div><div class="sect3" title="10.5.1.2. Volby které primárně ovlivňují rychlost a kvalitu"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-speedvquality"></a>10.5.1.2. Volby které primárně ovlivňují rychlost a kvalitu</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> <span class="bold"><strong>subq</strong></span>: Z voleb, které umožňují vyměnit čas za kvalitu, jsou obvykle nejdůležitější <tt class="option">subq</tt> a <tt class="option">frameref</tt> (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 <tt class="option">frameref</tt> a <tt class="option">subq</tt> velmi silně ovlivňují. Zkušenosti ukazují, že při jednom referenčním snímku si <tt class="option">subq=5</tt> vezme asi o 35% více času než <tt class="option">subq=1</tt>. Při 6 referenčních snímcích naroste spomalení nad 60%. Vliv <tt class="option">subq</tt> na PSNR se zdá být poměrně stálý, bez ohledu na počet referenčních snímků. Typicky <tt class="option">subq=5</tt> získá 0.2-0.5 dB celkového PSNR přes <tt class="option">subq=1</tt>. To je obvykle již viditelné. </p><p> Režim <tt class="option">subq=6</tt> je pomalejší a vede k vyšší kvalitě za rozumnou cenu. Oproti <tt class="option">subq=5</tt> 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í <tt class="option">subq</tt> nezávisí chování <tt class="option">subq=6</tt> tolik na <tt class="option">frameref</tt> a <tt class="option">me</tt>. Místo toho závisí efektivita <tt class="option">subq=6 </tt> hlavně na počtu použitých B-snímků. Při běžném použití to znamená, že <tt class="option">subq=6</tt> 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 <tt class="option">bframes</tt> na nenulovou hodnotu (viz níže). </p><p> <tt class="option">subq=7</tt> je nejpomalejší, s nejvyšší kvalitou. V porovnání s <tt class="option">subq=6</tt>, 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. </p></li><li class="listitem"><p> <span class="bold"><strong>frameref</strong></span>: Výchozí nastavení <tt class="option">frameref</tt> je 1, ale nemělo by to být bráno tak, že je rozumné nastavovat jej na 1. Pouhé zvýšení <tt class="option">frameref</tt> na 2 získá okolo 0.15dB PSNR s 5-10% spomalením, což je zřejmě dobrý obchod. <tt class="option">frameref=3</tt> získá kolem 0.25dB PSNR navíc k <tt class="option">frameref=1</tt>, což již může být viditelný rozdíl. <tt class="option">frameref=3</tt> je asi o 15% pomalejší než <tt class="option">frameref=1</tt>. Naneštěstí se zisk rychle vytrácí. Při <tt class="option">frameref=6</tt> můžete očekávat zisk pouze 0.05-0.1 dB nad <tt class="option">frameref=3</tt> při dodatečném 15% zpomalení. Nad <tt class="option">frameref=6</tt> 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ší <tt class="option">frameref=12</tt> celkový PSNR o pouhé 0.02dB nad <tt class="option">frameref=6</tt>, při spomalení o 15%-20%. Při tak vysokých hodnotách <tt class="option">frameref</tt> lze říct pouze jedinou dobrou věc, a to že jejich další zvyšování téměř nikdy <span class="bold"><strong>nesníží</strong></span> PSNR, ale další zisk kvality je stěží měřitelný, natož viditelný. </p><div class="note" title="Poznámka:" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Poznámka:</h3><p> Zvýšení <tt class="option">frameref</tt> na nemístně vysokou hodnotu <span class="bold"><strong>může</strong></span> a <span class="bold"><strong>obvykle taky sníží</strong></span> efektivitu kódování, pokud vypnete CABAC. Se zapnutým CABAC (výchozí chování) se zdá být možnost nastavit <tt class="option">frameref</tt> "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. </p></div><p> Pokud vám záleží na rychlosti, bývá vhodným kompromisem použít nízké hodnoty <tt class="option">subq</tt> a <tt class="option">frameref</tt> 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 <tt class="option">frameref</tt> 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 <tt class="option">frameref</tt> 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 <tt class="option">frameref</tt> 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. </p></li><li class="listitem"><p> <span class="bold"><strong>me</strong></span>: 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 <tt class="option">me=dia</tt> 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í (<tt class="option">me=hex</tt>) je rozumným kompromisem mezi rychlostí a kvalitou. Volba <tt class="option">me=umh</tt> získá o trošku méně než 0.1dB globální PSNR, při spomalení, které se liší v závislosti na <tt class="option">frameref</tt>. Při vysokých hodnotách <tt class="option">frameref</tt> (řekněme 12 nebo tak), je <tt class="option">me=umh</tt> asi o 40% pomalejší než výchozí <tt class="option"> me=hex</tt>. Při <tt class="option">frameref=3</tt>, klesne způsobené spomalení na 25%-30%. </p><p> Volba <tt class="option">me=esa</tt> používá tak rozsáhlé vyhledávání, že je příliš pomalá pro praktické využití. </p></li><li class="listitem"><p> <span class="bold"><strong>partitions=all</strong></span>: 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. </p></li><li class="listitem"><p> <span class="bold"><strong>bframes</strong></span>: 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 (<tt class="option">nob_adapt</tt>), zvýší obvykle enkódování s <tt class="option">bframes</tt> o trochu rychlost enkódování. </p><p> S vypnutým adaptivním rozhodováním o B-snímku (<tt class="option">x264encopts</tt> - volba <tt class="option">nob_adapt</tt>), optimální hodnota tohoto nastavení nebývá obvykle vyšší než <tt class="option">bframes=1</tt>, 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. </p></li><li class="listitem"><p> <span class="bold"><strong>b_adapt</strong></span>: Poznámka: Výchozí je zapnuto. </p><p> 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 <tt class="option">b_bias</tt> 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. <tt class="option">b_adapt</tt> a <tt class="option">b_bias</tt> nemají žádný vliv v následných průchodech. </p></li><li class="listitem"><p> <span class="bold"><strong>b_pyramid</strong></span>: 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. </p></li><li class="listitem"><p> <span class="bold"><strong>weight_b</strong></span>: 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é. </p><p> 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 <tt class="option">nob_adapt</tt> do x264encopts, pokud očekáváte, že stmívání bude mít znatelný vliv ve vašem konkrétním klipu. </p></li><li class="listitem"><p><a name="menc-feat-x264-encoding-options-speedvquality-threads"></a> <span class="bold"><strong>threads</strong></span>: 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 <tt class="option">threads=auto</tt> a ponechte <code class="systemitem">x264</code> 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). </p></li></ul></div></div><div class="sect3" title="10.5.1.3. Volby náležející různým preferencím"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-misc-preferences"></a>10.5.1.3. Volby náležející různým preferencím</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> <span class="bold"><strong>Dvouprůchodové enkodování</strong></span>: 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ší. </p><p> 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. </p><p> 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 <tt class="option">qcomp</tt>. </p><p> 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 <tt class="option">subq=1:frameref=1</tt> do <tt class="option">x264encopts</tt> prvnímu průchodu. Pak ve druhém průchodu použijte pomalejší volby pro vyšší kvalitu: <tt class="option">subq=6:frameref=15:partitions=all:me=umh</tt> </p></li><li class="listitem"><p> <span class="bold"><strong>Tříprůchodové enkódování</strong></span>? x264 nabízí možnost provádět větší počet následných průchodů. Pokud zadáte <tt class="option">pass=1</tt> v prvním průchodu a pak použijete <tt class="option">pass=3</tt> 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. </p></li><li class="listitem"><p> <span class="bold"><strong>qcomp</strong></span>: <tt class="option">qcomp</tt> 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, <tt class="option">qcomp=0</tt> 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, <tt class="option">qcomp=1</tt>, 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 <tt class="option">qcomp</tt> 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). </p></li><li class="listitem"><p> <span class="bold"><strong>keyint</strong></span>: <tt class="option">keyint</tt> je výhradně pro výměnu míry převinutelnosti za efektivitu kódování. Výchozí hodnota <tt class="option">keyint</tt> 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 <tt class="option">keyint=125</tt>; 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. </p></li><li class="listitem"><p> <span class="bold"><strong>deblock</strong></span>: Tato věc začíná být trochu kontroverzní. </p><p> 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 <tt class="option">deblock</tt> umožňuje nastavit offsety přednastaveným deblokovacím prahům. </p><p> 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í. </p><p> 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í. </p><p> 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. </p><p> <span class="bold"><strong>Ani to</strong></span> 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 <tt class="option">-vf noise</tt> při přehrávání. Volba <tt class="option">-vf noise=8a:4a</tt> 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. </p></li></ul></div></div></div><div class="sect2" title="10.5.2. Příklady nastavení enkódování"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-x264-example-settings"></a>10.5.2. Příklady nastavení enkódování</h3></div></div></div><p> 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. </p><p> 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. </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th>Popis</th><th>Volby</th><th>Rychlost [fps]</th><th>Relativní ztráta PSNR [dB]</th></tr></thead><tbody><tr><td>Velmi vysoká kvalita</td><td><tt class="option">subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</tt></td><td>6</td><td>0</td></tr><tr><td>Vysoká kvalita</td><td><tt class="option">subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</tt></td><td>13</td><td>-0.89</td></tr><tr><td>Rychlé enkódování</td><td><tt class="option">subq=4:bframes=2:b_pyramid:weight_b</tt></td><td>17</td><td>-1.48</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="menc-feat-xvid.html">Předcházející</a> </td><td width="20%" align="center"><a accesskey="u" href="encoding-guide.html">Nahoru</a></td><td width="40%" align="right"> <a accesskey="n" href="menc-feat-video-for-windows.html">Další</a></td></tr><tr><td width="40%" align="left" valign="top">10.4. Enkódování pomocí kodeku <code class="systemitem">Xvid</code> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Domů</a></td><td width="40%" align="right" valign="top"> 10.6. Enkódování rodinou kodeků <code class="systemitem">Video For Windows</code> </td></tr></table></div></body></html>
distrib
>
Mandriva
>
current
>
i586
>
media
>
main-updates
>
by-pkgid
>
a42e22ddf1d70fb02e9f62289d71cafa
>
files
>
57
