Pojďme si povědět něco o principu nastavování kodeku. V první řadě musíme vědět jaký typ videa a jaký požadavek máme na výsledné video. Pokud potřebujeme vměstnat určitou délku videa na záznamové médium (CD), použijeme 2-pass variable mode. To nám zaručí dodržení požadované délky souboru, aby bylo médium využito bezezbytku a naopak nebylo příliš velké, a zároveň získání co největší možné kvality videa vzhledem k požadované velikosti. Průměrný bitrate vypočítáme podle známého vzorce nebo nějakým bitrate kalkulátorem. Nezapomeňte počítat i s datovým tokem zvuku, o který bude celkový bitrate větší. Převod se provádí, jak již bylo řečeno, nadvakrát (to znamená, že se rendering provede dvakrát, např. ve VirtualDubu pomocí File/Save as AVI). Nejprve uložením log souboru a popřípadě mv (Motion Vector) souboru (doporučuji) s nastavením 2-pass, first pass a napodruhé stejnou akcí s nastavením 2-pass, second pass, který teprve vytvoří požadovaný AVI soubor. Pro oba průchody se nastavují úplně stejné parametry včetně bitratu.

Pokud máme krátké video a nezáleží nám na velikosti nebo na 100% víme, že se video na CD vejde, nebo prostě chceme dosáhnout určité kvality, použijeme 1-pass quality based. U něho nastavíme požadovanou kvantizaci, která se bude držet konstantní. To znamená, že u složitějších a rychlých scén se použíje automaticky vyšší bitrate a naopak. Velikost souboru a použitý průměrný datový tok pak bude závidet na celkové komplexnosti videa. Tento mód je také vhodný pro zachytávání v reálném čase, k tomu je ale potřeba rychlý procesor alespoň 600MHz. Dvouprůchodové enkódování není možné, to snad není třeba komentovat.

1-pass je možné použít pro přibližný odhad velikosti souboru a kvality, které lze dále regulovat nastavením Rate control v Advanced parameters. Parametry v MPEG-4 Tools není vhodné nastavovat při nahrávání v reálném čase, protože je to časově náročné. Pokud je ale zdroj videa prokládaný (nahrávání z TV při více jak 288 řádcích videa), je vhodné zapnout deinterlace. Vše samozřejmně záleží na výkonu procesoru. Scene change threshold se mi osvědčilo nastavit na 70-80%, protože kodek při základním nastavení 50% vkládal klíčové snímky příliš často.

Zastavme se také u bidirectional encoding. Zde je trochu problém. Vysvětleme si, jak vůbec pracují kodeky s programem. Ten posílá kodeku jednotlivé framy jeden po druhém a kodek mu tento frame vrátí zkomprimovaný. Není možná žádná prodleva ve vracení snímků. Normálně nelze udělat, aby kodek dostal několik framů a teprve potom je poslal zpět programu. Pro bidirectional encoding je ale potřeba znát následující snímek, abychom mohli zakódovat ten předchozí. Proto DivX 5 toto obchází takto: první frame videa je vždy I-frame a ten vrátí zakódovaný normálně, druhý frame ale nevrátí a místo něj vrátí delta (P) frame, který je shodný jako první frame (delta frame říká jen změnu, ovšem změna není žádná, takže je velmi malý). Místo třetího framu je pak vrácen druhý frame, místo čtvrtého třetí atd. Tím má kodek k dispozici jeden frame navíc, který je nutný právě pro bidirectional encoding. Vznikne tím ale časový posun videa vůči zvuku o 1/počet snímků za vteřinu, tedy 40ms pro 25fps. Navíc poslední snímek je "ztracen", protože ho software již nevyžaduje. Nevěšte ale hlavu, řešení tohoto problému existuje. Nová verze VirtualDubu 1.4.10 s tímto počítá a ten druhý shodný frame "zahodí" a všechny následující (které jsou normálně o jeden zpožděny) posunou na správné místo. Počítá se i s posledním snímkem, který se tak neztratí. Zajímavé je také, že vždy dva snímky jsou spojeny do jednoho a data uložená v dalším framu ve streamu nejsou použita (resp. tento frame je téměř nulový). To je ale interní věc kodeku, jak si data zakóduje. Při dekódování se vždy dekódují tyto dva snímky společně a ten druhý je uložen v paměti pro přehrání na správném místě, nevznikne tím žádné narušení posloupnosti snímků.

Nová verze DivX kodeku přináší oproti minulé verzi další zlepšení jak v kvalitě, tak i rychlosti enkódování. Ovšem při použití nových parametrů GMC, Bidirectional encoding a Quarter pixel dochází k výraznému zpomalení enkódování a dokonce i květší náročnosti na procesor při přehrávání. Jak výrazné zlepšení a vliv jednotlivých parametrů na rychlost však přinesou až praktické testy ...