Popis problému

Avery byl na chybu upozorněn jedním z návštěvníků jeho stránek a tak se ji jal prověřit v Vistě v RTM verzi. Napsal si testovací utilitku a zjistil, že i toto finální sestavení systému obsahuje inkriminovanou vadnou knihovnu generující chybné RIFF struktury v .avi souborech. Chování si můžete sami prověřit na miniaturním testovacím videu z jeho stránek, já k němu snad jen dodám, že při přehrávání „systémovou“ cestou ve Windows XP (tedy skrze systémové knihovny) je vše v pořádku, stejně tak i v Mplayeru (windowsový build MPUI) či postarším VirtualDubModu, naproti tomu VLC i Avidemux jej nezvládají.

Knihovna ukládá chybně „movi LIST chunk“ sekci hlavičky, která nese potřebná metadata.

RIFF

Krátce si teď odbočme k RIFF (Resource Interchange File Format) formátu pro uložení metadat, který .avi používá. RIFF datová struktura se skládá z „chunks“, kde hlavní roli mají prvky RIFF a LIST, jenž uvádějí první „chunk“, který dále odkazuje na další „subchunks“, z čehož jasně plyne, že správná struktura LIST sekce a prvního „chunku“ je pro korektní práci s daty klíčová.

Typický .avi soubor pro ukázku začíná ve stylu „RIFF / AVI LIST…“ a soubor pak v hlavičce obsahuje jak sekci informující o kodeku ve stylu vidsH264, tak třeba doprovodná metadata o nastavení kompresních parametrů kodeku, opět na ukázku:

x264 - core 54 svn-614 - H.264/MPEG-4 AVC codec - Copyleft 2005 - http://www.videolan.org/x264.html - options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=5 brdo=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=2 b_pyramid=0 b_adapt=1 b_bias=0 direct=1 wpredb=1 bime=0 keyint=250 keyint_min=25 scenecut=40(pre) rc=2pass bitrate=1500 ratetol=1,0 rceq='blurCplx^(1-qComp)' qcomp=0,60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20,0 qblur=0,5 ip_ratio=1,40 pb_ratio=1,30.

Tyto ukázky pochází z .avi souboru vytvořeného testovací verzí programu Avidemux 2.4.0 (r2692), který komprimoval dané video pomocí x264 kodeku build 614 (používám z důvodů bezproblémové funkčnosti multithreadingu, tedy komprese videa na více než jednom procesorovém jádru, to jen tak na okraj), jehož veškerá použitá nastavení jsou uložena ve finálním videu.

Ale zpět k Windows Vista. Příslušná část je v hlavičce obsažena hned dvakrát a to na neobvyklých místech, první „movi LIST“ pak dokonce začíná jakýmsi „chaosem“, vinou kterého je další zpracování programem v rámci hlavičky souboru potenciálně poškozeno. Jedním z důsledků dle Averyho je prakticky nemožnost generovat .avi v jednom průchodu. AVI totiž jakožto správný RIFF soubor, používá řadu „chunk“ prvků, v jeho případě k predikci velikosti „movi“, což se s poškozenými daty na počátku načítání hlavičky zkrátka nedá realizovat. Dané údaje v AVI souborech se nedají principielně ukládat postupně během procesu komprese (nebo nového ukládání, na tom nezáleží).

Aby toto bylo řešitelné, generuje se AVI nejprve s falešnými velikostmi polí a teprve po dokončení ukládání dat v něm jsou tyto pole zpětně naplněna koretními hodnotami a umístěna na správná místa v souboru. A s vadnou knihovnou ve Vistě je problém ten, že buď někdo v Redmondu tento kód zabezpečující zpětné uložení metadat „zvrzal“ tak, že dochází k chybě při zápisu finální „movi“ hlavičky na správné místo, nebo se nějak daří otevírat dva „movi chunks“, což je také špatně.

Avery pak dodává, že ukládání .avi ve VirtualDubu pod Vistou se netřeba bát, on má v programu napsán vlastní kód pro ukládání tohoto formátu, díky čemuž jím vytvářené .avi soubory jsou korektní. Sám pak dále popisuje metody, jak souboru napravit hlavičku, aby měla konzistentní index a opravit celou RIFF strukturu, což učiní soubor sice konzistentním, ale nadále nekompatibilním s AVI specifikacemi, díky čemuž má VirtualDub problém mezi relativním a absolutním indexováním v souboru, ale to již brzy nebude tak důležité. Chystaný VirtualDub 1.7.2 si s těmito soubory poradí, protože Avery ještě před odhalením viníka (Vista) na tomto problému pracoval v rámci jeho programu.

Praktická ukázka

Samozřejmě nám to nedalo a sami jsme se rozhodli ověřit existenci tohoto problému ve finálních Windows Vista Ultimate x86 (konkrétně šlo o build 6000). Pro ukládání .avi souboru jsme použili zcela náhodně vybraný program All Video Converter 3.8 v Trial verzi (proto ty vodoznaky v obraze). Dané zdrojové video s přírodovědcem Dr. Radkem Zelenkou (pracujícím momentálně „kdesi daleko“ v utajení, to jen tak naokraj :-) bylo prohnáno stejným postupem rekomprese videa jak ve zmiňovaných finálních Windows Vista, tak běžných Windows XP SP2. Video z Visty je chybně posunuto přesně dle očekávání, navíc je poškozena i zvuková stopa, ve které to poměrně nehezky prská. Stejným postupem vzniklé video ve Windows XP je zcela v pořádku. Oba obrázky zachycené z výsledných .avi souborů pochází z VirtualDubu, stejně se video chová i při přehrávání v Mplayeru či VLC, naproti tomu Microsoft Windows Media Player i to z Visty přehrává bez potíží (zvláštní, asi to mají nějak ošetřeno, nicméně to nic nemění na faktu, že video není v pořádku a nesplňuje specifikace).

Program Avidemux, který používá na vše vlastní interní funkce, pak má s otevřením poškozeného .avi z Visty ještě větší problémy než VirtualDub.

Závěr

Tento článek měl upozornit na problém, který se stále (minimálně v některých verzích) nachází v nejnovějším dílu Redmondského giganta. Postihuje všechny aplikace, které k ukládání .avi souborů používají standardní cestu skrze DirectShow a tudíž systémovou AVIfile knihovnu. A je více než ironické, že je to právě takovým hypem doprovázený nový OS firmy Microsoft, který neumí správně nakládat s .avi soubory, tedy formátem, který sám Microsoft před patnácti lety vytvořil a který interně používá Resource Interchange File Format, vyvinutý o rok dříve opět v Microsoftu (ve spolupráci s IBM).

Dobrým způsobem, jak se tomtuto problému elegantně vyhnout, je používat jiný formát pro uložení videa, který neukládají přímo Windows Vista pomocí AVIfile knihovny. Já sám za sebe pak mohu jen doporučit formát souborového kontejneru známý pod názvem Matroška a příponou .mkv. Používám jej v podstatě od jeho vzniku (zhruba čtyři roky) a nemohu si stěžovat, byť na editaci je mírně řečeno „nevhodný“.