Porovnání DivX 3 a 4

Důvodem, proč jsem předělal toto porovnání, je hlavně vydání DivX 4.0 beta 2. V této verzi je opraveno mnoho z chyb, které jsem minule zmiňoval a já jsem zase v tomto článku opravil nějaké své smyšlenosti... no a taky jsem kodeky vyzkoušel na více různých videích s různými nastaveními.

Specifikace

Zdroj videa:
Asi 20 náhodně nagrabovaných videí v plném PALu (768×576) a PALu/2 (384×288). Nejdelší mělo něco přes 2 minuty. Nahráváno bylo ze stanic s velmi čistým signálem, většinou satelitních a pokud možno přímé přenosy. V plném PALu bylo grabováno s použitím kodeku PICVideo Motion JPEG 2.10.0.25 při kvalitě 19, jinak Huffyuv 2.1.1.

DivX 3.11 alpha:
komprese v Nandubu 1.0 rc2
různé bitraty
doporučené nastavení od Dooma9 s ohledem na velikost obrazu
samozřejmě 2-pass

DivX 4.0 beta 2:
komprese ve VirtualDubu 1.4.5
různé bitraty
ostatní nastavení většinou default (pokud jinak, je to zmíněno)
většinou 2-pass

Pro plný PAL jsem volil záměrně bitrate 2000 kb/s, protože zdroj signálu byl dost čistý a na nízkém bitratu (vzhledem k rozlišení) se nejlépe pozná kvalita kodeku. Pro PAL/2 jsem většinou nechal defaultních 780 kb/s, které mi při čistém signálu připadají akorát.

Poznámky

DivX4 má už interně 3 základní mody enkódování:

• 1-pass se nejlíp hodí pro realtime capture, když výsledné video nechceme dále upravovat, nastavený bitrate má v tomto modu (logicky) největší odchylku od skutečného.
• 1-pass quality-based sami autoři doporučují pro realtime capture, pokud chcete výsledné video dále upravovat (konkurence MJPEG ;-). Jediný důležitý údaj pro nastavení je zde Quality, defaultní hodnota 85 % je však pro pozdější editaci nízká. Všechny snímky jsou komprimovány ve stejném poměru bez ohledu na jejich složitost. Zajímavé je, že při nastavení kvality ke 100 % je výsledný bitrate i vícenásobně vyšší než maximálních 6000 kb/s.
• 2-pass je vlajkovou lodí tohoto kodeku, jediná možnost pro kvalitní DVD či TV archivaci. Nevýhodou se může zdát, že po provedení first passu se musí kodek ručně přenastavit na second pass a pak znovu spustit převod. To ale není pravda, např. ve VirtualDubu stačí přidat do job listu nastavení pro převod do first a second passu a pak přes Job control spustit nepřerušený 2-pass. Pro ty línější určitě udělá Nando nějakou automatizaci do svého Nandubu.

Ač se to nemusí zdát, velmi důležitou volbou je Performance/quality ve stupních od Slowest do Fastest. Osobně doporučuji použít, kde to jde, Slowest (určitě při 2-passu). Při Fastest je snímek samozřejmě zkomprimován nejrychleji, ale má větší velikost a dle mých testů nižší kvalitu než při Slowest.

Je dobře, že v betě 2 vývojáři nahradili v nastavovacím dialogu výraz 'Crispness' za 'Frame dropping'. Pletlo se to s Crispness v DivX3. Tato volba je u DivX4 myšlena odlišně, a to vynecháváním snímků s velmi nízkou informací. Použitelné je to pro videa s velmi nízkým bitratem.

V betě 2 taky přibyla externí podpora nastavení postprocessing filtru, takže už můžeme nastavit postprocessing kvalitu, jas, kontrast a barvu z WMP 6.4 a jeho nadstaveb (Zoom Player, BSPlayer, ATV2000 Player, PowerDivX NextGen, ...).

DivX4 je dobře vybaven pro převod TV signálu - obsahuje interní a velmi rychlý deinterlace. Tento deinterlace je postaven na blend metodě, která mě osobně nevyhovuje. V současnosti se mi líbí nejvíc Deinterlace - area based od Gunnara Thalina s nastavením raději interpolace než blendu půlsnímků. Tento způsob jsem použil při převodu full PAL videí do DivX3 i DivX4, aby byly dodrženy stejné podmínky. Samozřejmě pro realtime grabování v plném PALu nezbyde jiná volba, než interní deinterlace použít, ale i tak si netroufám říct, jak silný procesor je k tomu potřeba.

Výhody a nevýhody

Nejprve začnu nevýhodou DivX4: nedodržuje nastavený bitrate tak dobře jako DivX3 ve spojení s Nandubem. U testovaných videí Nandub dodržoval bitrate téměř přesně, DivX4 byl vždy pod ním. Např. u 2-pass: bitrate 2000 kb/s - Nandub 250 kB/s, DivX4 238 kB/s; bitrate 780 kb/s - Nandub 98 kB/s, DivX4 88,8 kB. O 1-passu netřeba mluvit, zde nastavený bitrate nesedí ani u jednoho DivX, u kterého je to lepší si netroufám říct.

