DivX 5.0.2

Než se pustíme do jeho rozebrání a popisu, zkusme se mrknout lehce do jeho historie. Za všechno v podstatě může Microsoft, který se v roce 1999 (to to letí) pustil do boje v oblasti streamovaného videa po internetu se svými Windows Media Tools 4. Ty obsahovali i tři kodeky MPEG-4 označené V1, V2, V3. Prvně jmenovaný byl naprogramován přesně podle specifikace MPEG-4, ostatní byli ještě trochu vylepšené. V beta verzi šli používat ještě i v AVI souborech, ve finální verzi ale pouze v novém formátu ASF. Kdyby se Microsoft nevydal svojí cestou, zřejmně by nemusel jistý programátor říkají si Gej kodek V3 hacknout a povolit tak používání opět i v AVI, takže ho šlo využít jakýkoliv video editor, ne jen ten dodávaný ve Windows Media Tools. Nazval ho DivX 3. Ještě ten rok se objevilo další vylepšení a vznikly dva kodeky Slow motion a Fast motion. Jak již název napovídá, šlo o stejný kodek, pouze byla změněna distribuce bitratu. U Fast motion se u scén s malým pohybem snižoval bitrate daleko více, takže u rychlých scén bylo možné použít větší a tím i zvýšit kvalitu. Tyto kodeky byly v podstatě nelegální, protože licence Microsoftu takovéto nakládání se svým kodekem neumožňovalo. Microsoft dokonce ve verzi WMT 4.1 opět uvolnil použití V3 kodeku pro AVI, to už ale bylo pozdě, protože DivX získal uhromnou popularitu.

V roce 2000 Gej s několika dalšími programátory vytvořil projekt OpenDivX (nazývaný také Project Mayo), který měl nahradit dosavadní nelegální DivX a vytvořit kodek MPEG-4, který bude open source a do jeho vývoje se mohl zapojit kdokoliv (a hodně lidí i zapojovalo). Tak to fungovalo asi rok, než Gej & spol. udělali na všechny malý podlraz a založili vlastní firmu DivX Networks a pokračovali ve vývoji sami a v srpnu 2001 vypustili vlastní kodek DivX 4, založený na OpenDivX, kompatibilním se starým DivX 3, již ale nebyl open source. Jeho kvalita byla o něco horší, než DivX 3, šlo ale o plně legitimní projekt. Další verze přišly s výrazným zlepšením enkódování a kvalitativně se dostaly až na úroveň DivX3 (a tedy MS MPEG-4 V3), kodek byl stále freeware.

Začátkem března 2002 pak přišla verze 5.0, která má další vylepšení v kvalitě, ovšem vlastně jen v placené verzi DivX Pro (jsou dvě verze, DivX Pro 5.0 GAIN zobrazuje při surfování v Internet Exploreru (v Mozille ne :-) reklamní bannery a placená DivX Pro 5.0 je bez bannerů). Základní verze je stále zdarma, zůstává však kvalitativně na úrovni předchozí, obsahuje ale různé optimalizace pro zvýšení rychlosti plus pár věcí navíc. Novinkou je také nový formát souborů DIVX, který by měl řešit problémy se synchronizací zvuku v AVI. Zde se také sluší říci o projektu Xvid, který vychází z myšlenky OpenDivX a jako open source je stále a zřejmně tak zůstane. Je to také MPEG-4 kodek a svou kvalitou šlape DivX na paty (možná i v něčem předčí) a stává se stále oblíbenějším. Konec řečí, jdeme na samotný kodek.

Po otevření nastavení kodeku (vyběrem kodeku DivX 5.0 v oblíbeném video editoru a klepnutím na Konfiguraci resp. Configuration) na nás "vybafne" velké logo, které je obsaženo na každé straně. Je sice hezky graficky vyvedené, ale přece jen (na můj vkus) si ho mohli odpustit a raději zmenšit okno. Podívejme se na parametry na první straně označené jednoduše DivX Codec.

