MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Klient prostředí GColl pro Microsoft Windows BAKALÁŘSKÁ PRÁCE
Petr Němeček
Brno, 2010
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Poděkování Na tomto místě bych chtěl poděkovat všem, kteří mi nějakým způsobem při vypracování práce pomohli, zejména jsou to doc. RNDr. Eva Hladká, Ph.D. a Mgr. Pavel Troubil.
Shrnutí Účelem této bakalářské práce je analyzovat videokonferenční prostředí GColl a za pomoci získaných znalostí portovat klienta tohoto prostředí na operační systémy Microsoft Windows. Tento klient umožní uživatelům platformy Windows účastnit se GColl videokonferencí bez ohledu na to, jestli ostatní účastníci používají také Windows, nebo nějaký unixový systém.
Klíčová slova GColl, Windows, videokonference, VIC, portování programu
Obsah
Obsah.................................................................................................5 1 Úvod...................................................................................................7 1.1 Popis struktury práce ........................................................................ 7 2 Analýza výchozího stavu..........................................................................8 2.1 Operační systémy a portování aplikací mezi nimi ...................................... 8 2.1.1 Unixové operační systémy ........................................................... 9 2.1.2 Microsoft Windows .................................................................... 9 2.2 VIC ............................................................................................. 10 2.2.1 Programovací jazyk C ............................................................... 11 2.2.2 Programovací jazyk C++ ............................................................ 11 2.2.3 Skriptovací jazyk Tcl ................................................................ 11 2.2.4 FFmpeg ................................................................................ 12 2.3 GColl .......................................................................................... 12 2.3.1 Zprostředkovaný oční kontakt ..................................................... 12 2.3.2 Paketové zrcadlo .................................................................... 13 3 Popis použitých nástrojů........................................................................14 3.1 Virtualbox .................................................................................... 14 3.2 Visual studio ................................................................................. 14 3.3 PSPad ......................................................................................... 15 3.4 MinGW ........................................................................................ 16 3.5 MSYS ........................................................................................... 16 3.6 NASM,YASM ................................................................................... 16 3.7 Wireshark ..................................................................................... 16 4 Postup práce.......................................................................................18 4.1 Použití virtuálních počítačů ............................................................... 18 4.2 Převod na novou verzi vývojového prostředí ........................................... 19 4.3 Postup kompilace a řešení problémů .................................................... 20 4.3.1 Microsoft Active Template Library (ATL) ......................................... 20 4.3.2 Microsoft DirectX SDK ............................................................... 21 4.3.3 Assembler ............................................................................. 21 4.4 Knihovní funkce a linkování ............................................................... 22 4.4.1 Kompilace knihoven FFmpeg ...................................................... 23
5
5 Testování...........................................................................................25 5.1 Popis hardware použitého při testech ................................................... 25 5.2 Nastavení a testování síťové komunikace .............................................. 26 5.3 Postup a výsledky testování ............................................................... 26 6 Výsledky práce....................................................................................28 6.1 Dosažené výsledky ......................................................................... 28 6.2 Popis odevzdaných balíků ................................................................. 28 7 Závěr................................................................................................30 Literatura...........................................................................................31 Příloha..............................................................................................33 Návod na kompilaci vlastní verze programu ................................................ 33
6
1 Úvod V dnešní době, kdy se komunikační technologie a internet staly běžnými součástmi našich životů, se mění i spousta zažitých zvyklostí. S tím, jak se neustále vylepšují možnosti komunikace na dálku, rozšiřuje se spektrum úkonů, které můžeme vykonávat vzdáleně bez potřeby fyzické přítomnosti. Dříve, když měl tým lidí řešit společně nějaký problém, museli si dohodnout místo, kam všichni sjedou, a kde budou společně pracovat. Tento přístup samozřejmě funguje, ale má svoje nevýhody, které se projevují tím víc, čím víc jsou sebe jednotliví členové týmu geograficky vzdáleni. Pokud je vzdálenost velké, spotřebuje se cestováním spousta času a v neposlední řadě také peněz. V dnešní době, kdy to již technika umožňuje, se rozšiřuje využívání videokonferencí, které umožňují vést jednání a týmovou spolupráci na dálku. Díky videokonferencím mohou fungovat například týmy, kde polovina týmu je někde a druhá polovina v jiném městě tisíce kilometrů daleko. Ani videokonference však v dnešní podobě nedokáže plně nahradit komunikaci tváří v tvář, protože neumí přenášet spoustu nonverbálních součástí komunikace. Na zlepšení právě v tomto směru je zaměřen videokonferenční systém GColl, jehož úprava je předmětem mojí bakalářské práce.
1.1 Popis struktury práce Práci jsem celkově rozdělil na sedm kapitol, z čehož první kapitola je úvod a poslední kapitolou je závěr. V kapitole číslo dva se zabývám výchozími podmínkami pro svoji práci a vysvětlením jednotlivých pojmů. Navazující kapitola je vysvětlující a popisuji v ní programy a nástroje, které jsem během práce použil. Kapitola čtyři záznamem postupu prací na programu, popisuji v ní jednotlivé kroky a úpravy v pořadí, jak jsem je prováděl. Následuje kapitola věnovaná testování a odhalování chyb, kde jsou vyjmenovány jednotlivé testovací konfigurace a provedené testy. Šestá kapitola obsahuje sumarizaci provedené práce, dosažených výsledků a popis balíků s programu odevzdaných společně s prací.
7
2 Analýza výchozího stavu V této kapitole se zabývám vysvětlením pojmů, rozborem zadání a jeho zasazením do širší problematiky. Dále se snažím popsat výchozí stav věcí souvisejících s mojí prací a nastínit úkoly, kterými se budu vzhledem k zadání věnovat.
2.1 Operační systémy a portování aplikací mezi nimi Definic toho, co je to operační systém, existuje celá řada podle toho, z jakého hlediska je na systém nahlíženo. Ve své podstatě je operační systém soubor programových komponent, ovladačů hardware a dalších součástí, které společně utvářejí prostředí pro běh uživatelských programů a procesů. Úkolem operačního systému je nabídnout sadu služeb, které mohou být následně využity jednotlivými programy. Tyto služby jsou (nebo by alespoň měly být) v rámci daného operačního systému jednotné a zajišťují tak, že programy nemusí samy řešit specifika různých konfigurací, různého hardware a podobně. Například když potřebuje program číst ze souboru na pevném disku, jednoduše využije volání systémové funkce, která mu čtení souboru zajistí, a díky tomu program vůbec nemusí řešit jaký typ disku je v počítači, jak se s ním pracuje a pomocí jakého souborového systému jsou data na disku zapsána. Ideální z hlediska tvůrců programů by bylo, kdyby všechny operační systémy poskytovaly stejné rozhraní neboli nabízely programům stejnou sadu funkcí, jenže realita je bohužel jiná. Každý operační systém zpravidla definuje vlastní specifické rozhraní, které nabízí programům, často se navíc rozhraní liší i mezi různými verzemi jednoho OS. Bohužel tedy nelze očekávat, že program napsaný pro jeden systém bude fungovat na jiných systémech. Ve většině případů bude fungovat na vyšších verzích daného systému, ale jinde ne. Pokud chceme, aby program fungoval na více operačních systémech, existuje několik možností jak toho docílit. Můžeme vytvářet více různých verzí zdrojového kódu přesně podle vlastností cílových systémů, anebo můžeme vytvořit univerzální zdrojový kód, který využívá jen funkce, které jsou mezi cílovými systémy kompatibilní. Jestliže už máme hotovou aplikaci a potřebujeme ji přenést na jiný systém, který není s aplikací kompatibilní, musíme ji takzvaně portovat. Portování programu znamená úpravu programu nebo jeho částí tak, aby fungoval na cílovém systému. Jak moc složitá taková úprava bude, záleží na mnoha faktorech. Asi nejdůležitější je, jestli se při tvorbě aplikace počítalo s tím, že by mohla být v budoucnu portována. Faktorem silně ovlivňujícím náročnost portování je míra rozdílnosti výchozího a cílového systému.
8
2.1.1 Unixové operační systémy UNIX je ochranná známka operačního systém vytvořený v Bellových laboratořích americké firmy AT&T v roce 1969. V současné době ji vlastní konsorcium The Open Group a mohou ji používat pouze systémy, které jsou certifikovány podle SUS (Single UNIX Specification). SUS je soubor standardů specifikujících chování a různá rozhraní systému tak, aby byly programy používané na těchto systémech přenositelné a nevytvářely závislost na výrobci konkrétního operačního systému. Dále existuje celá řada systémů s prostředím UNIX zcela kompatibilních, ale z různých důvodů necertifikovaných, a také systémů kompatibilních z velké části, ale ne úplně. Všechny tyto systémy souhrnně označujeme názvem „unixové operační systémy“, patří sem systému založené na jádru GNU/Linux, systémy rodiny BSD, Mac OS a další.[1] Linux Jsou to všechny systémy používající jako svůj základ linuxové jádro, mezi tyto systémy patří například Debian, Ubuntu, SUSE, Red Hat Enterprise Linux, Gentoo a obrovské množství dalších. Linuxové jádro, na kterém jsou všechny tyto systémy postaveny, vytvořil v roce 1991 Linus Torvalds na univerzitě v Helsinkách jako svobodnou alternativu k v té době používaným unixům. Svoboda v tomto případě znamená (velmi zjednodušeně), že zdrojové kódy Linuxu mohou být libovolně šířeny, používány a upravovány, jedinou podmínkou je, že provedené změny je nutno zveřejnit za stejných licenčních podmínek a samozřejmě uvést autora. BSD Původní BSD (Berkeley Software Distribution) je systém odvozený od unixu, vytvořený na univerzitě v Berkeley a aktivně vyvíjený mezi lety 1977 a 1995. Díky tomu, že licence pro šíření BSD a jeho zdrojových kódů je jednou z nejvolnějších vůbec (klade ještě méně požadavků než GPL licence pod kterou je šířen Linux), vzniklo několik potomků na původní BSD navazujících. Mezi nejznámější přímé následníky patří FreeBSD, NetBSD a OpenBSD. BSD bylo také základem pro operační systém Sun OS firmy Sun a také pro Mac OS používaný v počítačích společnosti Apple.
2.1.2 Microsoft Windows První verze operačního systému Microsoft Windows spatřila světlo světa už v roce 1987 a od té doby vývoj neustále pokračuje. Díky orientaci na ovládání pomocí GUI (Graphical User Interface) a uživatelskou přívětivost se systémy Microsoft Windows postupně staly mezi uživateli vysoce populární a rozšířené. Statistiky se různí, ale uvádí se že některou z verzí operačního systému Windows používá okolo 90 % uživatelů.[2][3] V současné době jsou nejpoužívanější tři hlavní verze: Windows XP „Windows XP byl poprvé uvolněn 25. října 2001 a v současné době se jedná o nejvíce používanou verzi tohoto operačního systému. Od svého uvedení na trh se dočkal tří
9
velkých aktualizačních balíčků, z nichž hlavně Service Pack 2 (zkráceně SP2) systém výrazně pozměnil a přidal některé nové bezpečnostní prvky.“[4] Ač je systém již zastaralý, je stále nutné s ním při vývoji počítat a zajistit kompatibilitu pro starší, ale i nově vytvořené aplikace. I když podíl Windows XP mezi systémy rodiny Windows klesá, ještě několik let bude jeho zastoupení významné. Windows Vista Novější verze Windows, představená v listopadu 2006, oproti starším verzím přináší mnoho změn a vůbec poprvé v systémech od Microsoftu také podporu pro hardwarovou akceleraci zobrazení uživatelského rozhraní pomocí grafické karty. Windows 7 Zatím nejnovější operační systém od Microsoftu. Oproti svému předchůdci (Windows Vista) je Windows 7 výrazně modernizován a cílem je jeho plná kompatibilita s existujícími ovladači zařízení, aplikací a hardwaru.[5] Jestliže nebudeme brát v potaz verze Windows určené pro servery (Windows Server 2008, Windows Server 2003 a další), lze říci, že „program fungující v prostředí Microsoft Windows“ je program, který je funkční alespoň pod výše uvedenými třemi uživatelskými verzemi tohoto systému. Starší verze jako jsou Windows 2000, 98 a další jsou mezi uživateli rozšířené už jen velmi málo (méně než jedno procento), takže již není nutné brát kompatibilitu s těmito zastaralými verzemi na zřetel. Souhrnný název „Microsoft Windows“ („MS Windows“ nebo jen „Windows“) proto v této práci používám pro označení vlastností společných alespoň pro Windows XP, Vista a 7 včetně všech jejich podverzí.
2.2 VIC VIC je videokonferenční nástroj pro komunikaci v reálném čase. Cílem programu VIC je nabídnout uživateli nástroj, který se snadno ovládá, je jednoduchý na použití, a přitom nabízí dostatek funkcionality pro použití v různých podmínkách. Podporovány jsou různé operační systémy: Linux, Windows, FreeBSD a Mac OS. Sám o sobě VIC pracuje pouze s videem, a proto se spolu s ním často používá ještě program na přenos audia RAT. Po technické stránce funguje VIC tak, že snímá obraz z kamery nebo jiného zdroje videa, komprimuje ho zvoleným enkodérem a pomocí protokolu RTP (Real-time Transport Protocol, protokol pro streamování multimediálních dat přes IP síť definovaný v RFC 1889 a RFC 3550) zasílá pakety s komprimovaným videem na zadanou IP adresu. V případě více účastníků využívá VIC rozesílání paketů pomocí multicastu (zasílání dat skupině příjemců).[6] Zdrojové kódy nástroje VIC jsou směsicí souborů napsaných v programovacích jazycích C,C++ a skriptovacím jazyce Tcl rozšířeném o modul Tk, pomocí kterého je vykreslováno GUI programu. Funkce pro kódování a dekódování videa řeší VIC použitím knihoven projektu FFmpeg a jejich volání.
10
2.2.1 Programovací jazyk C Programovací jazyk C byl vyvinut mezi léty 1969 a 1973 v Bellových laboratořích v USA. Tvůrci jazyka jsou Ken Thompson a Dennis Ritchie, kteří jazyk vyvinuli pro potřeby operačního systému Unix, kde nahradil dříve používaný assembler. Oproti assembleru je zdrojový kód v jazyce C daleko přehlednější, čitelnější, je jednodušší ho zapsat a navíc je snáze přenositelný na jiné architektury. Z hlediska zařazení je C strukturovaný procedurální jazyk s nízkoúrovňovým přístupem do paměti pracující s jen minimální abstrakcí. Velice silným nástrojem jazyka, ale také jeho slabinou z pohledu rizika vzniku chyb, je použití ukazatelů (pointerů). Ukazatel je datový typ, který neukládá data, ale obsahuje odkaz na paměťový prostor daného typu proměnné. Používání ukazatelů umožňuje vytvářet efektivnější a rychleji vykonávaný kód.[7]
2.2.2 Programovací jazyk C++ Jazyk C++ je objektově orientovaný (ovšem ne čistě objektový) programovací jazyk vytvořený, stejně jako C, ze kterého vznikl, v Bellových laboratořích. Označení „++“ odpovídá v syntaxi jazyka inkrementaci a jeho přítomnost v názvu znamená, že jde o vyšší vývojový stupeň. Koncepce objektů jazyka C++ byla převzata z jazyka Simula 67. Objekty (třídy) jsou pojaty jako přirozené rozšíření datových struktur jazyka C o možnost vkládání členských funkcí. C++ umožňuje řídit viditelnost složek objektů pro ostatní části programu. Pro objekty je možná vícenásobná dědičnost. [8] Právě dědičnost je kromě ukazatelů dalším velice silným nástrojem jazyka, umožňuje místo vytváření různých variant podobných úseků kódu s různými typy proměnných. Díky dědičnosti lze napsat kód jen jednou pro obecnější typ a poté ho pro všechny typy spadající pro daný obecnější typ. V současnosti patří C++ mezi nejpoužívanější programovací jazyky a je využíván pro tvorbu široké palety různých aplikací počínaje ovladači hardware a součástmi operačních systémů až po běžné uživatelské programy nebo počítačové hry.
2.2.3 Skriptovací jazyk Tcl Tcl (Tool Command Language) je multiplatformní skriptovací jazyk, který je specializovaný na snadnou a rychlou tvorbu prototypových aplikací, návrh grafických uživatelských rozhraní (zde se používá jeho nadstavba resp. knihovna nazvaná Tk) a také pro zabudování do dalších aplikací, které tak získávají možnosti jednoduchého a přitom mocného skriptování. Kromě toho lze velmi snadno volat z programu napsaného v Tcl další aplikace napsané v jiných programovacích jazycích, a tak de facto Tcl rozšiřovat o další funkce a příkazy.[9] Tcl bylo vyvinuto v roce 1988 na univerzitě v Berkeley v USA, v základu vychází z jazyka LISP. Tcl je k dipozici zdarma včetně zdrojových kódů pod BSD licencí, v současné době je dostupné ve verzi 8.5.8 a vývoj stále pokračuje.
11
2.2.4 FFmpeg FFmpeg je open source projekt vytvářející multiplatformní balík nástrojů vhodných pro práci s multimediálními daty. Obsažené nástroje umožňují přehrávání, nahrávání, streamování a různé druhy konverzí digitálního videa a audia. Podporováno je velké množství kodeků, obálkových formátů i transportních protokolů pro streamování, podpora je navíc průběžně rozšiřována o další a další formáty. Na rozdíl od jiných řešení se FFmpeg nesnaží být hotovým řešením pro přehrávání nebo jinou práci s multimédii, jednotlivé součásti jsou sice funkční i samostatně bez nějakého přídavného obslužného programu, ale takovéto využití není typické. Hlavní síla FFmpeg spočívá v tom, že nabízí platformu, na které si každý může vybudovat program na míru přesně podle svých požadavků. Ukázkovým příkladem jsou multimediální přehrávače Mplayer, MPC – Home Cinema, VPlayer a mnoho dalších přehrávačů videa, které staví na funkcích FFmpeg, ale přitom jsou to různá řešení poskytující uživateli každý specifické funkce, jiný vzhled, jiné uživatelské rozhraní. Ve výsledku je toto řešení výhodné pro uživatele, kteří mají daleko větší možnost výběru, i pro vývojáře jednotlivých přehrávačů, kteří nemusejí vymýšlet už vymyšlené a jen vylepšují základ o svoje nápady. Stejná výhoda funguje i u spousty dalších programů nějakým způsobem využívajících funkce FFmpeg, což zdaleka nejsou jen přehrávače, je to široká paleta programů, které nějak potřebují pracovat audiem a videem.
2.3 GColl GColl je videokonferenční prostředí, které si klade za cíl nabídnout lepší možnosti pro spolupráci malých týmů. Na rozdíl od běžně provozovaných nástrojů používá GColl kromě kamery pro každou skupinu ještě dvě kamery pro každého uživatele. Ostatní videokonferenční prostředí přitom pužívají pouze jednu kameru pro každého uživatele, nebo jen jednu kameru pro celou skupinu. Z technického hlediska je GColl nástavbou na videokonferenční nástroj VIC, jehož funkce využívá pro práci s videem. Pro přenos audia používá GColl používá nástroj RAT spouštěný jen v jedné instanci pro každou ze skupin. Zatím je GColl dostupný pro unixové operační systémy a mým úkolem v této práci je portovat jej na platformu Windows
2.3.1 Zprostředkovaný oční kontakt Jedním z prvků neverbální komunikace, se kterým většina videokonferenčních nástrojů nedokáže správně pracovat, je oční kontakt. Při rozhovoru tváří v tvář poznáme z očního kontaktu jestli nás ostatní poslouchají. Pohledem na někoho lze naznačit , že mluvíme na něho, bez nutnosti použít oslovení. Právě tyto zákonitosti se GColl snaží respektovat a umožnit jejich přenesení i do videokonference. Zprostředkování očního kontaktu funguje díky tomu, že každého
12
uživatele snímají dvě kamery. Jedna kamera je umístěná co nejblíž obrazovce, kde uživatel sleduje ostatní, a zaznamenaný obraz vypadá, jako kdyby se uživatel díval přímo do kamery. Tento obraz vyvolá v uživateli, kterému je zobrazen, pocit, že se na něj dotyčný dívá. Naopak druhá kamera snímá obraz ze strany a vytváří dojem, že uživatel příjemce nesleduje, protože se dívá jinam. Z těchto dvou snímaných obrazů se příjemci zobrazuje v danou chvíli vždy jen jeden a jejich přepínání zprostředkovává změny očního kontaktu. [10][11]
2.3.2 Paketové zrcadlo Zajímavým prvkem je také nahrazení multicastu použitím paketového zrcadla. Paketové zrcadlo (UDP Packet Reflector) funguje pro GColl jako server, na který se všichni účastníci videokonference připojí a který se stará, aby byla jednotlivým klientům doručována správná data. Na rozdíl od multicastováho zasílání dat, které funguje na úrovni síťové vrstvy a data nijak nezkoumá, se při používání zrcadla posílají unicastové proudy dat a zrcadlo je podle nastavených parametrů zpracovává. Díky tomu, že zrcadlo rozumí obsahu dat, může s nimi i manipulovat. GColl tuto vlastnost využívá k tomu, že i když od každého uživatele přicházejí dva různé obrazy, k příjemci už putuje jen jeden. Výše zmíněné přepínání obrazu je totiž prováděno právě zrcadlem a díky tomu se dosahuje ještě nižších nároků na šířku pásma než při využití multicastu. Výhodou je také funkčnost tohoto řešení v sítích, kde není multicast dostupný.
13
3 Popis použitých nástrojů Tato kapitola se věnuje programovým nástrojům, které bylo pro vypracování práce nutné použít, nebo které jsem používal, protože mi práci ulehčovaly.
3.1 Virtualbox Virtualbox je multiplatformní virtualizační nástroj, tedy nástroj umožňující běh většiny1 běžně používaných operačních systémů na softwarově simulovaném počítači uvnitř jiného operačního systému. Hostitelským systémem (běžícím na reálném hardware) může být Microsoft Windows (XP a vyšší), Solaris, Open Solaris, Mac OS a většina Linuxových distribucí. Jednotlivé je možné kombinovat, jde používat například Windows uvnitř Linuxu, Linux uvnitř Windows, ale i Windows uvnitř Windows, 32-bit OS uvnitř 64bitových a dokonce i 64-bitové uvnitř 32-bitových. Virtualbox je software s otevřeným kódem distribuovaný zdarma. Na vývoji se v současné době podílí nejvíce společnost Sun, která také nabízí verzi s uzavřeným kódem a několika nadstavbovými funkcemi, která je zdarma pouze pro osobní účely nebo testování, pro komerční využití je tato verze placená. Všechny informace o Virtualboxu, návody i soubory ke stažení se nacházejí na adrese http://www.virtualbox.org/ domovské stránce programu. Vzhledem k tomu, že jsem ve své práci využil hlavně provoz virtualizovaných Windows v rámci jiné verze Windows, mohl jsem použít i různé jiné virtualizační nástroje, kupříkladu Microsoft Virtual PC. Virtualbox jsem si zvolil hlavně ze dvou důvodů z nástrojů, které jsem měl doposud možnost vyzkoušet, je subjektivně nejrychlejší, a také mám s jeho provozem nejvíce zkušeností.
3.2 Visual studio Pro vytvoření nebo úpravu zdrojového kódu programu stačí programátorovi teoreticky libovolný textový editor. Takový způsob vývoje je ale značně neefektivní, a proto se běžně používají sofistikovanější nástroje. Jsou to jednak speciální textové editory určené pro programátory, které umožňují označovat jednotlivé prvky zdrojového kódu různými barvami a usnadňující psaní například kontrolou syntaxe daného jazyka, a dále také celá programovací prostředí, tzv. IDE (Integrated Development Environment). IDE je sadou vzájemně propojených nástrojů, pokrývající celý vývoj aplikace od psaní zdrojových kódů až po vytvoření finálního spustitelného souboru určeného pro distribuci uživatelům. Typickými součástmi je textový editor optimalizovaný pro psaní v konkrétním programovacím jazyce (jazycích), kompilátor a debugger – nástroj pro odhalování a 1 Seznam dostupný na http://www.virtualbox.org/wiki/Guest_OSes
14
lokalizaci chyb v programu. Mezi dostupnými nástroji může být také profiler, který umožňuje měřit dobu běhu (využití procesorového času) jednotlivých částí aplikace, dále nástroj pro tvorbu instalačních balíků pro distribuci programu uživatelům a různé další nástroje. První verzí Visual Studia vydal Microsoft v roce 1997 a od té doby vydává nové verze přinášející nové funkce a podporu dalších jazyků zhruba jednou za dva roky. V současnosti aktuálními verzemi jsou Visual Studio 2008 a zatím pouze v beta verzi dostupné Visual Studio 2010. Jednotlivá vydání se vždy ještě dělí na podverze, například Visual Studio 2008 existuje ve čtyřech variantách (Professional, Premium, Ultimate a Test Profesional) lišících se různými sadami rozšiřujících nástrojů. Mimo tyto verze existují ještě Express edice – zdarma dostupné specializované edice s omezenou sadou funkcí , jsou to: – Visual Basic Express – Visual Web Developer Express – Visual C++ Express – Visual C# Express) Já jsem si ke své práci zvolil Visual Studio 2008, konkrétně verzi Visual C++ Express, a to zejména proto, že VIC nabízí pro kompilaci pod Windows projekt pro Visual Studio, ze kterého jsem vycházel při úpravách GColl. Pokud to není blíže specifikováno, používám v dalších částech této práce v rámci zjednodušení místo názvu Visual C++ Express 2008 souhrnné označení Visual Studio (nebo jen VS), jelikož jsou Express edice funkčními podmnožinami, předpokládám stejnou funkčnost i u vyšších verzí.
3.3 PSPad PSPad je volně šiřitelný textový editor určený hlavně pro psaní a editaci zdrojových kódů v různých programovacích jazycích a vytváření webových stránek. Kromě kromě běžných funkcí, jako jsou různé nástroje pro formátování textu nebo funkce najít a nahradit, umí PSPad porovnat soubory a barevně odlišit rozdíly, zvýrazňovat ve zdrojovém kódu k sobě patřící závorky a další pro programátory užitečné funkce. Velkou výhodou potom je automatické obarvovaní zdrojového kódu (zvýraznění klíčových slov a důležitých prvků jazyka různými barvami) pro velké množství různých programovacích jazyků. Aktuální verzi programu, další informace a různá rozšíření lze nalézt na stránce programu http://www.pspad.com/. Kromě výše zmíněného umí PSPad i spoustu funkcí, které jsou vlastní hlavně velkým programovacím prostředím typu Visual Studio, umí sdružovat soubory do projektů, spouštět externí kompilátory, obsahuje jednoduchého FTP (File Transfer Protocol) klienta a mnoho dalšího. Já jsem však PSPad využíval hlavně jako rychlý editor typu poznámkový blok a také jako editor souborů jazyka TCL. Visual Studio samozřejmě umožňuje v rámci projektu pracovat s těmito soubory také, ale pouze jako s generickým textovým
15
souborem, PSPad mi pomohl tím, že TCL skripty zná a umí jejich kód přehledně obarvovat.
3.4 MinGW MinGW je zkrácený název pro „Minimalist GNU for Windows“, jedná se o port GCC (GNU Comliper Collection) a GNU Binutils pro použití při přímém vývoji aplikací pro MS Windows. Nástroj používá standardní systémové knihovny od Microsoftu, pomocí kterých zpřístupňuje funkce Windows API. MinGW poskytuje kompletní open source sadu programovacích nástrojů vhodných pro vývoj nativních aplikací pro Windows, která je nezávislá na programech nebo knihovnách třetích stran.
3.5 MSYS MSYS (Minimal system) je nástroj nabízející pod Windows zjednodušené prostředí unixové příkazové řádky a některé její nástroje. Typicky se používá společně s MinGW při kompilaci open source programů pod Windows, kdy na rozdíl základní systémové příkazové řádky cmd.exe možňuje například běh autokonfiguračních skriptů často používaných při kompilaci různých programů nebo jejich součástí..
3.6 NASM,YASM NASM (The Netwide Assembler) je multiplatformní kompilátor programovacího jazyka assembler dostupný zdarma (Simplified BSD license). Mimo jiné umí ze zdrojových kódů vytvářet objekty dále použitelné v rámci MS Visual Studia. Domovská stránka nástroje NASM je http://www.nasm.us/. YASM (Yasm, the modular assembler) je multiplatformní kompilátor programovacího jazyka assembler vzniklý replikací funkcí NASM a přidáním dalších. YASM lze stejně jako NASM využít ve spolupráci s Visual Studiem. Domovskou stránku projektu lze nalézt na adrese http://www.tortall.net/projects/yasm/.
3.7 Wireshark Wireshark je nástroj umožňující analýzu síťového provozu na úseku sítě, kde je počítač připojen. Umí přepnout síťovou kartu do takzvaného promiskuitního módu, při kterém počítač vidí veškerou komunikaci na daném síťovém médiu nejen tu adresovanou danému počítači. Zachycené pakety je pak možno podrobně analyzovat. Díky tomu, že umí rozpoznat velké množství různých protokolů, umožňuje Wireshark prozkoumat
16
většinu paketů velmi detailně a prohlédnout si nejen obsah paketu, takzvaný payload, ale také informace jednotlivých protokolů, do kterých byl obsah zabalen, či jim přímo patřil. Už při zachytávání paketů nebo i později je možné volit různé filtry a sledovat například jen komunikaci konkrétní aplikace, komunikaci určitým protokolem nebo komunikaci týkající se určité IP adresy. Wireshark je dostupný zdarma a s otevřeným kódem pod licencí GPL, domovská stránka je na adrese http://www.wireshark.org/. Při mé práci mi Wireshark pomohl hlavně při zjišťování, jestli GColl odesílá data tak jak má a také jestli data z protistrany přicházejí v pořádku. Snadno lze tímto způsobem odhalit například špatně nastavený firewall blokující větší část komunikace, než by měl.
17
4 Postup práce V této kapitole popisuji jednotlivé kroky práce tak, jak jsem je vykonával a postupně řešil problémy, na které jsem narazil. Prvním krokem práce byla úvaha o tom, jak zhruba by mohla práce probíhat a jaké programové vybavení budu potřebovat. Došel jsem k závěru, že by nebylo moudré hned na začátku riskovat, že si prováděnými pokusy nějak naruším hlavní operační systém, a proto jsem se rozhodl, že, dokud to půjde, budu pracovat odděleně v rámci virtuálního počítače. Také jsem měl obavu (jak se později ukázalo zbytečnou), že by 64-bitový operační systém (Windows Vista Business) mohl znamenat komplikace při práci.
4.1 Použití virtuálních počítačů Každý program běžící v rámci nějakého operačního systému nějakým způsobem závisí na prostředí, ve kterém běží, a toto prostředí se skládá z obrovského množství dílčích parametrů. V operačních systémech Microsoft Windows je prostředí ovlivněno zejména verzí samotného operačního systému a dále mimo jiné přítomností či nepřítomností sdílených knihoven a jejich verzemi, aktuálními hodnotami proměnných prostředí a hodnotami klíčů v registru. Různé akce mohou prostředí modifikovat, například instalací programu vzniknou nové klíče v registru a mohou být přidány sdílené knihovny. Čím více instalací, odinstalací a jiných změn je v systému provedeno, tím více se systém stává unikátním a nevhodným pro testování nebo vývoj jakéhokoliv programu, který má fungovat univerzálně. Snadno se nám může stát, že program vytvořený v takovémto prostředí nebude při přenesení na jiný počítač fungovat, protože využívá nějakou součást nebo funkci, která není běžnou součástí operačního systému. Dalším rizikem je možnost zbytečné ztráty času řešením problémů, které jsou specifické pro tuto konkrétní instalaci a vznikly díky předchozím pádům aplikace nebo jinými akcemi, které prostředí nějakým způsobem narušily. Provádět kvůli každému pokusu novou instalaci Windows, programovacího prostředí a dalších potřebných programů z časových důvodů nelze, ale naštěstí je možné stejného efektu docílit stejného efektu i s výrazně nižší časovou ztrátou, a to využitím virtualizace. Virtualizace umožňuje vytvořit si virtuální počítač, kde bude nainstalováno jen to, co je potřeba, a zároveň nemusíme na hostitelském systému dělat žádné změny nebo třeba instalovat aplikace, které plánujeme využít jen jednorázově. Velkou výhodou je potom možnost uložit si v libovolnou chvíli stav počítače, takzvaný obraz (obsah pevného disku a všechna nastavení), a k tomuto stavu se kdykoliv zase vrátit, takže máme při novém pokusu jistotu nenarušeného prostředí. Obrazy lze kopírovat a přenášet mezi různými fyzickými počítači, což umožňuje pracovat v měnících
18
se podmínkách ve stále stejném prostředí a také mít více počítačů, ve výchozím stavu identických, kde v každém z nich rozvíjíme jinou variantu řešení aktuálního problému. Pro svojí práci jsem si vytvořil virtuální počítač, do něj jsem nainstaloval operační systém Windows XP Service Pack 2 a jen nejnutnější sadu programů, o kterých jsem věděl, že je potřebuji k práci. Tento stav počítače jsem si uložil a v případě potřeby se k němu vracel.
4.2 Převod na novou verzi vývojového prostředí Pro svojí práci jsem měl dva hlavní výchozí body: zdrojové kódy GColl zkompilovatelné pod unixovými systémy a zdrojové kódy samostatného programu VIC, který lze zkompilovat a provozovat pod Windows. Prvním krokem samozřejmě byl průzkum možností a naplánování postupu práce. Zjistil jsem, že verze VIC, na které je postavený GColl, je oproti nejnovější verzi z repozitáře UCL Media tools už poměrně zastaralá, v zásadě se proto nabízely dvě základní možnosti řešení. Z hlediska výsledku práce by určitě bylo ideální vzít nejnovější verzi VIC a GColl do ní postupně zapracovat. Nejnovější verze VIC obsahuje aktuální projekt pro Visual Studio 2008 a ve výsledku by vznikl balík, který by jednak obsahoval všechny nové funkce a opravy chyb a navíc by mohl do budoucna snadno držet krok s dalším vývojem VIC, protože by stačilo jen sledovat a reflektovat případné změny. Nevýhodou tohoto řešení je to, že kromě problémů spojených s portováním GColl na Windows je nutné zároveň řešit netriviální množství problémů, které mohou vzniknout při pokusu o převod GColl z konkrétní verze VIC na verzi výrazně novější. Druhou možností je vzít GColl včetně obsažené verze VIC a portovat ho v této podobě. Obsažená starší verze VIC obsahuje projekt Visual Studio 2003, což znamená práci navíc s převodem projektu do VS 2008, nicméně i přesto by mělo být celkové množství nutné práce menší. Nevýhodou této varianty je potom samozřejmě to, že práci mohou komplikovat v nové verzi již vyřešené chyby a hlavně, že výsledný GColl balík se bude stéle držet čím dál více zastarávající verze. Nakonec jsem se rozhodl zkusit paralelně obě varianty s tím, že pokud nebudou s převodem na novou verzi větší problémy, bude to lepší řešení, a naopak vyskytnou-li se na řešení časově náročné problémy, přestanu tuto variantu dál rozvíjet. Brzy jsem zjistil, že při použití nové verze vzniká nesrovnalostí mnoho, a proto jsem tuto variantu řešení po nedlouhé době opustil s tím, že je vzhledem k mým možnostem pravděpodobně příliš ambiciózní a časově náročná. Při použití původního balíku byl prvním nutným krokem převod projektu Visual Studia na verzi 2008, který naštěstí proběhl bez problémů, jen s několika málo upozorněními na problémy, které by se mohly díky převodu vyskytnout.
19
4.3 Postup kompilace a řešení problémů Zdrojové kódy VIC jsou pro všechny platformy společné, respektive jsou společně v jednom balíku. Některé soubory jsou pro různé platformy různé a o použití či nepoužití rozhoduje konfigurační skript pro danou platformu nebo v případě Windows zařazení nebo nezařazení souboru do projektu pro Visual Studio. Ostatní zdrojové kódy jsou společné pro všechny platformy a části zdrojového kódu specifické pro konkrétní platformy jsou řešeny pomocí maker preprocesoru, který určí, jestli se kód použije nebo ne. Například zdrojový kód mezi řádky #ifdef WIN32 #endif předá preprocesor kompilátoru pouze v případě, že je definovaná konstanta WIN32 (typicky při kompilaci pro Windows), naopak kód mezi řádky #ifndef WIN32 #endif bude použit všude jinde jen na Windows ne. GColl je implementován z části přidáním dalších zdrojových souborů a z části modifikováním a rozšířením souborů VIC, rozhodl jsem se proto zkusit rovnou začít projekt kompilovat. Součásti GCollu přidané do VIC budou potřebovat ke kompilaci další soubory a podle toho půjde vyhledat soubory, které je potřeba do projektu přidat. První problémy, na které jsem narazil, byly chybějící soubory. Ve většině případů, kdy kompilace hlásila chybějící soubor, soubor většinou nechyběl, ale preprocesor nevěděl, kde se nalézá. Mnoho chyb tohoto typu jsem snadno vyřešil opravou cest k souborům a přidáním některých složek mezi složky, kde se mají vkládané soubory hledat. V několika případech bylo potřeba místo chybějícího zastaralého hlavičkového souboru vložit jiný, který potřebné funkce definuje, nebo v případě některých funkcí nahradit funkci nějakou jinou, která dělá totéž a funguje pod Windows. Prvním problémem, který nešel vyřešit úpravou nastavení projektu nebo úpravou zdrojového kódu, byl chybějící soubor atlbase.h a několik dalších, které se vůbec nevyskytovaly nikde v počítači. Po krátkém hledání jsem zjistil, že tyto soubory jsou součástí Microsoft ATL.
4.3.1 Microsoft Active Template Library (ATL) Microsoft Active Template Library je balík podpůrných souborů pro vytváření programů v jazyce C++ na platformě Windows. Obsahuje různé šablony, předdefinované třídy a další komponenty jejich používání by mělo přispět k tomu, že výsledná aplikace bude rychlejší a méně paměťově náročná.[12] ATL je standardní součástí instalace plné verze Visual Studia, ovšem ve verzi Visual C+ + Express obsažena není. Naštěstí není nutné kvůli této součásti instalovat plné Visual Studio, ATL je možno do systému doplnit pomocí instalace Windows Server 2003 R2 Platform SDK. Následně je ještě nutné nastavit ve Visual Studiu, aby hledalo soubory
20
i v odpovídajících adresářích Platform SDK, nebo alternativně jednoduše chybějící soubory zkopírovat do adresářů Visual Studia. Ve výsledku je toto řešení složitější, než použití plného Visual Studia, ale použité nástroje jsou k dispozici zdarma. To považuji za důležité bez ohledu na fakt, že jako student mám díky členství fakulty v MSDN Academic Alliance zdarma přístup i k plné verzi Visual Studia.
4.3.2 Microsoft DirectX SDK Další součástí, kterou jsem kvůli chybějícím souborům potřeboval byl Microsoft DirectX SDK. DirectX je sada programových rozhraní (API) sloužících ve Windows pro multimediální operace s využitím hardwarové akcelerace, nejčastěji vykreslování 2D a 3D obrazu, přehrávání videa, práce s audiem. DirectX Software Development Kit je balík knihoven, hlavičkových souborů, dokumentace a dalších věcí potřebných pro vývoj aplikací, které chtějí DirectX využívat. Jistá komplikace spočívá v tom, že soubor qedit.h, vyžadovaný při kompilaci, si vynucuje přítomnost souboru dxtrans.h, který se v nových verzích DirectX SDK již nenachází. Poslední verzí, kde je tento soubor ještě přítomen, je DirectX SDK August 2007, kterou jsem při své práci používal (respektive potřebné soubory z tohoto balíku zkopírované). Existuje i několik alternativních řešení[13] tohoto problému dovolujících použít novější verze DirectX SDK. Kromě zásahu do souboru qedit.h, což považuji za špatné řešení, lze přidat ke svému programu vlastní „falešný“ soubor dxtrans.h, jehož obsahem budou řádky: #define __IDxtCompositor_INTERFACE_DEFINED__ #define __IDxtAlphaSetter_INTERFACE_DEFINED__ #define __IDxtJpeg_INTERFACE_DEFINED__ #define __IDxtKey_INTERFACE_DEFINED__ Další možnost řešení je potom podobná předchozí variantě, ale nevytváří soubor navíc, přímo do souboru, kde se vkládá qedit.h, se před řádek s textem #include
vloží řádky: #pragma include_alias( "dxtrans.h", "qedit.h" ) #define __IDxtCompositor_INTERFACE_DEFINED__ #define __IDxtAlphaSetter_INTERFACE_DEFINED__ #define __IDxtJpeg_INTERFACE_DEFINED__ #define __IDxtKey_INTERFACE_DEFINED__
4.3.3 Assembler Součástí projektu je i zdrojový soubor cpuid_win.asm - soubor kódu nízkoúrovňového programovacího jazyka assembler. Tento soubor bohužel není kompatibilní s assembler kompilátorem obsaženým ve Visual Studiu a je proto nutné zacházet s ním speciálním způsobem. Soubor používá syntaxi assembleru NASM a proto je nutné aby byl v počítači přítomen kompilátor NASM nebo kompilátor YASM, který syntaxi NASM také zvládá.
21
Vyzkoušel jsem obě varianty (starší verze VIC předpokládá NASM, novější YASM) a nakonec jsem projekt ponechal po vzoru novější verze přednastavený pro použití YASM, který si Visual Studio díky tomu při kompilaci již samo najde. V případě použití YASM stačí stáhnout balík: http://www.tortall.net/projects/yasm/releases/vsyasm-1.0.0-win32.zip a soubor vsyasm.exe překopírovat pod názvem yasm.exe do složky VC/bin/ v adrésáři s instalací Visual Studia. V případě použití NASM je potřeba stáhnout a nainstalovat balík ze stránek http://www.nasm.us/ a ve vic.vcproj upravit volbu "Custom Build Step" u souboru cpuid_win.asm tak, aby se při kompilaci volal NASM. Položka "Command line" potom bude vypadat například následovně: "%PROGRAMFILES%\NASM\nasm" -f win32 -o cpuid_win.obj $(inputpath)
4.4 Knihovní funkce a linkování Po analýze preprocesorem a zkompilování jednotlivých zdrojových souborů je dalším krokem linkování. Funkcí linkeru je prozkoumat objekty vzniklé zkompilováním jednotlivých zdrojových souborů, pro každý objekt dohledat vše, na co se daný objekt odkazuje, ale sám to nedefinuje, a nakonec z objektů sestavit výsledný spustitelný program. Jednotlivé objekty se mohou odkazovat na jiné objekty, ale i na knihovny objektů. Knihovna je vlastně soubor, který definuje určitou množinu funkcí, a tyto funkce nabízí programům pro používání. Knihovny dělíme na statické a dynamické, statické knihovny jsou při sestavování programu k programu pevně připojeny, naopak u dynamických knihoven je do aplikace pouze zabudována tabulka odkazů na knihovnu a linkování provádí až aplikace při svém spuštění. Většina problémů, které jsem pro úspěšné slinkování programu musel vyřešit, měla společný jmenovatel v podobě hlášení „Error LNK2019: unresolved external symbol ...“ oznamujícího, že linker daný symbol nenalezl. Takové symboly jsem poté musel dohledat ručně a zařadit do projektu knihovnu, která je obsahuje. V této fázi jsem také odhalil několik zdrojových souborů patřících GCollu, které bylo nutné do projektu zařadit, aby jejich zkompilováním vznikly chybějící symboly. Při řešení těchto problémů jsem často využil nástroj DUMPBIN, jenž je dostupný z příkazové řádky Visual Studia a po spuštění ve tvaru dumpbin /linkermember [jméno_knihovny] vypíše seznam všech symbolů definovaných v zadané knihovně.[14] Po vyřešení problémů linkeru nastal čas na pokus o první spuštění vytvořené aplikace. Narazil jsem však na problém s knihovnami FFmpeg, které VIC a tudíž i GColl používá pro manipulaci s videem. Konkrétně jsou to knihovny avcodec, avutil, postproc a knihovna x264, která není součástí FFmpeg balíku, ale jejíž použití s tímto balíkem umožňuje kódování videa do formátu h264. Program se s verzí knihoven obsaženou v balíku odmítal spustit a proto jsem se rozhodl uvedené knihovny nahradit jinou verzí.
22
Nejjednodušší by bylo použít již hotové zkompilované knihovny, které lze nalézt ke stažení například na adrese http://ffmpeg.arrozcru.org/autobuilds/. Bohužel zřejmě kvůli odlišným parametrům kompilace se mi nepodařilo najít žádnou funkční kombinaci a tudíž jsem si musel zmíněné knihovny zkompilovat sám, což se ukázalo být poměrně náročnou a zdlouhavou činností.
4.4.1 Kompilace knihoven FFmpeg Způsobů, jak zkompilovat FFmpeg pro Windows, existuje několik: – Přímá kompilace pomocí MSYS a MinGW Na tento způsob existuje nejvíce návodů, bohužel většinou zastaralých a nefunkčních. Největším problémem je, že k úspěšnému zkompilování je potřeba doinstalovat mnoho balíčků a nástrojů, které fungují pouze v určité verzi a musí být navzájem kompatibilní. Tento způsob jsem vyzkoušel jako první, ale neúspěšně. – Kompilace v Linuxu pro prostředí Windows Vyzkoušel jsem na Ubuntu 10.04, ale bohužel neúspěšně, podařilo se mi pouze zjistit, že problémy souvisí s verzí kompilátoru gcc obsaženého v této verzi Ubuntu. – Kompilace v prostředí Cygwin pod Windows – Kompilace v prostředí Cygwin pod Linuxem Věřím, že oba problémy, na které jsem narazil, bych byl chopen vyřešit, ale zároveň jsem předpokládal, že určitě existuje jednodušší cesta. Podařilo se mi najít návod využívající kompilaci MSYS a MinGW, jehož autor velice elegantně vyřešil problémy s verzemi nástrojů v rámci MinGW. Mplayer – multiplatformní open-source přehrávač videa založený na FFmpeg nabízí na stránkách předem připravenou sadu pro kompilaci, kterou lze snadno použít i pro kompilaci FFmpeg samostatně. Jedinou úpravou, kterou je nutno provést, je aktualizace gcc rozbalením balíku „GCC full 4.4.0“ do složky c:\mingw (podle zvoleného umístění kompilační sady). Funkční postup vedoucí k úspěšnému vytvoření potřebných knihoven pod Windows je tedy následující: [15] 1) Stáhnout balík „MinGW Build Environment with gcc 4.2.5“ ze stránky http://oss.netfarm.it/mplayer-win32.php a rozbalit ho do kořenové složky c:\, čímž bude vytvořena složka c:\MinGW. 2) Stáhnout balík gcc-full-4.4.0-mingw32-bin-2.tar.lzma ze stránky http://sourceforge.net/projects/mingw/files/ a jeho obsahem zkopírovat do c:\MinGW, již existující soubory přepsat. 3) Spustit c:\MinGW\msys.bat a vytvořit si složky x264 a ffmpeg (složky se budou nacházet v c:\MinGW\home\jmeno_uzivatele\).
23
4) Do těchto složek uložit zdrojové kódy, které lze získat pomocí nástrojů Git2 a Subversion3 pomocí příkazů git clone git://git.videolan.org/x264.git a svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg nebo git clone git://git.ffmpeg.org/ffmpeg/ 5) Ve složce s instalací Microsoft Visual Studia vyhledat soubor lib.exe (pro verzi Express 2008 je při výchozím nastavení ve složce c:\Program Files\Microsoft Visual Sudio 9.0\VC\bin\) a zkopírovat ho do složky c:\MinGW\bin 6) V MSYS příkazové řádce ve složce ~/x264/ postupně spustit příkazy ./configure make make install 7) Pokud se nevyskytly chyby, přepnout se do složky ~/ffmpeg/ a postupně spustit příkazy ./configure --enable-libx264 -–enable-gpl --enable-memalign-hack -–disable-static -–enable-shared --extracflags='-I/usr/local/include' --extra-ldflags='-L/usr/local/lib' make make install 8) Pokud šlo všechno jak má, hotové knihovny najdeme ve složce c:\MinGW\local\bin
2 http://cs.wikipedia.org/wiki/Git 3 http://cs.wikipedia.org/wiki/Subversion
24
5 Testování S nově zkompilovanými knihovnami už se program spustil, takže jsem mohl postoupit do fáze testování a hledání problémů v už alespoň částečně fungujícím programu. GColl se normálně spouští pomocí skriptu run.tcl, jehož funkcí je zobrazení okna s dotazem na nastavení. Získané údaje potom předá jako jako parametry souboru vic.exe, který spustí. Debugger ve Visual Studiu bohužel Tcl nezná a je nutno při jeho použití spouštěcí skript obcházet. Naštěstí to nebyl problém, nutné parametry jsem snadno odvodil a nastavil do debuggeru pro přímé použití při spuštění programu. Některé problémy se objevily okamžitě, například pád programu při pokusu o vstup do menu, pro odhalení dalších už bylo potřeba zapojit kamery a testovat s nimi. Bohužel v tuto chvíli jsem byl nucen opustit Virtualbox a přenést práci z virtuálních počítačů do nativních systémů, jednak nevím jestli by virtualizovaný systém správně správně rozpoznal připojené kamery a hlavně zatím nelze ve virtualizovaném prostředí spolehlivě používat funkce hardwarově akcelerovaného DirectX, které GColl pod Windows potřebuje.
5.1 Popis hardware použitého při testech Pro testování a další vývoj práce jsem využíval notebook a stolní počítač (později ještě druhý stolní počítač) a čtyři webkamery. Parametry počítačů byly následující: Notebook Acer Travelmate 5520 (procesor AMD Turion X2 1.9 GHz, 3 GB RAM, grafická karta ATI Radeon HD 2400 XT, operační systém Windows Vista Business EN 64bit Service pack 1). PC1 Procesor AMD Phenom II X4 2,7 Ghz, 4 GB RAM, grafická karta Radeon ATI Radeon HD 4200, operační systém Windows 7 Professional EN 64bit. PC2 Procesor AMD Athlon XP 2200+, 768 MB RAM, gafická karta ATI Rage 128 Pro, operační systém Windows XP CS 32-bit Service Pack 2. Použití výhradně procesorů AMD a grafických karet ATI nebylo cílem, ale pouhou shodou okolností. Věřím že při použití hardware od jiných výrobců by se nic nezměnilo. Co se týče použitých kamer, jednalo se konkrétně o „Acer Crystal Eye webcam“ integrovanou ve víku notebooku a tři kamery připojitelné přes USB (Universal serial Bus) - „Genius Eye110“ a dva kusy „Logitech QuickCam Pro 9000“, které jsem měl zapůjčené z fakulty.
25
5.2 Nastavení a testování síťové komunikace Jakmile jsem se dopracoval do stavu, kdy program běžel a dokázal zobrazovat video z lokálních kamer, bylo dalším krokem testování a zprovozňování komunikace po síti. V první fázi, kdy jsem testoval spojení z notebooku na pc v rámci lokální sítě, nebylo potřeba žádné speciální nastavení. Windows Firewall běžící na obou počítačích bez problému rozeznal pokus programu o komunikaci a po potvrzení povolení již žádnou část komunikace neblokoval. Jediný možný problém s nastavením síťové komunikace je nastavení protokolu ICMP, kdy jsem pozoroval, že na počítači komunikujícím s jiným, který nezasílá odpovědi na ICMP Echo Request, dochází častěji k haváriím programu. Vzhledem k tomu, že v dalších etapách testování se problém již neobjevil, předpokládám, že jsem buď problém odstranil jako součást řešení jiných problémů nebo se jednalo o náhodný jev. Raději však toto pozorování zmiňuji, pro případ, že se problém projevuje jen v nějaké specifické situaci a v programu zůstal nevyřešen. Posledním krokem bylo zprovoznění plné funkcionality, tedy komunikace s paketovým zrcadlem. Zde jsem narazil na problém s NAT (Nework Address Translation), GColl totiž pro svoji funkci potřebuje veřejnou IP adresu pro každý připojený počítač. Nejprve jsem zkusil připojit alespoň jeden počítač pomocí přesměrování portů z veřejné IP. Toto řešení na první pohled fungovalo, později se však ukázalo, že ne úplně, a hlavně já jsem potřeboval otestovat připojení alespoň dvou počítačů najednou. Nakonec se nečekaně jako dobrý nápad ukázalo řešení pomocí univerzitní VPN (Virtual Private Network). Zjistil jsem totiž, že VPN připojení do sítě MUNI umožňuje s jedním loginem více paralelních připojení, kdy každé připojení dostane vlastní adresu. Veškerá komunikace chodí správně jak tunelem k zrcadlu a zpět, tak i mezi počítači z jednoho VPN tunelu do druhého. Další testy jsem proto prováděl za použití této konfigurace.
5.3 Postup a výsledky testování Jedním z problémů při testování programu bývá obrovský počet různých situací, které při jeho použití mohou nastat. Pokud program nemá přesně definované pořadí kroků a dává uživateli volnost například v tom, v jakém pořadí vybere jednotlivé volby, které jsou mu k dispozici, měly by být otestovány všechny možnosti. V případě že není možné otestovat všechny situace, mělo by testování postupovat od akcí, jejichž výskyt předpokládáme nejčastěji, a které tvoří základní funkcionalitu programu. Naopak funkce, které nejsou pro správný běh programu nezbytně nutné případně nepředpokládáme jejich časté využití, přijdou na řadu nakonec. Portovanou verzi programu jsem úspěšně otestoval pod operačními systémy Windows Vista a Windows 7. Oba tyto systémy jsou v 64-bitové variantě, ale mnou vytvořená binární verze GColl je 32-bitová a tudíž předpokládám naprosto stejné chování i na 32bitových verzích těchto systémů. Program pod těmito OS bez problémů přijímá, posílá a zobrazuje jednotlivé proudy videa včetně správné práce s okny a jejich přepínáním. Fungují statistiky datových přenosů a je možné měnit datový tok a snímkovou frekvenci
26
odesílaného videa. Z formátů pro kódování odesílaného videa lze použít h261 a h263+ s tím, že h261 funguje výborně a h263+ funguje ve smyslu úspěšného přenosu videa, ale neúměrně zatěžuje procesor odesílajícího pc a dosahuje kvůli tomu jen nízkých snímkových frekvencí. Abych otestoval co nejvíce stavů, přidal jsem do testování kromě notebooku a pc ještě druhé pc, kam jsem nainstaloval Windows XP (Service pack 2). Vzhledem k tomu, že většina práce probíhala právě na této verzi systému (i když virtualizovaně) a měl jsem již ověřeno, že program jde spustit, nepředpokládal jsem žádné problémy. Bohužel problém se objevil ve formě nefunkčního automatického zobrazení a přepínání oken s videem, jinak program běží a přijímá i odesílá video.
27
6 Výsledky práce V této kapitole se zabývám shrnutím provedené práce a hlavně popisem výsledků mé činnosti.
6.1 Dosažené výsledky Podařilo se mi vytvořit port klienta videokonferenčního prostředí GColl na platformu Microsoft Windows fungující na dvou nejnovějších verzích tohoto systému (Windows Vista a Windows 7). Všechny provedené kroky procesu portování jsem popsal v jednotlivých kapitolách této práce. Klienta jsem vytvořil ve dvou binárních verzích a součástí práce je samozřejmě i balík upravených zdrojových kódů, ze kterého je možné program, ve verzi pro Windows, zkompilovat. K práci přikládám také stručný návod, jak co nejjednodušeji provést kompilaci vlastní verze klienta.
6.2 Popis odevzdaných balíků Součástí této práce je přiložené cd, na kterém jsou uloženy následující soubory a složky: \Gcoll_bin\ Tato složka obsahuje binární formu GColl klienta pro Windows. Klienta je možno spustit pomocí skriptu run.tcl, ale pouze v případě, že v počítači nainstalován interpret jazyka Tcl ve verzi 8.5 nebo její podverzi. \Gcoll_bin_integratedTcl\ Tato složka obsahuje binární formu GColl klienta pro Windows spolu se soubory jazyka Tcl. K běhu této verze není potřeba instalace žádných doplňujících komponent. Klient se v tomto případě spouští pomocí dávkového souboru souboru start_GColl.cmd v podsložce \Gcoll\, který nastaví cestu k interpretu jazyka Tcl a spustí program. \Gcoll_src\ Tato složka obsahuje zdrojové soubory a jiné soubory nutné pro zkompilování GColl klienta pro Windows. \ActiveTcl8.5.8.2.292682-win32-ix86-threaded.exe Instalační balík jazyka Tcl pro použití s verzí klienta bez integrovaného Tcl. \PetrNemecek_text_prace.odt
28
Soubor obsahující text této práce ve formátu ODT. \PetrNemecek_text_prace.pdf Soubor obsahující text této práce ve formátu PDF.
29
7 Závěr Videokonference jsou stále častější metodou vedení různých jednání a týmové spolupráce a to zejména díky tomu, že umožňují šetřit čas všech zúčastněný, kteří nemusejí trávit dlouhé hodiny na cestách, ale také peníze, které by to cestování stálo. Bohužel videokonference mají i svoje nevýhody v podobě v podobě neosobnosti, zpoždění přenosu znemožňující proti straně rychle reagovat, ale také ztráty spousty nonverbálních prvků komunikace. Myšlenkou programu GColl je umožnit účastníkům videokonference zprostředkovaný oční kontakt, a tím posunout videokonferenci o kousek blíž k vlastnostem komunikace tváří v tvář. Úkolem mé práce bylo vytvořit GColl klienta pro operační systémy Microsoft Windows a umožnit používání programu daleko většímu množství uživatelů. Tento úkol jsem splnil a jsem rád, že moje práce je součástí vývoje něčeho, co je opravdu užitečné a může lidem ulehčit život. Jsem si vědom i jistých nedostatků ve své práci, zejména v podobě jen částečné funkčnosti pod Windows XP, což se mi, jak doufám, ještě podaří napravit. Jako další krok ve vývoji Windows verze se potom nabízí rozšíření funkcionality o další videoformáty, zejména h264.
30
Literatura [1] Deborah S. Ray, Eric J. Ray: Unix -- podrobný průvodce. Grada 2009. ISBN: 80-2472125-2. [2] OS Platform Statistics [online]. 2010 [citováno 16. 05. 2010]. Dostupné z WWW: [3] StatCounter Global Stats: Top 5 Operating Systems on OCT 09 [online]. 2009 [citováno 16. 05. 2010]. Dostupné z WWW: [4] Jan Bednařík, Petr Broža , Jiří Hlavenka: Microsoft Windows XP. Computer Press 2004. ISBN: 80-89190-07-3. [5] Windows Team Blog: Windows 7 Unveiled Today at PDC 2008. Windows Team Blog, 28. října 2008. Dostupný z WWW: [6] McCanne, S., and Jacobson, V., vic: A Flexible Framework Framework for Packet Video, ACM Multimedia '95. [7] Brian W. Kernighan, Dennis M. Ritchie: Programovací jazyk C. Computer Press 2006. ISBN: 80-251-0897-X [8] Virius Miroslav: Jazyky C a C++. 2005. ISBN:80-247-1494-9. [9] Pavel Tišnovský: Programovací jazyk TCL [online]. 2005 [citováno 16. 05. 2010]. Dostupný z WWW: [10] Slovák, Petr - Troubil, Pavel - Holub, Petr. GColl: A Flexible Videoconferencing Environment for Group-to-Group Interaction – INTERACT 2009. 2009. vyd. : Springer Berlin / Heidelberg, 2009. od s. 165-168, 4 s. ISBN 978-3-642-03657-6. [11] Slovák, Petr - Troubil, Pavel - Holub, Petr. GColl Group-to-group Videoconferencing System: Design and First Experiences. In The 5th International ICST Conference on Collaborative Computing: Networking, Applications and Worksharing. 2009. 9 s. Accepted for publication. ISBN 978-963-9799-76-9.
31
[12] Microsoft Corporation: ATL Reference [online]. 2010 [citováno 16. 05. 2010]. Dostupný z WWW: [13] Microsoft Corporation: MSDN Forums: dxtrans.h missing in Microsoft DirectX SDK (November 2007) [online]. 2008 [citováno 16. 05. 2010]. Dostupný z WWW:
[citováno
[15] FFmpeg Windows Help Forum: Building FFMPEG on Windows the *easy way* [online]. 2009 [citováno 16. 05. 2010]. Dostupný z WWW:
32
Příloha
Návod na kompilaci vlastní verze programu 1) Nainstalovat Visual Studio Express 2008 nebo nějakou vyšší verzi Visual Studia (a vynechat krok 2) 2) Nainstalovat Windows Server 2003 R2 Platform SDK 3) Nainstalovat DirectX SDK August 2007 4) Nainstalovat YASM 5) Nainstalovat Active Tcl 8.5 6) Otevřít projekt vic.vcproj nacházející se ve složce \Gcoll_src\vicrat\ 7) Ručně spustit kompilaci souboru cpuid_win.asm 8) Spustit kompilaci celého projektu 9) Zkopírovat .dll knihovny ze složky \Gcoll_src\vicrat\win32\lib\ do složky \Gcoll_src\vicrat\ (nebo jiné vzniklé v závislosti na typu kompilace) 10) Pokud byl zvolen typ kompilace „Debug“, mělo by nyní spustit program pomocí souboru \Gcoll_src\vicrat\run.tcl
33