Zkusil jsem taky, jak kodeky dodržují, pokud jim nastavíte velmi malý bitrate. O DivX3 (bez Nandubu) je známo, že i když nastavíme bitrate třeba 10 kb/s, kodek sám nastaví pro něj minimálně akceptovatelný bitrate, třeba 300 kb/s. Testoval jsem to na asi minutovém videu v PALu/2 při nastavení 200 kb/s. Zde si nejlépe vedl DivX4 2-pass, který měl výsledný bitrate 21 kB/s, dále Nandub se 40 kB/s. 1-pass jsem zkusil též, pro Slowest byl bitrate 47 kB/s, Fastest 71 kB/s. Nedalo mi to a zkusil jsem 1-pass s nastavením Maximum quantizeru na 20 (zjednodušeně řečeno: kolikrát max. se může zkomprimovat frame). Výsledky byly lepší: Slowest 32 kB/s, Fastest 38 kB/s.

K rychlosti enkódování: Píše se, že byla zvýšena až 4×, ale je tím myšleno vůči verzi OpenDivX 4.0 alpha 50. V porovnání s DivX3 je DivX4 trošku rychlejší, přibližně o 5 % v 2-passu (při nastavení kodeků uvedeném výše).

Prošel jsem si výsledná videa obrázek po obrázku ve VirtualDubu, tzn. bez použití vylepšovacích filtrů a z hlediska obrazu jsem již našel jen samá superlativa pro DivX4:

• I když mělo DivX4 video nižší bitrate, kvalita obrazu byla lepší, je to jednoduše vidět v přesnějším podání barev a hlavně při pohybu se vyskytuje míň čtverečků. Zastavil bych se u barevného podání - v několika případech přece jen bylo lepší u DivX3, ale dozajista to je způsobeno menším bitratem DivX4.
• Nadšen jsem byl u prolínačky - zkuste si zkomprimovat přechod od konce znělky Sportovních novin na nově a zjevením moderátora, u DivX4 byl snímek v přelomovém bodě přechodu skoro jako originál, u DivX3 zas až moc podřadný. Podotýkám, že oba kodeky při přechodu nepoužily key-frame. Stejné to bylo i u mlhy, dýmu, "dobrých" duchů - DivX3 hodně kostiček, DivX4 pohoda.
• Při zvětšeném obrazu je vidět, že DivX4 produkuje méně komprimačních chyb, myslím hlavně ty v rámci čtvercového segmentu.
• Potěšilo mě, že u DivX4 už nedochází ke slévání ploch s podobnými barvami, např. člověk s kalhoty a svetrem podobné barvy nevypadá jako v pytli, viz DivX3.
• Při rychlých pojezdech kamery a zabírání 2 ploch kontrastních barev jsou u DivX3 znatelné duchy, takové zbytkové artefakty, u DivX4 jsou minimálně. Jako příklad úvodní scéna Mumie 1.
• Nespornou výhodou DivX4 je jednoduchost nastavení oproti Nandubu, i když zase nejde nastavit tolik parametrů. S tím souvisí další věc: 2-pass DivX3 uděláme jen v Nandubu, 2-pass DivX4 snad v každém video editoru.
• Minule jsem se zapomněl zmínit, že DivX4 interně umí dosadit key-frame při změně scény, ale já to bral od doby DivX3 VKI a Nandubu jako samozřejmost. Zde vidím malou nevýhodu u DivX4, kdy se občas vyskytnou i 3 key-framy za sebou. V Nandubu se dá nastavit prevence před key-framy ihned za sebou zvolením alternativního Scene change detection mechanismu.
• U DivX4 konečně, nejlépe ve spojení s The Playa, chodí plynule přehrávání full PAL videa s CPU 650 MHz.
• Od bety 2 si DivX4 pamatuje poslední nastavení.

The Playa,
v době psaní verze 0.6.1, je jednoduše vypadající player, který má ale všechny vymoženosti jako ostatní přehrávače, včetně podpory skinů a titulků. Má ještě své mušky, které určitě budou vyřešeny. Umí přehrát DivX3/4 a vytěžuje při tom CPU v obou případech méně a rovnoměrněji oproti WMP (nedokážu si vysvětlit proč). U DivX3 i 4 jde nastavit CPU Quality (nyní Image postprocessing level o 7 úrovních), samozřejmě při vyšších hodnotách vytížení CPU značně stoupá...

Zkoušel jsem v Playa přehrávat některá DivX3 videa a produkovaný obraz byl trhaný po určitých pravidelných intervalech. Přitom WMP 6.4 a klony přehrávají tato videa plynule. Nejdřív jsem si myslel, že je to chybou v DivX4 dekodéru (beta 1). Ale protože trhání přetrvává i v betě 2, kdy Playa využívá pro DivX3 videa DivX3 dekódovací filtr (aspoň pod Windows 98), tak si teď myslím, že za to může VBR MP3 audio a jeho interleaving, a s tím má asi Playa problémy.

V The Playa se najdou i další problémy:

