Zpracování videa ve VirtualDubModu
Kapitoly článků
Nebudu se zde zabývat samotným záznamem videa. To se značně liší od použitého grabovacího hardware, či v případě TV tunerů podle osazeného čipu a použitých ovladačů (Bt878, Bt881, Philips 713x ad.) - vydalo na samostatný článek. Problém zpravidla pro méně zkušené grabovače nastává ve chvíli, kdy TO mají převést do nějaké úspornější formy. V tu chvíli většinou nastupují rady od kamarádů, kterým také radili nějací kamarádi a pak je občas na katastrofu zaděláno. Mohl bych strašit malé děti historkami o filmech v rozlišení 320×240 v DivX 3 Low Motion, ripnutých na 2CD s 15fps a zvukem 8bit 11kHz mono MP3. Postupů, jak zpracovat film je mnoho a některé se opírají o zálohu na DVD-Video disk. To je však značně neúsporná metoda, opírající se o zastaralý kompresní algoritmus MPEG-2, kterým nás v současné době masírují filmová studia a videopůjčovny ve snaze vytřískat z umírajícího formátu ve smrtelné křeči poslední dolary.
Tento článek vám poskytne alternativní postup, kterak uložit vaše video s co nejvyšším poměrem kvality vůči velikosti výsledného videa. Každému již musí být v tuto chvíli jasné, o co půjde. Samozřejmě o to, co nás čeká ve standardech přicházejících na trh, a to MPEG-4 kompresi.
Než se v diskusi pod článkem začnete všichni divit, proč proboha matroska, proč ne DivX, proč ne WMV9, proč ne tohleto a támhleto, tak vezměte v úvahu třeba otázky jako: proč tento postup používám již skoro 2 roky, proč jsem ochotný se za něj bít na tomto serveru, je skutečně M$ AVI ten jediný správný formát. Nikoho nenutím používat zrovna matrosku a ogg zvuk. Pokud budete mít zájem, mohu poskytnout i postupy pro klasické AVI a zvuk v MP3, DVD-Video anebo třeba také vcelku neznámý OGM Ogg Media Stream. Nyní již zpět k tématu:
Vše, co budete k použití následujícího postupu potřebovat je zde:
- všemocný program VirtualDubMod (dále jen jako Vdub)
- některý z MPEG-4 kodeků, např. DivX, XviD, 3ivX, MS MPEG-4. Moje doporučení zní XviD
- pokud je vaše zdrojové video prokládané, tak i Smart Deinterlacer Filter
- dále pak (třeba) OGG kodek na zvuk, já osobně si vystačím s OggDrop aplikací
- nakonec něco, co si poradí s Matroska containerem: Matrsoka Pack Full resp. mPlayer resp. VLC Player (záleží na vašem vkusu).
Nejrpve si někam rozbalte Vdub (já osobně pro takovéto aplikace používám univerzální adresář C:\Drivers\) a do adresáře C:\Drivers\VirtualDubMod_1_5_10_1_All_inclusive\plugins rozbalte Smart Deinterlacer Filter. Nebudu tu popisovat, jak rozbalit ZIP soubor, to umí třeba Total Commander nebo i samotná Windows XP (díky Bille :-).
Dalším krokem je nainstalování kodeku, který použijeme. Já se zaměřím na XviD (a vám bych to doporučil také, protože další pasáže se budou vztahovat právě na něj). Pro účely tohoto testu jsem použil aktuální verzi XviD-1.1.0-Beta1-16012005.
Následně si někam rozbalte OggDrop (opět předpokládám, že to zvládne každý). No a pokud ještě nepoužíváte Matroska Pack, mPlayer nebo VLC, tak si aspoň nainstalujte Matroska Pack.
Volby v instalaci Matrosky nastavte třeba podle obrázku.
- RealMedia Splitter stejně vyžaduje nainstalovaný RealPlayer, takže je to zbytečné (lepší je použít Real Alternative)
- VSFilter občas způsobuje tuhnutí při přehrávání videí, takže jej také neinstalujte
- pokud chcete přehrávat všechny MPEG4 videa společným dekodérem, můžete si nainstalovat, sice starší, ale přesto kvalitní verzi ffdshow, bundlovanou s Matroska Packem
- doporučuji též nainstalovat MatrixMixer, ten pak tvoří jakousi mezivrstvu při přehrávání a umožňuje vám třeba měnit hlasitost audio stopy, pokud vaše zvukovka nestíhá (skutečně jsem se setkal s tak tichou zvukovou stopou ve filmu, že ani mixer zvukovky na max. v kombinaci s maximální hlasitostí reproduktorů nebyl dostatečný a pomohlo pouze umělé přebuzení zvukové stopy právě pomocí MatrixMixeru)
Pokud jste majitelem trochu bystřejších očí, určitě si v průběhu tohoto článku všimnete, že mnou ripnutá okna aplikací se občas poněkud liší od toho, co máte na monitoru vy. Je to způsobeno tím, že jsem je lehce předělal, abyste u každého většího obrázku nemuseli klikat na náhled pro zobrazení v plné velikosti. To by značně kazilo váš požitek ze čtení :-). Strukturou však tato típnutá okna odpovídají skutečnosti, takže by snad neměl nastat problém. Pokud by se však přece jen mezi vámi našel nějaký puritán, nechť mi dá vědět v diskusi a já si doma vysypu nějaký ten popel na hlavu (obrázky ale rozhodně předělávat nebudu).
Tak a konečně se můžeme pustit do zpracování (ještě malá poznámka, já v postupu jako zdrojové video používám soubor bez komprese, majitelů DV kamer se bude týkat nějaká verze DV kodeku, tuneristů typicky např. Huffyův nebo MJPEG kodek)
Prvním krokem je otevřít zdrojový soubor ve Vdubu. To lze provést několika způsoby
- drag&drop přes wokna
- ve Vdubu Ctrl+O
- nebo použít můj oblíbený: Vdub mít v liště Total Commanderu a jen přetáhnout (v podstatě subvarianta a)
Vdub poté bude vypadat nějak takto:
Teď je ta pravá chvíle na to, upřesnit si několik detailů. Obrázek odpovídá rozlišení 1024×768, zdrojové i cílové video pak 720×576 (zdrojem byla DV kamera). Oko znalce pozná, že zdrojové video je prokládané to bude první věc, jíž budeme řešit po seznámení se s Vdubem. Důležitá informace je to, že v okně„finální video“ vidíte, jak bude vypadat výsledný soubor po aplikování vybraných filtrů (které probereme podrobněji dále). Timeline označuje zjednodušenou časovou osu, pomocí níž se ve Vdubu velice rychle orientuje v editovaném souboru. Vaše pozice po otevření souboru je vždy na prvním snímku, který je také snímkem klíčovým.
Správný čas na vsuvku:
- kodeky jako MJPEG, Huffyův či Uncompressed video mají všechny snímky klíčové, anglicky Keyframe ve Vdubu označené [K]. Tyto snímky jsou uloženy celé a obsahují tak veškeré informace, vztahující se k tomuto snímku
- kodeky jako DivX, XviD používají 3 typy snímků:
- keyframes (klíčové)
- Predicted ty nejsou uloženy celé, obsahují pouze informaci o změně oproti nejbližšímu předchozímu klíčovému snímku. Pokud se tedy v časové ose posunete na P-snímek, Vdub jej nejprve musí dopočítat
- Bidirectionaly-Predicted tyto snímky ukládají pouze změnu oproti dvěma nejbližším klíčovým snímkům (před a za) jejich dopočítání je časově náročnější než u P-snímků
Poznánka pro experty: toto je pouze zjednodušený popis, nekamenujte mě za to v diskusi.
Z principu věci je hned jasné, že klíčové snímky jsou nejjednodušeji dekódovatelné (a tudíž přehratelné), protože je k nim okamžitý přístup. S P-snímky je to komplikovanější, ale zase je jejich velikost menší, než u klíčových snímků. Nejlépe z hlediska velikosti výsledného videa jsou na tom B-snímky, neboť mají nejmenší velikost, jejich dekódování je však nejpomalejší (mám na mysli dekódování při pohybu v časové ose Vdubu, nikoliv při přehrávání videa).