Hned první parametr Variable bitrate mode určuje celkové chování kompresoru a distribuci bitratu. Z předchozích verzí zmizelo nastavení Constant bitrate, u kterého byl bitrate v čase konstantní. Nyní jsou všechny módy enkódování VBR (variable bitrate).

• 1-pass - jednoprůchodové enkódování, které se snaží dodržet v průměru zadaný bitrate, přesto je použit vyšší bitrate pro složitější scény a nižší pro jednodušší. Nevýhodou je, že v průběhu procesu se může měnit přerozdělování bitratu a některé scény (i když stejně složité) v různých částech filmu budou mít rozdílnou kvalitu.
• 1-pass quality based - v tomto módu se nezadává bitrate, ale Kvantizace (Quantizer), určující výslednou kvalitu bez rozdílu složitosti scén. Nevýhodou je nemožnost určit přesně bitrate a tím i výslednou velikost souboru, volíme ho tedy, pokud nám na velikosti nezáleží.
• 2-pass, first pass - první průchod dvouprůchodového enkódování, v tomto módu nedochází k převodu, ale k analýze videa a uložení informací o kvantizaci, komplexnosti scén, textur a pohybu do log souboru. V principu funguje podobně jako 1-pass quality based, nedochází ale k produkci výsledného streamu. Abychom ho získali, musíme tedy následně provést:
• 2-pass, second pass - druhý průchod dvouprůchodového enkódování, při kterém již dochází k ukládání výsledného videa a používají se informace z log souboru vytvořeného v prvním průchodu. Touto metodou (resp. metodami - oběma průchody) lze dosáhnout poměrně přesného výsledného celkového bitratu při konstantní kvalitě, netrpí chybou rozdělování bitratu jako metoda 1-pass, kvalita je konstantní jako u 1-pass quality based, ale je určena až na základě informací z prvního průchodu a nastaveného výsledného bitrate. Nevýhodou je zdlouhavost (dva průchody znamenají dvakrát delší čas enkódování), je vhodné především pokud chceme dosáhnout co nejvyšší kvality při "vměstnání se" na dostupnou kapacitu média (např. CD).

Dalšími parametry na této straně je nastavení Two-Pass Encoding Log Files. Zde lze nastavit cestu a jméno souboru, kam se bude ukládat Log file při dvouprůchodovém enkódování. Lze také použít ukládání dodatečných informací z prvního průchodu do tzv. MV souboru, což má urychlit druhý průchod. Ale pozor! Toto lze použít pouze pokud jsou kompresoru dodána na chlup přesně stejná data jako v prvním průchodu. Pokud ne, může to mít za následek nedefinovatelné výsledky včetně porušení struktury obrazu.

Následuje MPEG-4 Tools. Zde lze nastavit komplexnější enkódování a je dostupné jen ve verzi Pro kodeku. Tyto položky jsou také jediným kvalitativním přínosem od minulé verze 4.12. Use Quarter Pixel zapne realističtější zpracování makrobloků. V předchozí verzi bylo filtrování bloků a jejich pohybu prováděno s přesností na půl pixelu, tímto se zvýší na jednu čtvrtinu. Use GMC zapíná Global Motion Compensation. To je výhodné, pokud jsou některé objekty zvětšovány nebo zmenšovány bez změny jejich obsahu a struktury, například u zoomování videokamer. Use bidirectional encoding bude mít asi největší význam. Zapíná použítí B-framů (předtím se používaly pouze I a P framy), které používají nejen informace z předchozího snímku (jako P framy), ale i z následujícího. Největší efekt to bude mít u pohybu objektu na statickém pozadí. Normálně při použití P framů se musí kódovat i pozadí, které se objevilo po přesunu objektu, při B framech se použije pozadí v dalších snímcích, což snižuje nutný bitrate.

Pomocí Write DivX MP4 file můžeme přímo za běhu enkódování vytvářet nový formát souborů DivX. Ukládá se ale pouze video bez zvuku (ten není pro kodek dostupný) a navíc lze přehrát jen v dodávaném DivX Playeru.