• Pod Windows 98 někdy přestane reagovat, i když video je dál přehráváno.
• Nelze použít jako univerzální player, protože ne-DivX videa nepřehraje, napíše chybovou zprávu 'The location you selected could not be opened'.
• V dialogu nastavení DirectShow filtrů jsou zobrazeny všechny (kromě DivXG400), nastavit jdou ale jen DivX3 a DivX4 dekodéry.
• Při enkódování používám volbu nastavení 'Default decoder postprocessing level'. Toto nastavení The Playa ani ostatní přehrávače zatím nevyužívají.
• Posuvník se špatně ovládá u konce, já to většinou přeženu a video jede od začátku.
• Bylo by dobré ukládat úroveň hlasitosti.

Realtime grabování s DivX4

(Všechna zde zmíněná videa byla grabována v rozlišení 384×288, YUY2.) V porovnání z hlediska kvality je i v této oblasti vítězem DivX4, platí stejné výhody jako uvedené výše. Z hlediska vytížení CPU a dodržování nastaveného bitrate však už nelze vítěze jednoznačně určit, oba tyto údaje velmi závisí na konkrétním vysílaném signálu. Nagraboval jsem pár videí s DivX3 (High- i Low-Motion) a pár s DivX4 při nastavení Slowest, vše při různých bitratech. Vytížení CPU bylo přibližně na stejné úrovni, pro DivX4 je plusem rovnoměrnější vytížení. Nyní už jen o DivX4:

Pro realtime grabování je doporučeno nastavení Performance/quality na Fastest, na CPU 650 MHz ale chodí grabování v PALu/2 při Slowest bez drop-framů (při rozumném bitrate a pouze pod Windows 9x). Jen pro doplnění, s tímto procesorem jsem se na grab full PALu 25 fps nechytal ani s Fastest. Taky záleží v jakém programu a Windows grabujete. Zkoušel jsem VirtualDub 1.4.5, ATV2000 PR10.2, MoreCapture 1.1a, iuVCR 3.1.0.103 ve Windows 98 a 2000 (pokud to šlo).

Na okraj, spíše než na Windows asi záleží, jaké drivery používáte, jestli VfW nebo WDM. Pod Windows 98 nejlépe vychází VirtualDub, jak z hlediska rychlosti, tak komfortu. MoreCapture je také dobrý, má však omezení na 384×288 a na některých stanicích přidává do obrazu příčné pruhy. Na posledním místě ATV, u kterého je uměním nastavit ho, aby capture fungovalo, jak má: Stiskněte F8 pro Capture panel. Tlačítko pro nastavení kodeku nefunguje, musíte stisknout F9. Potom přes popup-menu nastavte Driver - Format na 384×288 (i když před tím Capture panel signalizuje 384×288, není nastaveno). A nakonec zase přes popup-menu nastavte Capture - Video na YUY2 (zase platí, co vidíte před nastavením na Capture panelu i v popup-menu, nemusí být pravda).

Tímto jsem trošičku naznačil chybu DivX 4.0b2 (objevil Lucifer), která se vyskytuje pouze pod Windows 9x (VfW), pouze v rozlišení 384×288, pouze při nastavení grabování do 24-bit RGB (trochu je to vidět i v 32-bit ARGB) a pouze při realtime grabování. Jedná se o to, že při pravém okraji obrazu je navrch přidán zelený pohybující se poloprůhledný přerušovaný pruh o šířce 2 pixely. Tohoto jsem si nevšiml, protože většinou grabuju s MoreCapture, kde tato chyba není, v ATV a VirtualDubu ale je. Ze zmíněného MoreCapture plyne obejití této chyby, dokud nebude opravena - dovoluje totiž capture pouze v (mimochodem rychlejším) YUY2, kde zelený pruh nevzniká. VirtualDub má v Capture modu defaultně nastaveno 24-bit RGB, takže ho přenastavíme (v menu Video - Set Custom format nastavte YUY2), pro ATV je nastavení uvedeno výše.

Windows 2000 (WDM) mně v realtime grabu s DivX4 zklamaly. V žádném programu jsem nedosáhl grabování bez drop-framů při Slowest. Přenastavil jsem tedy kodek na Fastest. Nejlépe si při tomto nastavení vedl iuVCR, který jen-tak-tak stíhal bez drop-framů. Na druhém místě ATV s hodně drop-framy a na dalším VirtualDub s ještě více.

Zhodnocení

Tato verze DivX4 je přelomová. Já to vidím na smrt DivX3, pokud bude ve finální verzi akurátnější bitrate a opraveny další chybky jako: pod Windows 98 VirtualDub spadne při enkódování do DivX4 v rozlišení 768×576; pod Windows 2000 nelze v žádném přehrávači použít pro DivX3 videa DivX3 dekódovací filtr a další chyby uváděné např. u Dooma9. Optimální by bylo, kdyby se do vývoje zapojil Nando ;-).

Úplně na závěr, chyby které jsem našel, jsem odeslal na DivX server. Pokud nějaké najdete, bude slušností to udělat taky, i když při počtu uživatelů tam nejspíš již budou oznámeny.