Quick config CLI slouží pro "rychlé" zadávání parametrů do příkazové řádky. Po pravdě řečeno mi uniká smysl, protože mi přijde rychlejší nastavování pomocí zaškrtávátek (GUI) nebo profilů (viz dále). Snad jen zkopírování doporučených nastavení z internetu může být prospěšné. Veškeré změny na této řádce se promítnou i do GUI a naopak.

Na druhé straně General Parameters lze měnit parametry videa jako velikost, ořezávat apod.

Po zaškrtnutí Enable Crop můžeme oříznout část obrazu ze všech stran. Zadává se jako počet bodů od kraje, 0 je tedy bez oříznutí. Povolením Enable resize lze měnit velikost výsledného videa. Máme na výběr ze čtyř metod:

• 1. Bilinear (Very Soft) - vždy dva body se propojí přímkou a nový bod leží někde na této přímce. Vhodné především pro zmenšování, eliminují se zubaté okraje objektů
• 2. Bicubic (Soft) - u všech tří metod Bicubic dochází k aproximaci proložení tří bodů parabolou. Tato metoda neztrácí ostrost objektů a je vhodná hlavně pro zvětšování. S ostrostí (Soft->Normal->Sharp) není dobré to přehánět, protože mohou opět vznikat "zubatice" (tato metoda se používá u stolních přehrávačů pro zvětšování VideoCD formátu na plné rozlišení)
• 3. Bicubic (Normal)
• 4. Bicubic (Sharp)

Psychovisual Enhancements povolí přerozdělování bitratu a dat v jednotlivém snímku i v sekvencích videa tak, že berou v úvahu citlivost lidského oka a jeho neschopnost vidět některé detaily při pohybu. Dělá v podstatě to samé co MP3 u zvuku, které také odstraňuje ze zvuku ty tóny, které jsou pro lidské ucho špatně slyšitelné, např. při překrytí jiným tónem. Tato volba může zhoršit obraz, což bude viditelné hlavně při zastavení videa, takže bych byl opatrný při jeho používání. Může se ale hodit, pokud pracujeme s menším rozlišením a potřebujeme velmi nízký bitrate.

Pre-Processing Source odstraňuje šum ze zdroje, což za určitých okolností (hlavně u nahrávek z analogových zdrojů jako TV vysílání, VHS) může snížit nároky na bitrate. Filtr v podstatě dělá jediné - "rozmaže" jednotlivé pixely do sebe (aritmetický průměr přilehlých bodů), ale snaží se vynechat okolní body s příliš odlišnou hodnotou, aby nerozmazal hrany objektů a nezničil ostrost. Čím více bodů se použije pro rozmazání, tím více se odstraní šum, obraz ale bude vypadat "plastičněji". Na výběr máme z (od nejmenšího efektu k největšímu vyhlazení) Light, Normal, Strong a Extreme. Jak dobrý je tento filtr se ukáže až časem, lze samozřejmě použít jži osvědčené filtry ve video editoru.

V dalším poli lze nastavit jak často se mají vkládat klíčové snímky (Key frames) - I-framy. Tyto snímky mají největší velikost a tak jejich časté vkládání rapidně zvětšuje velikost výsledného souboru. naopak příliš málo keyframů má za následek pomalé nebo nepřesné přemísťování aktuální pozice ve videu (seeking). Scene change threshold určuje citlivost na změnu scény, kam se také vkládají automaticky klíčové snímky.

V položce Source interlace se nastavuje typ zdrojového videa a možnost zapnutí Deinterlace.

• All frames are progressive - zdrojové video je neprokládané (nebo po deinterlace ve video aplikaci), deinterlace je vypnutý
• All frames are interlaced - zdrojové video je prokládané a zapíná se deinterlace
• Intelligent IVTC/deinterlace - zapíná inverse telecine, tedy dochází ke zpětnému převodu filmového materiálu, dělá se jen u NTSC, takže pro PAL nemá význam. Mění se framerate ze 30 nebo 29.97 na 24, takže se ukládá jen do MP4 souboru, AVI soubor vytvořený video aplikací neobsahuje obrazová data.

Basic Video Deinterlace zjednodušuje processing, což vede ke zvětšení rychlosti, ovšem není tak kvalitní. Deinterlacing by se nemělo používat pokud bylo zdrojovému videu měněna velikost ve svislém směru, protože již není zaručeno prokládání řádků po jednom.
Třetí záložka Advanced Parameters obsahuje další parametry určující přesnější chování kodeku.

Data Rate Control (RC) definuje přidělování bitratu jednotlivým snímkům a má velký vliv na výslednou kvalitu. Většinou ale nelze tyto parametry přesně určit a nastavení může záviset na charakteristice vstupního videa a optimální hodnoty vlastně neexistují, takže se nesnažte objevit nějaké "zaručené" hodnoty. Ty jsou na sobě také závislé, takže změna jednoho může mít i opačný efekt než požadovaný. Tyto hodoty nemají vliv při zvolení módu 1-pass quality-based, protože tam se nastavuje kvantizer rovnou konstantní. Minimum quantizer a Maximum quantizer určují minimální a maximální hodnoty kvantizace, které se mohou použít. Kvantizace přímo odpovídá určité kompresi, neodpovídá ale bitratu, protože závisí také na složitosti framu (včetně předchozích nebo následujících). Tyto hodnoty by měly odpovídat požadovanému bitratu, jinak může dojít k (i velmi výrazné) odchylce výsledného bitratu. Proto je také přednastaven poměrně široký rozsah, který odpovídá velkému rozsahu datového toku. Čím nižší kvantizace, tím vyšší kvalita, a naopak. RC Averaging nastavuje počet snímků, které se průměrují pro dosažení požadovaného bitratu a kvantizace. Určije tedy i dobu zapomínání a "hloubku" reakce na změnu komplexnosti scén. Vyšší hodnoty by měly více zvyšovat kvalitu ve složitějších (rychlejších) scénách a zhoršovat v pomalých scénách. RC reaction určuje rychlost reakce na změnu komplexnosti scén. Čím vyšší hodnota, tím rychlejší reakce. RC up/down reaction pro změnu určuje citlivost na změnu pohybu v obraze a tedy i rychlé/pomalé scény. Vyšší hodnoty zlepšují rychlé scény, zvětšuje se ale nárok na bitrate.

Data partitioning mění uspořádání streamu do paketů, které jsou vhodné pro přenášení po internetu a jsou odolnější proti chybám při přenosu, protože jsou nezávislé na ostatních a mohou být samostatně dekódovány.

Performance/Quality nastavuje váhu mezi rychlostí enkódování a výslednou kvalitou. Slowest generuje co nejlepší kvalitu při nejpomalejším enkódování. Ostatní jsou určeny při enkódování v reálném čase, jinak není dobré je používat.

DivX MP4 Creator skouží pro převod AVI souboru s videem DivX do nového formátu souboru DivX (.MP4 nebo .divx). Zadá se vstupní (Input) a výstupní (Output) soubor, popř. i soubor pro výpis informací o převodu (Conversion log file) a stiskem Create začne převod. Jde pouze o kopírování, nedochází k převodu, takže je velmi rychlé.

Na čtvrté záložce Manage settings je možné ukládat jednotlivá nastavení kodeku do profilů, takže není nutné vždy vše přenastavovat. Myslím, že zde neí co popisovat, přesto pro úplnost:

• Add codec settings - přidá nový profil do seznamu
• Replace settings - nahradí vybraný profil, slouží pro úpravu profilů (načíst nějaký, změnit parametr a stisknout toto pro uložení)
• Delete settings - smaže profil
• Load settings from file - načte nastavení ze souboru, vhodné pro výměnu nastavení s někým jiným (např. po internetu)
• Save settings to file - uloží nastavení do souboru
• Apply selected - načte nastavení vybraného profilu

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řejmě 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 ...