eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Diplomová práce
Vícekanálový skriptovací video-editor Bc. Radim oustal
Vedoucí práce:
Ing. Roman Berka, Ph.D.
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský
Obor: Výpo£etní technika
20. kv¥tna 2009
iv
v
Pod¥kování Rád bych pod¥koval v²em, kte°í mne v této práci podporovali. D¥kuji svému ²vagru Vladimíru Floriánovi za korekci práce a d¥kuji panu Ing. Romanu Berkovi Ph.D., svému vedoucímu diplomové práce za podporu.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 22. 4. 2009
.............................................................
viii
Abstract This paper deal with principle of storing and processing multichannel audiovisual data by the help of using batch scripts. New language was created to describe modi cations and operations made over input data. The MPEG-4 standart is used for data storing and compression. The solution of this problem was implemented in two programs. First program is able to modify videorecordings according used script and the second program allows users to easily create and modify these scripts.
Abstrakt Práce pojednává o principu ukládání a zpracování vícekanálových audiovizuálních dat pomocí dávkových skript·. Pro ukládání dat je vyuºito standardu MPEG4. K tomuto ú£elu byl vytvo°en jazyk pro popis úprav a operací nad vstupními daty. Implementaci tvo°í dva programy. Program pro úpravu videozáznam· podle p°edloºeného skriptu a gra cký program umoº¬ující jednoduchou tvorbu a úpravu t¥chto skript·.
ix
x
Obsah 1 Úvod 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 2
2 Popis problému, speci kace cíle 2.1 Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Sou£asný stav problematiky . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 3
3 Analýza a návrh °e²ení 3.1 Analýza ukládání ve formátu MPEG-4 3.1.1 Model systémového dekodéru . 3.1.2 MPEG4 kontejner . . . . . . . 3.2 Analýza problému . . . . . . . . . . . 3.3 Analýza jazyka . . . . . . . . . . . . . 3.3.1 De nice datových typ· . . . . . 3.3.2 De nice vstup· a výstup· . . . 3.3.3 De nice funk£ní £ásti . . . . . . 3.4 Návrh implementace . . . . . . . . . . 3.4.1 Obecný návrh implementace . . 3.4.2 Modularita . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
5 5 5 6 7 10 10 10 11 12 12 13
4 Realizace 4.1 Funkce a struktury jádra . . . . . . 4.1.1 Programová analýza jazyka 4.1.2 Vnit°ní struktura . . . . . . 4.1.3 Zpracování . . . . . . . . . 4.2 Funkce a struktury modul· . . . . 4.2.1 Zobrazování . . . . . . . . . 4.2.2 Dekódování a kódování . . . 4.2.3 Funk£ní moduly . . . . . . 4.3 Gra cké rozhraní . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
15 15 15 16 16 17 17 17 18 19
5 Testování 5.1 Testování implementace 5.1.1 Test 1 . . . . . . 5.1.2 Test 2 . . . . . . 5.2 Diskuse . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
21 21 21 23 23
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . xi
xii
OBSAH
6 Záv¥r
25
Literatura
27
A Seznam pouºitých zkratek
29
B P°íprava a instalace B.1 Hardwarové a softwarové poºadavky B.2 P°íprava instalace . . . . . . . . . . . B.2.1 Kompilace knihoven FFmpeg B.2.2 Kompilace program· . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
31 31 31 32 32
C Uºivatelská p°íru£ka C.1 Uºivatelská p°íru£ka konzolového programu . . . . C.2 Uºivatelská p°íru£ka základních modul· . . . . . . C.2.1 AV . . . . . . . . . . . . . . . . . . . . . . . C.2.2 Group . . . . . . . . . . . . . . . . . . . . . C.2.3 Rotate . . . . . . . . . . . . . . . . . . . . . C.2.4 Translate . . . . . . . . . . . . . . . . . . . C.2.5 Scale . . . . . . . . . . . . . . . . . . . . . . C.2.6 Grayscale . . . . . . . . . . . . . . . . . . . C.2.7 Fade . . . . . . . . . . . . . . . . . . . . . . C.2.8 Speed . . . . . . . . . . . . . . . . . . . . . C.2.9 Reverse . . . . . . . . . . . . . . . . . . . . C.2.10 Screen . . . . . . . . . . . . . . . . . . . . . C.2.11 MPEG4 . . . . . . . . . . . . . . . . . . . . C.3 Uºivatelská p°íru£ka gra ckého rozhraní programu
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
35 35 35 35 35 36 36 36 36 36 36 36 37 37 38
D Popis API pro vytvá°ení D.1 Základní popis t°íd . . D.2 Vytvá°ení modul· . . . D.3 Funk£ní modul . . . . D.4 Kompilace modul· . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
43 43 44 45 45
modul· . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
E UML diagramy
47
F Testovací script 1
51
G Obsah p°iloºeného CD
53
Seznam obrázk· 3.1 3.2 3.3 3.4 3.5 3.6
Dekódovací schéma MPEG4 . . . . . . . . . . . . . . . . . . . . . . . . Gra cké znázorn¥ní struktury pro jeden kanál . . . . . . . . . . . . . . Ukázka návrhu funk£ního modulu s prolnutím svých dvou potomk· . . Gra cké znázorn¥ní struktury pro více kanál· . . . . . . . . . . . . . . Upravené gra cké znázorn¥ní struktury pro více kanál· . . . . . . . . . Znázorn¥ní funkce klí£ových £as· a interpolace hodnoty u funkce fade
. . . . . .
. 6 . 7 . 8 . 8 . 9 . 14
4.1 Obecná struktura ko°enového uzlu . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Zp·sob zpracování stromu scéná°e . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Ukázka implementace gra ckého rozhraní . . . . . . . . . . . . . . . . . . 19 5.1 Znázorn¥ní testovacího skriptu v programu gra ckého rozhraní . . . . . . 22 C.1 Základní rozloºení gra ckého rozhraní . . . . . . . . . . . . . . . . . . . . 38 C.2 Moºný obsah funk£ního menu . . . . . . . . . . . . . . . . . . . . . . . . . 40 E.1 E.2 E.3 E.4
Hierarchie uzl· a jejich závislosti . . . . . . . . . . . . . . . . Struktura syntaktického, lexikálního analyzátoru a jejich typ· UML diagram struktur pro funk£ní modul operace posunutí . UML vstupního a výstupního modulu . . . . . . . . . . . . .
xiii
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
47 48 48 49
xiv
SEZNAM OBRÁZK
Kapitola 1
Úvod 1.1 Úvod Práce se zabývá principem ukládání a úpravou vícekanálového audio-video záznamu komprimovaného moderním standartem MPEG-4. Dále se práce zabývá návrhem jazyka, který de nuje zp·sob zpracování a prezentace dat v r·zných kanálech. Práce také pojednává o návrhu gra ckého rozhraní pro p°ehlednou vizuální prezentaci zpracovávaných dat a operací, které nad t¥mito daty bude moºné provád¥t.
1.2 Motivace Práce pojednává o zp·sobu uloºení a zpracování více obrazových a zvukových kanál·, neº se obvykle pouºívá u tohoto druhu záznam·. Obvykle se pouºívá jen jedna video stopa a jedna £i více audio stop ( nap°. pro r·zné jazykové p°eklady). Pro n¥které ú£ely je základním poºadavkem synchronní p°ehrávání dvou nebo více obrazových stop zárove¬. Toto se pouºívá nap°íklad ve stereoskopii, kde je pot°eba mít pro kaºdé oko jeden obrazový signál. Roz²í°ení stereoskopického vjemu m·ºe být je²t¥ umocn¥no pouºitím technologie CAVE, u které je pot°eba prezentovat t°í nebo více stereoskopických obraz· zárove¬. V °ad¥ p°ípad· je po vytvo°ení nového audiovizuálního záznamu nutné tento záznam dále zpracovat. Pro b¥ºný záznam obsahující jednu zvukovou a obrazovou stopu existuje mnoho voln¥ dostupných nástroj·, kterými je moºné tuto sekvenci libovoln¥ upravovat. P°i úprav¥ záznamu s více obrazovými a zvukovými stopami (nap°. natá£ení stejné scény n¥kolika r·zn¥ umíst¥nými kamerami), nám tyto nástroje jiº neposkytují v²echen moºný komfort, p°ípadn¥ ani funkcionalitu nutnou na úpravu tohoto záznamu. Problém by bylo moºné °e²it vytvo°ením skriptu pro samostatné zpracovávání jednotlivých stop, ale tento postup nemusí zaru£it správnou synchronizaci jednotlivých stop p°i jejich následném p°ehrávání. Tento problém je moºné °e²it vytvo°ením jazyka pro popis jednotlivých vstupních a výstupních audiovizuálního stop a operací provád¥ných nad t¥mito stopami. Výhodou skriptu napsaném v tomto jazyce je i moºnost automatizovat stále se opakující operace nad ur£itou sekvencí záznam·. 1
2
KAPITOLA 1.
ÚVOD
1.3 Kapitoly Hlavní kapitoly této práce se zabývají t¥mito tématy: Kapitola 2 pojednává o hlub²ím popisu problému práce a jsou zde de novány cíle, které by tato práce m¥la obsáhnout. Kapitola 3 se zabývá teoretickým návrhem a analýzou daného systému a jeho £ástí. Kapitola 4 obsahuje popis implementace jednotlivých £ástí. Kapitola 5 popisuje výsledky implementa£ní £ástí a diskusi o jejich moºném dal²ím roz²í°ení. Kapitola 6 obsahuje zhodnocení dosaºených výsledk· a celé práce.
Tato práce navazuje na výsledky dosaºené v rámci Bakalá°ské práce a Semestrálního projektu takto: • Bakalá°ská práce - re²er²e pojednávající o principu ukládání video-signálu do for-
mát· MPEG-2 s cílem navrhnout zp·sob vyuºití pro ukládání stereo-video-signálu tak, aby vºdy jeden ze dvou signál· mohl být standardním p°ehráva£em videa dekódován a druhý ignorován.
• Semestrální projekt - re²er²e pojednávající o principu ukládání audio-video signálu
do formát· MPEG-4
Kapitola 2
Popis problému, speci kace cíle Kapitola pojednává o cílech a rozsahu problému a poºadavcích na implementa£ní £ást práce.
2.1 Cíle práce Práce si klade za cíl vytvo°it nástroj pro snadnou úpravu audiovizuálního signálu, kde jsou ve v¥t²in¥ p°ípad· na sob¥ jednotlivé stopy závislé. Nap°íklad mám¥ nato£eno n¥kolik sekvencí stejného d¥je ve stejnou dobu a z r·zných úhl·. P°i prezentaci tohoto d¥je je pot°eba zachovat konzistenci mezi v²emi sekvencemi i p°i spole£né úprav¥ nebo i p°i úprav¥ jen jedné ur£ité sekvence. Základní my²lenkou je vytvo°it jazyk, který bude de novat vstupní signály, operace nad vstupními signály a jejich výstup. Jazyk by m¥l být dob°e £itelný a srozumitelný pro £lov¥ka, který jiº má aspo¬ základní zku²enosti s n¥kterým programovacím jazykem (C++, Java, VRML). S de nicí jazyka jiº bude moºné vytvá°et skripty. Práce bude zahrnovat program, který nebude obsahovat ºádn¥ gra cké rozhraní a bude p°ijímat jen skripty s de nicemi poºadovaných úprav. Pokud program rozezná ve skriptu syntaktickou chybu nebo nebude moci najít poºadovaný soubor nebo modul, tak zobrazí zprávu s p°edpokládanou chybu v de nici, ukon£í úpravy a celý program. Sou£ástí implementace bude také gra cké rozhraní, ve kterém bude tvorba skriptu usnadn¥na a gra cky znázorn¥na.
2.2 Sou£asný stav problematiky V sou£asné dob¥ existuje velmi málo program· umoº¬ujících úpravu videa i pomocí skriptovacího jazyka. Jeden z t¥chto program· je i projekt s názvem VirtualDub. Tento program v sob¥ obsahuje de nici skriptovacího jazyka pro popis zpracování videa s názvem Sylia. Syntaxe tohoto jazyka je podobná zjednodu²ené syntaxi jazyka C++, obsahuje v sob¥ základní datové typy, t°ídy a pole. V implementaci jazyka je k dispozici mnoºství t°íd pro manipulaci s daty a nastavení mnoha atribut· (nap°íklad typ komprese). Av²ak podle speci kace jazyka v aktuální verzi (0.7) je moºné manipulovat jen s jednou video stopou a dv¥ma audio stopami. To v²ak nespl¬uje ná² cíl, kdy poºadujeme moºnost zpracování více stop zárove¬. 3
4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza a návrh °e²ení První podkapitola se zabývá °e²ením problému ukládání více zvukových nebo obrazových stop do formátu MPEG-4. Druhá podkapitola °e²í analýzu jazyka, který by umoº¬oval popsat v²echny d·leºité operace de nované v zadání práce. Poslední podkapitola °e²í návrh £len¥ní implementace programu na moduly podle funk£ních poºadavk·.
3.1 Analýza ukládání ve formátu MPEG-4 MPEG-4 je název skupiny standard· pouºívaných na kódování audiovizuálních informací za ú£elem zmen²ení jejich velikosti (komprese) nebo za ú£elem jednodu²²í prezentace. Standard MPEG-4 je de nován v norm¥ ISO/IEC 14496, který se je²t¥ d¥lí na 27 £ástí. Kaºdá £ást tohoto standardu de nuje jednu oblast vyuºití nebo roz²í°ení tohoto standardu. Jak se formát dále roz²i°uje tak vznikají i nové £ásti standardu. Základní tzv. systémová £ást je de nována v standardu ISO/IEC 14496-1. Systémová £ást v sob¥ obsahuje popis základních algoritm· a struktur pro uloºení multiplexovaných zvukových, obrazových, p°ípadn¥ dal²ích informací a zaji²t¥ní také jejich synchronizace a správu vyrovnávacích pam¥tí. Standard ISO/IEC 14496-2 popisuje kompresi vizuálních dat (videa, textur a syntetických obrázk·) Standard ISO/IEC 14496-3 popisuje kompresi zvukových dat. Standard ISO/IEC 14496-12 popis souborového kontejneru formátu MPEG4.
3.1.1 Model systémového dekodéru Celá problematika systémové £ásti je speci kována v norm¥ ISO/IEC 14496-1 [1], zde budou uvedeny jen základní principy související s touto prací. Systémová £ást formátu MPEG-4 zaji²´uje správnou synchronizaci a prezentaci audiovizuálních informací. V této oblasti se datový tok jednoho druhu informací ozna£uje jako elementární stream, coº m·ºou být zvukové, obrazové, textové informace nebo informace o zm¥nách scény. P°i kódování a dekódovaní vstupuje kaºdý elementární stream do p°íslu²ného kodéru nebo dekodéru, který ho dokáºe správ¥ kódovat nebo dekódovat. Elementární stream se dále d¥lí na takzvané Access Unit (AU), coº je jiº nejmen²í datový element, který sebou nese svoji £asovou informaci. V²echny elementární streamy jsou indexovány 5
6
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
£ísly od 0, kaºdá AU pak v sob¥ obsahuje £íslo elementárního streamu ke kterému pat°í. Dal²í d·leºitou informací, který si nese kaºdá AU jsou £asové zna£ky, kdy má být jednotka dekódována, tzv. Decoding Time Stamp (DTS) a Presentation Time Stamp (PTS), která udává kdy má být prezentována. ádné dv¥ AU jednotky v jednom elementárním streamu nemohou mít stejnou DTS a PTS. Na obrázku 3.1 je zobrazeno základní schéma pro dekódování a prezentaci objekt·. Objektem je my²leno zobecn¥ní pro r·zné druhy audiovizuálních dat, popis scény, titulk· a jiných kódovaných informací v systému MPEG-4. Z demultiplexoru vystupují datové pakety ozna£ené indexem stopy. Dekódovací vyrovnávací pam¥´ (DB ) slouºí k ukládání £ástí AU, které v¥t²inou nejsou uloºeny v celku, ale jsou je²t¥ rozd¥leny na men²í £ásti (pakety) z d·vodu plynulej²ího p°ehrávání. Pro uchování dekódovaného objektu £ekajícího na dal²í zpracování nebo prezentaci slouºí tzv. prezenta£ní vyrovnávací pam¥´ (PB ). Z obsahu t¥chto pam¥tí se pak skládá (vytvá°í) výsledná prezentace.
Obrázek 3.1: Dekódovací schéma MPEG4
3.1.2 MPEG4 kontejner V²echny informace uloºené v záznamu jsou zapouzd°eny v tzv. MPEG4 kontejneru. Tento je de nován ve standardu ISO/IEC 14496-12 [4] a ISO/IEC 14496-14. MPEG4 kontejner v sob¥ obsahuje krom¥ záznamu i informace o pouºitých dekodérech, strukturách pro uloºení záznamu a informace pro podporu vyhledávání klí£ových snímk· v záznamu. Tyto informace jsou d·leºité pro p°ehráva£e, aby správn¥ rozpoznaly jejich obsah a um¥ly je dekódovat. Kontejner se skládá ze t°í základních £ástí. První £ást uvozenou °et¥zcem "ftyp" ( le type) de nuje verzi pouºitého kontejneru a kompatibilitu. V dal²í £ásti jsou pomocí speciálního °et¥zce, ozna£eného "mdat" (media data container), uloºena ve²kerá mediální data, která tento soubor obsahuje. Tyto data jsou rozd¥lena na na stejn¥ dlouhé úseky dat nazývané pakety a ozna£ena podle p°íslu²nosti k jednotlivým elementárním stream·m. K identi kaci obsahu celého bloku "mdat" slouºí £ást nazývaná metadata container a ozna£ené °et¥zcem "moov ". Jsou zde uloºené v²echny d·leºité informace o jednotlivých elementárních streamech, nap°íklad jak jsou dlouhé, jejich datový tok, datum vytvo°ení aj. Je zde obsaºen i index v²ech klí£ových I-snímk· a kde se v souboru nacházejí, pro jednoduché hledání.
3.2.
ANALÝZA PROBLÉMU
7
Podrobn¥j²í informace kolem struktury celého souboru lze nalézt ve zdroji [7] nebo p°ímo ve speci kacích iso [1], [4], [3].
3.2 Analýza problému Pro návrh jazyka byl inspirací jazyk VRML, který je primárn¥ ur£en pro popis t°írozm¥rných scén virtuální reality. Vlastností jazyka VRML je, ºe popisuje scénu pomocí grafu (stromu), kde v listech jsou uloºeny elementární objekty nacházející se ve scén¥ a v nad°azených uzlech jsou uloºeny operace a transformace t¥chto objekt·. Podobnou ideou se zabývá tato práce, kde v²echny operace nad vstupními daty jsou prezentovány uzly. Popí²eme tuto ideu nejd°íve pro jednu stopu.
Obrázek 3.2: Gra cké znázorn¥ní struktury pro jeden kanál Ko°en stromu p°estavuje celé rozloºení scéná°e úprav. Scéná°em úprav je my²leno sestavení r·zných sekvencí audio-vizuálního obsahu v£etn¥ jejich transformací (°azení za sebe) do jedné £asové linie. Listy stromu p°estavují vstupní data. Tyto data mohou být bu¤ zvukové, obrazové nebo kombinací t¥chto typ·. Listy se sami starají o na£ítání a p°edzpracování audiovizuálních informací tak, aby s nimi bylo moºné v celém strom¥ pracovat. Vnit°ní uzly stromu p°estavují operace, které se nad vstupními daty budou provád¥t. Kaºdý vnit°ní uzel m·ºe dále obsahovat n¥kolik potomk·, po°adí potomk· ur£uje jejich po°adí p°i zpracování a také prezentování. Nákres takovéhoto stromu je nazna£en na obrázku 3.2. Pomocí této struktury je moºné vytvá°et shluky sekvencí, se kterými lze jednodu²e manipulovat a zm¥nou jejich rodi£ovského uzlu lze jednodu²e m¥nit jejích rozloºení v kompozici. To znamená, ºe kaºdý uzel ve strom¥ má svojí vlastní lokální £asovou osu. Lokální osa má své výhody i nevýhody, hlavní její výhodou je, ºe je nezávislá na jakémkoli jiném uzlu, který je jí nad°azen nebo je jejím sousedem. To znamená, ºe nemohou z principu vzniknout ºádné £asové kolize, kdy by m¥ly být ve stejný £as zobrazeny dva nebo i více snímku p°es sebe. Také ºádný uzel nem·ºe p°edbíhat svého levého souseda nebo se opoº¤ovat za svým pravým sousedem. Z toho plyne jednoduchý zápis v²ech sekvencí.
8
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Nevýhodou této metody neschopnost p°ímo popsat prolínání dvou uzl· do sebe nap°íklad obraz v obraze nebo prolínání dvou obraz·. Tato nevýhoda by ²la vy°e²it funk£ním uzlem, který by de noval prolnutí svých sousedních potomk· v ur£itém £ase. Ukázka na obrázku 3.3. Tak by z·stala stále zaru£ena p°ehlednost celé stromové struktury. Stopy v obrázku jsou prezentovány obrázky lmu a dinosaura.
Obrázek 3.3: Ukázka návrhu funk£ního modulu s prolnutím svých dvou potomk· Roz²í°ení tohoto popisu pro více audiovizuálních stop znamená roz²í°ení stromu o jednu dimenzi. V podstat¥ se jedná o více nezávislých strom·, spojených pouze ko°enovým uzlem. Kaºdý uzel bude bude obsahovat pro kaºdou stopu seznam svých potomku, nazna£eno na obrázku 3.4. Toto °e²ení sice spl¬uje poºadavky na více kanál·, ale tím se nám
Obrázek 3.4: Gra cké znázorn¥ní struktury pro více kanál· i obecn¥ zhor²ila sloºitost a manipulovatelnost s celým stromem. Proto je pot°eba ud¥lat je²t¥ jednu malou úpravu a zavést tzv. monolitické uzly. Monolitické uzly jsou uzly, které se chovají jako jeden uzel, ale p°itom jsou v n¥m obsaºené v²echny stopy se kterými se v projektu pracuje. Mají jen jeden seznam svých potomku a jako jejich potomci jsou také o£ekávány monolitické uzly. Je moºné mít i monolitický vstupní uzel, to je uzel který uº na vstupu obsahuje poºadovaný po£et stop. Ve v¥t²in¥ p°ípad· v²ak nemáme
3.2.
ANALÝZA PROBLÉMU
9
na vstupu poºadovaný po£et stop a tak z t¥chto stop je pot°eba monolitický uzel vytvo°it. K tomuto ú£elu de nujeme hrani£ní monolitický uzel. Z pohledu rodi£e se tento uzel chová jako monolitický, ale jiº obsahuje více seznam· pro de nici více stop. Na obrázku 3.5 je nazna£ena takto de novaná struktura. K p°ehlednosti pom·ºou uzly skupiny (group ) nikterak nem¥ní obsah dat jen sdruºují uzly v nich obsaºené pro v¥²í p°ehlednost a manipulovatelnost.
Obrázek 3.5: Upravené gra cké znázorn¥ní struktury pro více kanál·
10
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
3.3 Analýza jazyka Jazyk by mel být schopen popsat: • Vstupy • Výstupy • De nici úprav a zm¥n nad vstupními daty
3.3.1 De nice datových typ· Jazyk podporuje £ty°i základní datové typy. integer - celo£íselný typ nap° 12 double - £ísla s desetinou £árkou nap° 0.25 string - textový °et¥zec nap° "media data" timestamp - £asová zna£ka reprezentující £as nap° "00:00:30.70", jednotlivé £ásti p°estavuji (hodiny):(minuty):(sekundy).(setina sekundy)
Druhy datových typ· jsou rozpoznávány p°i p°ekladu a není t°eba je blíºe ur£ovat. Dobrou vlastností jazyka jsou i komentá°e, zakomentování £ásti kódu je podobné jako v jazyku C °et¥zcem dvou zp¥tných lomítek (//).
3.3.2 De nice vstup· a výstup· Tato £ást jazyka se zabývá popisem datových zdroj· (vstup· - typicky soubor) a výstup· (coº m·ºe být obrazovka, soubor p°ípadn¥ sí´ové p°ipojení). Tyto oblasti musí být jednozna£n¥ odd¥leny, aby syntaktický analyzátor programu poznal, kde se nacházejí a co obsahují. Vstupní £ást ozna£íme klí£ovým slovem "Input" a výstupní £ást ozna£íme slovem "Output". Za t¥mito klí£ovými slovy se nacházejí de nice vstupních a výstupních uzl· uzav°ených ve sloºených závorkách "{ .. }". De nice vstupního uzlu se skládá z názvu modulu, který bude na£ítat vstupní data. Na základ¥ této de nice bude daný modul na£ten a zajistí správné dekódování vstupních dat. Tyto moduly jsou funk£n¥ odli²né, nap°iklad modul pro na£ítání statických obrázk· bude obsahovat jiné algoritmy, neº nap°íklad pro na£ítání zvukových dat. Za de nicí modulu následuje identi kátor, kterým je daný vstup pojmenován pro dal²í úpravy. V sloºených závorkách následují vstupní atributy modulu, které jsou mu p°i vytvá°ení p°edány. Kaºdý atribut je ozna£en svým klí£ovým slovem, je mu p°i°azena hodnota a je ukon£en st°edníkem. Kaºdý modul by m¥l mít své vlastní implicitní parametry a p°i ²patn¥ zadaném atributu by na to m¥l upozornit. Následující kód ukazuje jak by m¥la vypadat de nice vstupu pojmenovaném video1.
3.3.
ANALÝZA JAZYKA
11
Input{ AV video1{ // název_modulu identifikátor Path = "./video1.mp4"; // název_atributu = hodnota } }
De nice výstupního uzlu má oproti vstupním uzl·m pár rozdíl·. De nice výstup· neobsahují identi kátor (je to zbyte£né), ale obsahují de nice stop, které se do n¥j po úpravách celé uloºí. Toto je d·leºité, pokud do daného výstupu nechceme uloºit výsledek úprav v²ech stop, ale jen n¥kterých, nap°íklad pokud chceme získat pouze náhled nebo rozd¥lit výstupy do více soubor·. De nice výstupu je uvozena znakem '#' a následuje soupis stop tak jak jsou zapsány ve funk£ní £ásti. Nap°íklad °et¥zec #1, 4 ozna£uje, ºe se do tohoto výstupního uzlu uloºí jen data z první a £tvrté stopy. Za de nicí stop následuje de nice modulu, ta má stejný význam jako u vstupu. Tento modul se op¥t na£te a slouºí k nálnímu zpracování dat (nap°. uloºení do souboru). Následují atributy jako u vstupních uzl·. Output{ #1,2 screen { // #výstupy název_modulu width = 800; // název_atributu = hodnota height = 600; } }
3.3.3 De nice funk£ní £ásti Tato £ást popisuje úpravy provád¥né nad jednotlivými vstupy. V²echny operace nad vstupy jsou uloºeny v n¥kterém z uzl· stromu popisující úpravu daného záznamu. Kaºdý uzel je uvozen svým identi kátorem, tento identi kátor je bu¤ název vstupu, tak jak je de nován uºivatelem ve vstupní sekci nebo je to název pouºité funkce nebo modulu. Za identi kátorem se nacházejí parametry uzlu v kulatých závorkách a odd¥lené £árkou. Vstupní parametry musejí být základního typu, jak jsou de novány v £ásti kapitoly 3.3.1. Pokud uzel nemá ºádné parametry, z·stanou závorky prázdné. Obsah uzlu se zde d¥lí na dv¥ £ásti podle pouºití. Pokud budeme vytvá°et monolitický uzel, tak není t°eba zadávat informace o stopách. O tuto práci se stará n¥který z hrani£ních monilitických uzel, který je jeho potomkem. Taková de nice by vypadala následovn¥: Rotate(20){ grayscale(){ .. } group() .. } }
12
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
P°íklad ukazuje uzel provád¥jící rotaci obrazu, kterému je p°edán parametr 20 (rotace o 20◦ ), Tento uzel obsahuje dva potomky. Výstup tohoto samotného uzlu bude rotován o 20◦ a nejd°íve bude na výstup vloºen celý obsah uzlu grayscale a poté obsah uzlu group, tyto uzly jsou bu¤ monolitické nebo hrani£ní. Druhý moºný popis je popis hrani£ního uzlu, kdy je pot°eba jiº de novat p°ímo jednotlivé stopy. Tato de nice m·ºe vypadá nap°íklad následovn¥: translation(0,0,0,100,200,100){ #1 video1(00:00:20.00,00:00:30.00); video1(00:00:00.00,00:00:20.00); #2 video2(00:00:20.00,00:00:30.00); video2(00:00:00.00,00:00:20.00); }
Je zde ukázán nap°íklad uzel translation obsahující de nici dvou stop uvozenou #, kaºdá z t¥chto stop v p°íkladu obsahuje je²t¥ dv¥ sekvence ze vstupu pojmenovaného video1 a video2. V parametrech uzlu transformace je zadáno po£áte£ní posunutí obrazu v osách X a Y a startovní bod 0 (transformace hned od za£átku lokální £asové osy), parametr 100 a 200 udávají kone£né posunutí obrazu v osách X, Y a cílový bod transformace ve 100% £asové osy (na konci). Pokud nebudou mít sekvence v jednotlivých stopách stejnou délku, bude se brát v úvahu £as del²í stopy a v p°ípad¥ obrazových dat bude u krat²í stopy stále opakován poslední snímek z na£tených dat v p°ípad¥ zvukového signálu bude do stopy vloºen prázdný signál (ticho). Celou tuto £ást zast°e²uje klí£ové slovo 'Main', je to analogie ke ko°enovému uzlu. Na obrázcích je tento uzel znázorn¥n jako ko°en stromu 3.4, 3.4, 3.5. První parametr tohoto uzlu je po£et pouºitých obrazových stop, druhým parametrem je po£et zvukových stop. Main[2,1]{ .. }
3.4 Návrh implementace Tato £ást kapitoly popisuje návrh implementace a £len¥ní programu na jednotlivé funk£ní moduly.
3.4.1 Obecný návrh implementace Jedním z d·leºitých poºadavk·, které by m¥l navrhovaný systém spl¬ovat je jednoduchost a univerzálnost pouºití. Pro spln¥ní této podmínky je t°eba odd¥lit návrh hlavní £ásti systému, která zpracovává a manipuluje s vnit°ní strukturou stromu a návrh gra ckého rozhraní, které jiº jen vyuºívá funkcí hlavního systému.
3.4.
NÁVRH IMPLEMENTACE
13
Pro zvý²ení univerzálnosti pouºití by bylo dobré vytvo°it program tak, aby zku²en¥j²í uºivatel byl schopen vytvo°it nové funkce, které nejsou obsaºeny v základní knihovn¥ funkcí programu. Tato vlastnost je d·leºitá, protoºe základní knihovna funkcí nem·ºe obsáhnou v²echny funkce, které by kdy uºivatelé mohli pot°ebovat. My²lenkou je vytvo°it základní jádro programu, které bude schopno na£íst obsah p°edloºeného skriptu, z n¥hoº získá klí£ová slova modul· a poté podle t¥chto klí£ových slov dokáºe pouºít odpovídající modul. Jádro programu nebude samo o sob¥ mít ºádn¥ funkce na na£ítaní, ukládání nebo transformaci dat a o v²echny tyto záleºitosti se budou starat dynamicky na£ítané moduly. Pokud by se vyskytla chyba v jakémkoli základním modulu, sta£í ji opravit jen v daném modulu a ten pak zkompilovat. Není pot°eba kompilovat celý program a v²echny jeho p°idruºené knihovny. Funkce jádra budou obsaºeny v knihovnách, které budou vyuºívat ob¥ aplikace jak konzolová tak i aplikace s gra ckým rozhraním. Pro vytvo°ení gra ckého uºivatelského rozhraní jsem se rozhodoval mezi pouºitím knihovny GTK+ nebo QT. Ob¥ tyto knihovny jsou multiplatformní, tudíº dostupné na v²ech dne²ních, nejroz²í°en¥j²ích opera£ní systémech. Obrovskou výhodou knihovny QT je velmi kvalitní a názorná dokumentace [5] v£etn¥ p°íklad· a spustitelných ukázek. Z tohoto d·vodu jsem se rozhodl pouºít tuto knihovnu.
3.4.2 Modularita Jak jiº bylo d°íve zmín¥no, moduly se budou na£ítat vºdy p°i spu²t¥ní programu a budou uloºeny v podadresá°i programu (Plugins ). Poºadavky na základní funk£ní moduly: AV - na£ítání audiovizuálního obsahu VsM group - nemá ºádnou edita£ní funkci, je jen pro p°ehledn¥j²í a jednodu²²í správu ve strom¥ uzl· FM rotate - rotace obsahu FM translate - posun obsahu FM scale - ²kálování obsahu FM fade - stmívání - p°echod do tmy nebo p°edem de nované barvy FM grayscale - zm¥na barvy na ²edou stupnici FM screen - výstup na obrazovku FM MPEG4 - výstup do souboru ve formátu MPEG4 VyM
Zkratky FM -funk£ní modul, VsM -vstupní modul, VyM -výstupní modul
14
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
U n¥kterých funkcí je ºádoucí, aby se jejich parametry b¥hem £asu m¥nily. Nap°íklad bude-li stanoven startovní bod, kdy má za£ít p°echodový d¥j a bod kdy má skon£it, nazývejme tyto body startovní a cílový bod. Kaºdý z t¥chto bod· bude mít stanovenou °ídící hodnotu p°echodu a mezi t¥mito body se tato hodnota bude plynule m¥nit (lineární funkce). Startovní body a jejich hodnoty nemusejí vºdy za£ínat na hodnotách 0. Pr·b¥h takové funkce je nazna£ena na obrázku 3.6, konkretn¥ na funkci fade (stmívání). P°ed startovním bodem by m¥la mít funkce hodnoty startovního bodu a za cílovým bodem nem¥nnou hodnotu cílového bodu.
Obrázek 3.6: Znázorn¥ní funkce klí£ových £as· a interpolace hodnoty u funkce fade
Kapitola 4
Realizace 4.1 Funkce a struktury jádra Implementace jádra obsahuje vlastní lexikální a syntaktický analyzátor pro na£ítání jazyka.
4.1.1 Programová analýza jazyka Lexikální analyzátor rozd¥luje vstupní posloupnosti znak· na lexikální jednotky (£ísla, identi kátory, klí£ová slova, °et¥zce). Tyto lexikální jednotky nazývané tokeny jsou poté zpracovány syntaktickým analyzátorem. Seznam moºných token· je de nován ve zdrojovém kódu v souboru token.h. Lexikální analyzátor je koncipován jako deterministický kone£ný automat, identi kace symbolu se ur£uje podle koncového stavu automatu. Syntaktický analyzátor zpracovává lexikální jednotky p°ipravené lexikálním analyzátorem a vytvá°í celou strukturu zpracovávaného skriptu. Základní fáze syntaktické analýzy: 1. Na£ítání vstupní £ásti skriptu, která obsahuje de nice vstup·, a vytvá°ení seznamu vstupních identi kátor·. Identi kátor·m jsou p°edány jejich atributy a £ekají na své pouºití v seznamu globálních identi kátor· v objektu RootNode (ko°enový uzel stromu úprav). 2. Na£ítání výstupní £ásti skriptu, která obsahuje de nice výstup· a vytvá°ení seznamu výstupních uzl·, které jsou p°idávány do seznamu výstupních uzl· v objektu RootNode. 3. Na£ítání funk£ní £ásti skriptu. V této jsou popsány vlastní úpravy. Z rozpoznaných klí£ových slov funkcí vstupních identi kátor· a z de nic stop je vytvá°en strom celého scéná°e úprav. Ko°enem celého scéná°e je objekt RootNode. Náhled na implementované t°ídy je ukázána na UML grafu E.2 v p°íloze. 15
16
KAPITOLA 4.
REALIZACE
4.1.2 Vnit°ní struktura Zpracováním skriptu pomocí syntaktického analyzátoru se vytvá°í vnit°ní struktura zast°e²ená ko°enovým uzlem. Základní schéma ko°enového uzlu je ukázáno na 4.1. Tento uzel obsahuje celý popis skriptu a m·ºe být pro dal²í zpracování celý p°edán dal²ím aplikacím. Tohoto se vyuºívá u gra ckého rozhraní, kde knihovny jádra p°edají gra ckému uºivatelskému rozhraní ukazatel na ko°enový uzel a program GUI si v²echny pot°ebné informace z této jedné struktury vezme.
Obrázek 4.1: Obecná struktura ko°enového uzlu
4.1.3 Zpracování O °ízení celého zpracování se stará algoritmus implementovaný v ko°enového uzlu. V první fázi se celý strom scéná°e úprav musí inicializovat. Inicializace se volá ve strom¥ rekurzivn¥ a inicializuje v²echny prom¥nné a zdroje pro jejich pouºití. Poté si ko°enový uzel vyºádá od v²ech svých potomk· jejich délky, toto volání je také rekurzivní. Kaºdý uzel si vyºádá od svých potomku jejich délky a tyto délky bu¤ se£te jako svoji celkovou délku nebo vypo£ítá svoji novou délku a po²le ji svému rodi£ovskému uzlu. Samotné zpracování výsledného snímku probíhá inkrementáln¥ dotazováním ko°enového uzlu na ur£itý snímek ve scéná°i úprav. Je dotazováno postupn¥ na v²echny snímky ve scéná°i úprav a jen na ty stopy, které jsou de nované na výstupu. Je zbyte£né se ptát na stopy, které nebudou vkládány na výstup. Kaºdý uzel si sám °ídí správu lokální £asové osy a správu dotazování svých potomku. K tomuto ú£elu jsou v aplika£ním programovacím rozhraní (API ) implementovány algoritmy pro správu £asové osy a dotaz·. Tyto algoritmy nemodi kují parametry £asové osy. Pokud v²ak chceme vytvo°it uzel, který m¥ní rychlost nebo chod £asové osy, je pot°eba si tyto funkce upravit. Obrázek 4.2 schématicky ukazuje postup procházení stromu a získávání jednotlivých snímk· nebo fragment· zvukového signálu. Obrazové snímky se p°edávají ve formátu RGB, to z d·vodu jednoduché manipulace a úprav t¥chto snímk·. Zvukový signál je uloºen v seznamu fragment· zvuku. První zvukový fragment vloºený do tohoto seznamu také první vystupuje (fronta typu FIFO).
4.2.
FUNKCE A STRUKTURY MODUL
17
Obrázek 4.2: Zp·sob zpracování stromu scéná°e Získané snímky se podle nastavených stop vkládají do p°íslu²ných uzl· výstupu a ty je podle svých algoritm· zpracovávají.
4.2 Funkce a struktury modul· 4.2.1 Zobrazování Implementace programu podporuje pouze zobrazovení obrazových sloºek. Náhled p°i zpracování umoº¬uje modul screen a v gra ckém rozhraní je to okno s náhledem. V obou t¥chto p°ípadech je pro zobrazení pouºita stejná metoda. Zobrazení vyuºívá prost°edí a API OpenGL. Na vytvo°ený £tverec pokrývající celou plochu okna prost°edí OpenGL jsou naneseny texturovací sou°adnice a p°ipojena textura. Pak jiº sta£í jen m¥nit obsah textury p°ijímanými snímky. Výhodou je, ºe p°i zm¥n¥ velikosti okna se nemusejí p°epo£ítávat data na jiné rozli²ení, ale o tuto záleºitost se stará OpenGL a gra cká karta.
4.2.2 Dekódování a kódování Pro kódování a dekódovaní jsou pouºity knihovny projektu FFmpeg [2]. Jejích sou£ástí jsou následující knihovny. Knihovna libavcodec se stará o kódování a dekódování obrazu a zvuku, libavformat se stará o multiplexování, demultiplexování a formáty pouºité v kontejneru (v na²em p°ípad¥ MPEG4 kontejneru) a libswscale umoº¬uje p°evod obrazových dat do rozli£ných formát· a jejich ²kálování. Pro implementaci vstupního modulu (AV ) pro na£ítání záznam· ze souboru bylo pot°eba vytvo°it kódovací a dekódovací schéma. Dekódovací implementace odpovídá schématu na obrázku 3.1. Demultiplexor a dekodér objekt· je implementován v knihovn¥ FFmpeg. Funkce této knihovny bylo pot°eba dále v programu doplnit o navázání t¥chto £ástí (demultiplexor a dekodér) na sebe a vytvo°ení dekódovacích vyrovnávacích pam¥tí. Výstupem z dekódovacího schématu jsou pro formát MPEG-4 obrazové snímky
18
KAPITOLA 4.
REALIZACE
ve formátu YUV420. Tyto snímky je pot°eba p°evést na formát RGB, který se pouºívá p°i zpracování ve stromové struktu°e scéná°e úprav. P°evod zaji²´ují metody knihovny libswscale. Na obrázku E.4 je schéma uzlu pro na£ítání záznam· ze souboru. Základním objektem reprezentujícím na£tený soubor je AVFormat, ten obsahuje objekty AVFormatContext z nichº kaºdý reprezentuje jednu stopu ve formátu. Kaºdý objekt stopy obsahuje objekt AVCodec, coº je reprezentace pouºitého kodéru na dekódování celé stopy. Po inicializaci a nastavení správného dekodéru pro kaºdou stopu, je moºné za£ít postupn¥ vybírat pakety z datového streamu a ukládat je do vyrovnávací pam¥ti. Pokud jiº je na£ten celý snímek, tak se obsah vyrovnávací pam¥ti m·ºe dekódovat pomocí k tomu ur£ené funkce. O snímku máme dostupné v²echny informace jako jsou velikost jeho PTS, DTS a formát obrazu. Obecn¥ p°i p°esunu ve formátech MPEG je problém dekódovat jen jeden ur£itý snímek. Snímky jsou obsaºeny ve skupinách zvaných Group Of Pictures (GOP ), kde na sebe snímky p°ímo navazují a nejdou jednotliv¥ dekódovat. P°esouvání po souboru probíhá po I snímcích, coº jsou klí£ové snímky, které jediné jde samostatn¥ dekódovat. Pokud se soubor skládá jen ze samých I snímk·, tak lze kdykoli sko£it na jakýkoli snímek v souboru a dekódovat ho. V¥t²inou se v²ak soubor skládá i z rozdílových snímk· B a P a ty jiº nejde samostatn¥ dekódovat. Je pot°eba vy°e²it problém, aby bylo moºné dekódovat jakýkoliv poºadovaný snímek. Moºnosti jsou dv¥. První moºností je vºdy na£íst, postupn¥ dekódovat a uloºit do pam¥ti celý GOP, tato moºnost je náro£n¥j²í na pam¥´ a pracuje dob°e pokud budeme ºádat o dal²í snímek ze stejného GOP. Ideálním p°ípadem vyuºití této metody je p°ehrávání pozpátku. Druhou moºností je dekódovat jen snímky od klí£ového snímku k poºadovanému a aº ten uloºit a zbytkem GOPu se nezabývat. Tato metoda není tak náro£ná na pam¥´ a nap°íklad p°i rychlém p°ehrávání, kdy je t°eba z GOP dekódovat jen jeden ur£itý snímek je efektivn¥j²í. Nejhor²ím p°ípadem pro tuto metodu je p°ehrávání pozpátku, kdy jsou n¥které snímky dekódovány vícekrát. Pro implementaci byla pouºita druhá metoda, z d·vodu men²í náro£nosti a p°edpokladu, ºe se ve v¥t²in¥ p°ípad· budou poºadovat po sob¥ jdoucí snímky. P°i kódování je postup opa£ný. Nejd°íve se musí vytvo°it nový kontext formátu AVFormat a p°edat mu název nového souboru. Dále se musí do tohoto formátu p°idat poºadovaný po£et audio a video stop a nastavit t¥mto stopám kodér a parametry. Vstupní obrazová data je nejd°íve nutné p°evést do správného obrazového formátu (YUV420 ) a rozli²ení, zvuková data taktéº. Pak vstupují data do kodér·, který tyto data zkomprimuje. Je pot°eba vytvo°it novou strukturu AVPaket, této struktu°e p°edat informace o zkomprimovaných datech, nastavit £asové informace PTS a DTS. Po té je paket zapsán do kontextu formátu AVFormat. Na konec je pot°eba objekt AVFormat uzav°ít, tím se ukon£í v²echny stopy a uloºí ostatní nastavení pot°ebné k dekódování.
4.2.3 Funk£ní moduly K implementaci n¥kolika modul· bylo pouºito algoritm· popsaných v knize Moderní po£íta£ová gra ka [8]. Jsou to zejména algoritmy pro p°evod obrázku do ²edé stupnice a transformace typu posunutí, ²kálování a rotaci.
4.3.
GRAFICKÉ ROZHRANÍ
19
U n¥kterých modul· je moºno pouºít dynamicky se m¥nící parametry v závislosti na nastavení klí£ových bod·. Klí£ové body se nastavují v procentech £asové osy. Moduly umoº¬ující dynamickou zm¥nu parametr· jsou transforma£ní scale, translate, rotate a modul fade. UML diagram na obrázku v p°íloze E.3 ukazuje implementované t°ídy PlugTranslation pro rozpoznání modulu a TranslationNode implementující funk£ní uzel.
4.3 Gra cké rozhraní Pro tvorbu gra ckého rozhraní byly pouºity knihovny QT. Ukázka implementovaného gra ckého rozhraní je na obrázku 4.3. Pracovní plocha je rozd¥lena na 3 základní £ásti. Pro panel funkcí, vstupních a výstupních modul· je pouºit prvek QToolBox, který umoº¬uje p°epínání mezi sekcemi menu. Název a gra cké ozna£ení je sou£ástí kaºdého modulu. Panel funk£ních modul· je vºdy napln¥n p°i spu²t¥ní programu a je dále nem¥nný. Do menu obsahující vstupy a výstupy lze dal²í elementy p°idávat p°es hlavní menu. P°idáním se roz²í°í menu o danou poloºku a je podle toho aktualizován ko°enový uzel.
Obrázek 4.3: Ukázka implementace gra ckého rozhraní Gra cké znázorn¥ní scéná°e úprav je roz²í°ením QT objektu QGraphicsScene. Kaºdý uzel scéná°e je reprezentován gra ckým elementem odvozeným od t°ídy QGraphicsItemGroup, ten obsahuje obrázek funkce uzlu. Elementy obsahují spojnice s jinými elementy, znázor¬ující jejich návaznost s rodi£i nebo potomky. Náhledové okno a okno nastavení jsou °e²ena jako plovoucí okna, které je moºné nap°íklad p°ipojit k pravé stran¥ hlavního okna. Jsou odvozena od QDockWidget a pokud nejsou pot°eba je moºné je zav°ít, p°i pot°eb¥ se op¥t zobrazí. Sou£ástí náhledového okna je panel QGLWidget. Zobrazení snímk· v OpenGL je probráno v kapitole 4.2.1. Pod panelem jsou jeho ovládací prvky. Okno nastavení se dynamicky m¥ní podle ozna£eného uzlu a jeho moºných parametr·. Kon gurace nastavení je ve struktu°e Con gNodeStructure kaºdého modulu. Con gNodeStructure uchovává pro daný uzel seznam názv· parametr·, jejích typy a ozna£ení.
20
KAPITOLA 4.
REALIZACE
Podle typu parametru se ur£ují elementy, které se nejlépe hodí pro jejich zadávání a ty jsou také zobrazeny s aktuální hodnotou parametru v uzlu. V okn¥ nastavení tak m·ºou být nastavovány v²echny základní typy prom¥nných a p°i jejich zm¥n¥ jsou hned aktualizovány v uzlu.
Kapitola 5
Testování 5.1 Testování implementace K testování byly pouºity upravené £ásti krátkých lm· Big Buck Bunny a Elephants dream. Tyto lmy je moºné voln¥ ²í°it a upravovat. Domovské stránky t¥chto lm· se nachází na adresách www.bigbuckbunny.org a www.elephantsdream.org. Pro testování výstupních soubor· byl pouºit program VLC media player, který dokáºe p°ehrávat více stop ve více oknech zárove¬. Je to náhradní °e²ení místo projektu vícekanálového p°ehráva£e, který p°ímo nesouvisí s touto prací a jehoº implementace nebyla cílem této práce. Program VLC player lze nalézt na stránkách projektu www.videolan.org. Binární soubory programu VLC uloºené v repositá°ích distribuce Ubuntu si bohuºel nerozumí se zkompilovanými knihovnami FFmpeg, které jsou pot°ebné pro b¥h programu. e²ením je nap°íklad stáhnout zdrojové kódy VLC a zkompilovat celý p°ehráva£ nebo vy°e²it kon ikty r·zných verzí knihoven. V mém p°ípad¥ jsem zkompiloval program s novými knihovnami. Testování bylo provád¥no na po£íta£ové kon guraci s procesorem Intel Core 2 2.2 GHz, 2 GB RAM a gra ckou kartou nVidia GeForce 7600ST. Opera£ní systém Ubuntu 9.04.
5.1.1 Test 1 První test má za cíl otestovat správnou funk£nost vybraných modul·. Z lmu Big Buck Bunny byla vybrána £ást o délce t°i minuty. Do této sekvence bylo do obrazových dat p°idáno ozna£ení soubor· £íslicemi 1 a 2, aby bylo moºné od sebe vizuáln¥ rozli²it r·zné stopy. Testovaný videoklip byl zmen²en na velikost 480∗270 bod·, z d·vodu sníºení výpo£etní náro£nosti p°i testování. Testované soubory jsou ve formátu MPEG4. Pouºitý video kodér je MPEG4-video a pro audio stopu je pouºit AAC. Po£et snímk· za sekundu je 24. Pro testování byl napsán krátký skript, který obsahuje n¥které funkce programu. Celý skript je uveden v p°íloze F. Po spu²t¥ní programu p°íkazem ./vscript test0.vsr jsou do standardního výstupu zapsány informace o pracovním adresá°i a název spou²t¥ného skriptu. Jsou vypsány nalezené knihovny a jejich stav p°ipojení do programu. Poté je vypsán krátký stav inicializace a nakonec je vypsán kone£ný stav programu. Pak je 21
22
KAPITOLA 5.
TESTOVÁNÍ
program ukon£en. V adresá°i se skriptem je výsledný soubor se v²emi poºadovanými úpravami. Následuje výpis konzolového programu. Current work Dir: "/home/rodeo/App/LexAn/debug/src", File :" test0.vsr" ./Plugins/.libs/libplugscale.so - LOAD ./Plugins/.libs/libplugscreen.so - LOAD ./Plugins/.libs/libplugrev.so - LOAD ./Plugins/.libs/libpluggroup.so - LOAD ./Plugins/.libs/libplugiav.so - LOAD ./Plugins/.libs/libplugspeed.so - LOAD ./Plugins/.libs/libplugfade.so - LOAD ./Plugins/.libs/libplugtrans.so - LOAD ./Plugins/.libs/libpluggray.so - LOAD ./Plugins/.libs/libplugrot.so - LOAD ./Plugins/.libs/libplugomp4.so - LOAD ----------------------------------Init node Init output Done
Znázorn¥ní testovacího skriptu v gra ckém programu je ukázáno na obrázku 5.1. Jak je z obrázku patrné, algoritmus pro umís´ování uzl· není nejvhodn¥j²í a ob£as se sousední uzly mohou p°ekrývat. Proto by bylo vhodn¥j²í najít lep²í algoritmus, který by nejd°íve analyzoval celou strukturu stromu a pak by, umístil uzly tak, aby se navzájem nemohly p°ekrývat.
Obrázek 5.1: Znázorn¥ní testovacího skriptu v programu gra ckého rozhraní
5.2.
23
DISKUSE
kon gurace 1 kon gurace 2 po£et vstupních uzl· 2 118 po£et transforma£ních uzl· 1 59 £as výpo£tu [minut] 182 186 pouºitá pam¥´ [MB] 91 186
Tabulka 5.1: Výsledky testu £. 2
5.1.2 Test 2 Druhý test si bere za cíl odzkou²et program na velkých souborech vstupních dat (°ádov¥ stovky megabyt·) v r·zných kon guracích. Sledovanými poloºkami byly £as a vyuºití opera£ní pam¥ti. K testování byly pouºity lmy Big Buck Bunny a Elephants dream v plném (HD ) rozli²ení, které £iní 1920x1080 bod·. Pro kaºdý kanál byl zvolen jeden lm a byla vybrána £ást o délce deseti minut. V první testovací kon guraci byl zvolen pro kaºdý kanál jeden vstupní uzel a jeden transforma£ní uzel rotace. V druhé testovací kon guraci byl pro kaºdý kanál zvolen jeden lm, rozd¥len na £ásti po 10 sekundách a nad kaºdou £ástí zvlá²´ byla provedena rotace transforma£ním uzlem. Oba testovací skripty se nacházejí z d·vodu v¥t²ího rozsahu na p°iloºeném CD v£etn¥ vstupních video soubor·. Výsledky test· jsou uvedeny v tabulce 5.1. Výsledné soubory byly zpracovány podle testovacích skript·. B¥hem celého testu bylo vyuºití pam¥ti konstantní, protoºe v²echny velké bloky pam¥ti se alokují na za£átku p°i inicializaci stromu. B¥hem zpracovávání stromu jiº není pot°eba alokovat dal²í velké bloky pam¥ti. Z tohoto poznatku lze tedy odvodit, ºe nejd·leºit¥j²ím parametrem ovliv¬ujícím mnoºství pouºité pam¥ti je po£et uzl·, nikoliv v²ak délka zpracovávaného videa. as zpracování obou testovacích kon gurací se li²í minimáln¥ a p°i pouºití stejných transformací je úm¥rn¥ závislý jen na délce vstupního zpracovávaného videa.
5.2 Diskuse Moºností k roz²í°ení této práce je n¥kolik. Nap°íklad tento návrh není uzp·soben k plnému vyuºití procesor· s více jádry nebo pro b¥h na skupin¥ po£íta£· (clusteru). Pro více jádrové procesory by sta£ila men²í úprava algoritmu, kde kaºdé jádro by zpracovávalo jednu stopu a tím by se výrazn¥ urychlil b¥h programu. K úprav¥ b¥hu algoritmu na clusteru by byla vhodn¥j²í metoda, kde by kaºdá výpo£etní jednotka p°edstavovala jeden nebo více uzl· ve scéná°i úprav a zaji²´ovala by jeho funkci. Ke zvý²ení vyuºitelnosti programu by p°isp¥lo roz²í°ení mnoºství modul·. Nap°íklad pro vstupní moduly to m·ºe být na£ítaní bitmapových nebo vektorových obrázk·, pro výstupní moduly t°eba ukládání do jiných formát· nebo rovnou vysílání do sít¥. Moºností na roz²í°ení funk£ních modul· je opravdu nep°eberné mnoºství nap°íklad barevné efekty, deformace obrazu aj. . Ke sníºení výpo£etní náro£nosti programu by mohlo pomoci vyuºití výpo£etního výkonu moderních gra ckých karet, které jsou £asto vybaveny více paraleln¥ pracujícími
24
KAPITOLA 5.
TESTOVÁNÍ
výpo£etními jednotkami. Tyto výpo£etní jednotky zvládají sice pouze jednoduché a specializované operace, ale díky paralelnímu zpracování a jejich po£tu (desítky a více) mohou dosahovat vysokých výkon· v n¥kterých aplikacích. K programování t¥chto výpo£etních jednotek se pouºívají speciální rozhraní. V sou£asné dob¥ je to hlavn¥ API OpenCL nebo CUDA rmy Nvidia. T¥chto moºností by se dalo vyuºít jak p°i kódování a dekódovaní a hlavn¥ samotných úpravách zpracovávaného videa.
Kapitola 6
Záv¥r V této práci se poda°ilo navrhnout a implementovat modulární nástroj umoº¬ující dávkové zpracování vícekanálového videa. Sou£ástí je i návrh jazyka popisujícího operace nad vstupními daty a de nice jejich výstup·. Základní funkce st°ihu videa jsou jiº sou£ástí jádra programu, ostatní funkce jsou obsaºeny v dynamicky p°ipojitelných modulech. Funk£ní moduly obsahují základní obrazové transformace jako posunutí, rotaci, zm¥nu m¥°ítka a zm¥nu barev, dále také umoº¬ují transformaci £asové osy. Vstupní a výstupní moduly umoº¬ují na£ítání a ukládání audiovizuálních dat ve formátu MPEG-4. Data mohou být na£ítána z n¥kolika zdroj· (soubor·) nebo mohou být na£tena z jediného zdroje (souboru), který obsahuje n¥kolik video stop. Implementace také umoº¬uje libovoln¥ rozd¥lit zpracovaná vícekanálová data do n¥kolika soubor· nebo v²e uloºit jen do jediného. Oproti zadání umoº¬uje implementace navíc na£ítat, upravovat a ukládat i zvukovou stopu, která je sp°aºena s jednou zvolenou video stopou. Sou£ástí práce je i kompletní dokumentace obou program· vygenerovaná z komentá°· zdrojových kód·. Pomocí p°iloºené dokumentace a zdrojových kód· je moºné vytvá°et dal²í roz²i°ující funkce (moduly) do obou program· a roz²í°it tak jejich moºnosti a pouºitelnost. Poda°ilo se navrhnou gra cké rozhraní pro jednoduchou úpravu a vytvá°ení skript· v de novaném jazyce. Je moºné prohlíºet a m¥nit strukturu celého skriptu a jeho rozvrºení. Gra cké rozhraní umoº¬uje i celkový náhled na výsledné transformace v pr·b¥hu skriptu a umoº¬uje upravovat parametry sekvencí videa, které se hned po zm¥n¥ projeví. V programu byla implementována základní sada operací, která demonstruje moºnosti gra ckého rozhraní p°i vytvá°ení a úpravách skript·.
25
26
KAPITOLA 6.
ZÁV
R
Literatura [1] G. R. Alexandros Eleftheriadis, Carsten Herpel. Text for CD 14496-1 Systems, November 1997. [2] F. Bellard. FFmpeg project. http://ffmpeg.org, [Online], [cit. 2009-04-27]. [3] ISO/IEC. ISO/IEC 14496 Part 2: Visual, December 2001. [4] ISO/IEC. ISO/IEC 14496 Part 12: ISO base media le format, February 2004. [5] Trolltech and Nokia. Qt Reference Documentation. http://www.qtsoftware.com/, [Online], [cit. 2009-04-24]. [6] Wikipedie.
http://cs.wikipedia.org, [Online], [cit. 2009-04-24].
[7] R. oustal. MPEG4 kontejner.
http://www.rodeo.ic.cz/mp4/doc/mp4container2.pdf, [Online], [rev. 2007-10-
18], [cit. 2009-04-24].
[8] J. ára, B. Bene², and P. Felkel. Moderní po£íta£ová gra ka, volume 1. Compute Press, Oval Road, London, UK, 2th edition, 2004.
27
28
LITERATURA
Dodatek A
Seznam pouºitých zkratek ISO (International Organization for Standardization) Mezinárodní organizace pro normalizaci IEC (International Electrotechnical Commission) Mezinárodní elektrotechnické komise MPEG (Motion Picture Experts Group) název skupiny standard· pouºívaných na kódování audiovizuálních informací JPEG (Joint Photographic Experts Group) název skupiny, která navrhla formát JPEG nebo se touto zkratkou ozna£uje samotný formát. YUV420P Barevný model, typicky pouºívaný u barevných obrázku pro zmen²ení jeho velikosti. Informace o jasu jsou v plném rozli²ení a informace o barv¥ jsou pod vzorkovány. RGB Barevný model, kde kaºdý pixel nese informaci o t°ech barevných sloºkách. XPM (X PixMap) po£íta£ový formát soubor· pro ukládaní rastrové gra ky. AAC (Advanced Audio Coding) formát komprese video vyvinutý pro pouºití ve formátu MPEG-4 AU (Access Unit) nejmen²í datový úsek nesoucí informaci o svém zobrazení. Vyuºívá se ve formátech MPEG-4 DTS (Decoding Time Stamp) £asová zna£ná reprezentující £as, kdy se má ur£itý kódovaný blok dekódovat. Vyuºívá se ve formátech MPEG PTS (Presentation Time Stamp) £asová zna£ná reprezentující £as, kdy se má ur£itý blok zobrazit-prezentovat. CTS (Composition Time Stamp) speci kuje formát MPEG-4. Má podobnou funkci jako je PTS u star²ích formát·. GOP (Group Of Pictures) skupina obrázk·, které na sebe navazují. Skupina se skládá z I, B, P snímk·. CAVE (Cave Automatic Virtual Environment) technologie, která vytvá°í kolem pozorovatele vjem virtuálního prostou.
29
30
DODATEK A.
SEZNAM POUITÝCH ZKRATEK
UML (Uni ed Modeling Language) gra cký jazyk pro vizualizaci speci kaci a navrhování a dokumentaci programových systém· [6] API (Application Programming Interface) sbírku procedur, funkcí £i t°íd n¥jaké knihovny, které m·ºe vyuºívat programátor, který knihovnu vyuºívá. [6] VRML (Virtual Reality Modeling Language) jazyk navrºený pro popis t°írozm¥rných scén. CUDA (Compute Uni ed Device Architecture) paralelní výpo£etní architektura gra ckých karet rmy Nvidia
Dodatek B
P°íprava a instalace B.1 Hardwarové a softwarové poºadavky Jediným hardwarový poºadavkem je gra cká karta s podporou OpenGL 2.0 . Program je psaný v jazyce C++ a primárn¥ je ur£en pro opera£ní systém GNU/Linux. V²echny knihovny krom¥ X11lib (na kterém je závislý jen modul screen) existují i pro jiné opera£ní systémy, tak by nem¥l být problém zkompilovat program i pro n¥. Seznam pouºitých knihoven d·leºitých pro správný b¥h program·. X11lib knihovna pro zobrazení gra ckého rozhraní pouºívaná v modulu screen. (v 11.99.2) GLU knihovna pro zobrazení OpenGL kontextu v modulu screen (v. 7.4) QT knihovna vyuºita pro tvorbu gra ckého rozhraní aplikace (v. 4.5) (http://www.qtsoftware.com/) libfaac knihovnu vyuºívaná FFmpeg pro kódování formátu AAC (v. 1.26) FFmpeg knihovny pro kódování a dekódování audiovizuálních dat. Knihovna vyuºívaná ve vstupních a výstupních modulech. (http://www.mpeg.org/) verze knihoven: libavutil 50. 2. 0; libavcodec 52.22. 3; libavformat 52.32. 0; libavdevice 52. 1. 0; libswscale 0. 7. 1
B.2 P°íprava instalace Pro kompilaci program· a knihoven je pot°eba nainstalovat následující programy: libtool ve verzi 1.5.* s verzí 2 nejde program zkompilovat automake ve verzi 1.10 make ve verzi 3.18 g++ ve verzi 4.3 svn ve verzi 4.3
31
32
DODATEK B.
PÍPRAVA A INSTALACE
Dále jsou ke kompilaci pot°ebné knihovny popsané vý²e i s balí£ky pro vývoj. V mém p°ípad¥ se v²echny tyto knihovny a programy nacházely v repositá°ích systému Ubuntu 9.04. Av²ak v p°ípad¥ knihoven FFmpeg nebyly podporovány v²echny pot°ebné kodeky pro tuto práci a bylo pot°eba si vlastnoru£n¥ zkompilovat knihovny FFmpeg.
B.2.1 Kompilace knihoven FFmpeg 1. Staºení zdrojových kód· z repositá°· pomocí p°íkazu svn checkout svn://svn.mpeg.org/mpeg/trunk mpeg 2. Spu²t¥ní kon gura£ního skriptu s podporou v²ech pot°ebných knihoven a zapnutou volbou pro sdílené knihovny ./con gure enable-shared enable-libfaac 3. Spu²t¥ní kompilace p°íkazem make 4. Instalace knihoven do systému make install standardní p°edvolená cesta instalovaných knihoven je /usr/local/lib 5. Registrace nových systémových knihoven ldcon g 6. Vy°e²ení moºného kon ikt· s jiº d°íve nainstalovanými knihovnami FFmpegu nebo odinstalace d°ív¥j²ích knihoven
B.2.2 Kompilace program· U obou program· je p°iloºen i celý projekt vývojového prost°edí Kdevelop, ve kterém je moºné projekt zkompilovat. Vývojové prost°edí vytvá°í kon gura£ní scripty con gure a Make le, je tedy moºné tyto projekty zkompilovat i bez tohoto vývojového prost°edí. Kompilace obou program· je odli²ná z d·vodu pouºití knihoven QT, která mají trochu jiný zp·sob kompilace. Kompilace modul· a konzolové aplikace: 1. V adresá°i s projektem je pot°eba spustit kon gura£ní script, který vytvo°í p°íslu²ný Make le ./con gure 2. Pak uº jen sta£í spustit kompilaci celého projektu p°íkazem make 3. V adresá°i Optimized nebo Debug, záleºí na nasavení kompilace bude nov¥ zkompilovaný program i s p°íslu²nými moduly 4. Spustitelný binární soubor má název vscript a jiº je program p°ipraven k pouºití Kompilace programu gra ckého rozhraní:
B.2.
PÍPRAVA INSTALACE
33
1. V adresá°i s projektem gra ckého rozhraní je pot°eba nejd°íve spustit kon gura£ní program qmake 2. Pak jíº sta£í spustit samotnou kompilaci gra ckého prost°edí p°íkazem make 3. Zkompilovaný program bude v adresá°i bin 4. Program ke svému b¥hu pot°ebuje knihovny jádra aplikace a primárn¥ je hledá v adresá°i sdílených knihoven, tak je pot°eba mu tyto knihovny zp°ístupnit. Sta£í nakopírovat do adresá°e /usr/lib nebo v tomto adresá°i vytvo°it odkazy na následující sdílené knihovny: libplugin.so, libnodes.so, liblexical.so, libsynan.so. 5. Na záv¥r je nutné nakopírovat do adresá°e Plugins u spustitelného programu v²echny moduly, nebo vytvo°it symbolický odkaz na adresá° se v²emi moduly, které budeme chtít v gra ckém uºivatelském rozhraní pouºívat. 6. Spustitelný binární soubor má název vscriptgui a program je p°ipraven k pouºití
34
DODATEK B.
PÍPRAVA A INSTALACE
Dodatek C
Uºivatelská p°íru£ka C.1 Uºivatelská p°íru£ka konzolového programu Konzolová aplikace je na ovládání velmi jednoduchá. P°i jejím spou²t¥ní je pot°eba zadat jako spou²t¥cí parametr jen název skriptu, který má být zpracován. Po spu²t¥ní program vºdy vypí²e seznam v²ech na£tených modul·, to je informace pro uºivatele, jestli byly v²echny moduly správn¥ na£teny a které moduly mohou být pouºity ve skriptu. Pokud se ve skriptu vyskytne chyba, která zamezuje pokra£ování zpracování, program se ukon£i a do standardního výstupu vypí²e hlá²ení o chyb¥. Toto hlá²ení obsahuje informace, na kterém °ádku scriptu byla chyba nalezena a o jakou chybu se pravd¥podobn¥ jedná. Pokud tato chyba nenaru²uje zpracování, je do standardního výstupu vloºeno varování s p°íslu²nými údaji podobn¥ jako u chyb. Úsp¥²né zpracování je také oznámeno na standardní výstup.
C.2 Uºivatelská p°íru£ka základních modul· V základní instalaci je podporováno n¥kolik základních modul·. Zde bude popsáno jejich pouºití. Parametry a atributy psané kurzivou jsou volitelné. V²echny startovní a cílové body jsou udávány v procentech pr·b¥hu uzlu, není t°eba se zabývat jejich délkou.
C.2.1 AV Vstupní modul umoº¬uje na£ítání a dekódování audiovizuálních dat ze soubor·. Má jen jeden atribut Path - Cesta ke vstupnímu souboru, který bude zpracováván.
C.2.2 Group Funk£ní modul nemá ºádnou edita£ní funkci, nemá ºádn¥ vstupní parametry, je jen pro p°ehledn¥j²í a jednodu²²í správu ve strom¥ uzl·. group( ){..} 35
36
DODATEK C.
UIVATELSKÁ PÍRUKA
C.2.3 Rotate Tento funk£ní modul zpracuje v²echen obrazový obsah, který prochází tímto uzlem tak, ºe je rotován s osou rotace ve st°edu snímku hodnotu zadanou jeho prvním parametrem. Parametr je £íselného typu, udávaný ve stupních. rotate(start_hodnota, start_bod, cíl_hodnota, cíl_bod ) {..}
C.2.4 Translate Funk£ní modul umoº¬uje posunout obraz o stanovený po£et pixel· v osách X a Y v rámci jeho rozli²ení. Startovní a cílové hodnoty jsou udávány v pixelech translate(start_hodnota_osyX, start_hodnota_osyX, start_bod, cíl_hodnota_osyX, cíl_hodnota_osyY, cílový_bod ){..}
C.2.5 Scale Funk£ní modul umoº¬uje zv¥t²ovat nebo zmen²ovat sv·j obsah. Hodnoty ²kálování je pot°eba zadávat v %. scale(start_hodnota_²kálování, start_bod, cíl_hodnota, cílový_bod ){..}
C.2.6 Grayscale Funk£ní modul m¥ní rozsah barev procházejícího obrazu do ²edé stupnice. Nemá ºádné parametry. grayscale( ){..}
C.2.7 Fade Funk£ní modul vytvá°ející efekt stmívání, nebo rozjas¬ování, první parametr ur£uje typ p°echodu. Hodnota 0 - stmívání, 1 -rozjas¬ování. Následující t°i parametry ur£ují barvu p°echodu R, G, B a poslední dva parametry ur£ují startovní a kone£ný bod. fade(type, r, g, b, start_bod, cílový_bod ){..}
C.2.8 Speed Funk£ní modul zrychlující nebo zpomalující chod potomk·. Má jediný parametr udávaný v %. Standardní rychlost je 100-100% speed(rychlost){..}
C.2.9 Reverse Funk£ní modul otá£ející chod potomk·. Nemá ºádné parametry. reverse( ){..}
C.2.
UIVATELSKÁ PÍRUKA ZÁKLADNÍCH MODUL
37
C.2.10 Screen Výstupní modul umoº¬ující náhled p°i zpracovávání scény. Má následující atributy. width - nastavení rozli²ení v pixelech ²í°ky okna, implicitní nastavení 320 px height - nastavení rozli²ení v pixelech vý²ky okna, implicitní nastavení 200 px
C.2.11 MPEG4 Výstupní modul schopný kódovat a ukládat data ve formátu MPEG4, pouºitý kodér pro kódování videa je MPEG4-video a pro zvukovou sloºku se pouºívá kodér AAC. Má následující parametry: Path - nastavení cesty, kde bude uloºen kódovaný soubor width - nastavení rozli²ení v pixelech ²í°ky výstupu, implicitní nastavení 320 px height - nastavení rozli²ení v pixelech vý²ky výstupu, implicitní nastavení 200 px video_bit_rate - nastavení datového toku pro video, implicitní nastavení 400000 b video_gop_size - nastavení velikosti skupiny obrázk·, implicitní nastavení 12 audio_bit_rate - nastavení datového toku zvuku, implicitní nastavení 64000 b audio_sample_rate - nastavení vzorkovací frekvence zvuku, implicitní nastavení 44100 Hz
38
DODATEK C.
UIVATELSKÁ PÍRUKA
C.3 Uºivatelská p°íru£ka gra ckého rozhraní programu Gra cké uºivatelské rozhraní je rozd¥leno na 6 £ástí. Rozd¥lení t¥chto £ástí je ukázáno na obrázku C.1. Následn¥ budou v²echny £ásti popsány a vysv¥tlena jejich funkce.
Obrázek C.1: Základní rozloºení gra ckého rozhraní
1. Základní menu s roz²í°enými funkcemi programu 2. Li²ta s rychlými volbami 3. Menu s výb¥rem funkcí, vstup· a výstup· 4. Pracovní oblast, zobrazuje graf scéná°e. 5. Plovoucí okno s nastavením parametr· a prom¥nných ozna£ených uzl· 6. Plovoucí okno s náhledem a výb¥rem ozna£eného uzlu
Základní menu s roz²í°enými funkcemi programu Menu sdruºuje v²echny základní funkce: • File
New - vytvo°ení nového scriptu Open - otev°ení jiº existujícího scriptu Save - uloºení scriptu pod stávajícím jménem Save As - uloºení scriptu pod zvoleným jménem
C.3.
UIVATELSKÁ PÍRUKA GRAFICKÉHO ROZHRANÍ PROGRAMU
39
Close - uzav°ení projektu scriptu Exit - ukon£ení programu • Insert
Insert Input - Vloºí do projektu vstupní uzel. Obsahem je soupis moºných vstupních modul· Insert Output - Vloºí do projektu nový výstupní uzel. Obsahem je soupis moºných výstupních modul· • About
About - O programu a verzi programu About Plugin - Výpis na£tených modul· a jejich verzí s dal²ími informacemi.
Menu s výb¥rem funkcí Obsahuje jen jednu poloºku a to moºnost zv¥t²ování nebo zmen²ování náhledu na strom scéná°e.
Výb¥rové menu funkcí, vstup· a výstup· Náhled na moºný obsah jednotlivých menu je na obrázku C.2. Obsah menu je zobrazen pomocí ikon, kde kaºdé poloºce p°íslu²í intuitivní obrázek a v p°ípad¥ vstupních uzl· je to náhled na snímek v desáté sekund¥ vstupního souboru. Poloºky jsou rozd¥leny do t°í sekcí podle pouºití. V první sekci nazvané Input je soupis v²ech vstupních uzl·, které byly pouºity. Do tohoto menu se dají p°idat dal²í poloºky z hlavního menu v sekci Insert Input. Kaºdá poloºka, která je zde uvedená je ozna£ena jménem. Toto jméno je název identi kátoru, kterým se tento uzel ozna£uje v textu. P°i ozna£ení jakékoli poloºky z tohoto menu je moºné v náhledovém menu prohlédnout celý jeho obsah. P°idání tohoto uzlu do scéná°e se provádí funkcí Drag&Drop, kdy se chytne poloºka kurzorem my²i a p°etáhne se na poºadovaný uzel, kde má být p°idána. Poté je je²t¥ moºné v okn¥ Nastavení upravit parametry nového uzlu podle poºadavk· uºivatele. Odstran¥ní nepouºitého vstupního uzlu se provádí p°es kontextové menu, které je aktivováno pravým tla£ítkem my²i. Jedinou poloºkou tohoto menu je Remove - odstran¥ní uzlu. Druhá sekce nazvaná Function obsahuje v²echny na£tené funk£ní moduly. Kaºdý funk£ní modul je ozna£en intuitivní ikonou a jeho názvem (klí£ovým slovem). P°idání do scéná°e se provádí také zp·sobem Drag&Drop. T°etí sekce s názvem Output obsahuje v²echny aktivní výstupní uzly. P°i jejich ozna£ení lze v okn¥ Nastavení m¥nit jejich parametry. Odstran¥ní se provádí poloºkou Remove v kontextovém menu.
40
DODATEK C.
UIVATELSKÁ PÍRUKA
Obrázek C.2: Moºný obsah funk£ního menu
Pracovní oblast a vyobrazení grafu scéná°e V této oblasti (4. obr. C.1) je vyobrazena celá struktura scéná°e. Hlavním uzlem je uzel Root, ve stromové struktu°e je to to ko°en vyobrazeného stromu. Od tohoto uzlu se odvíjí celá stromová struktura scéná°e. Kaºdý uzel je znázorn¥n jeho ikonou a názvem. Kaºdý uzel v sob¥ znázor¬uje seznam svých potomku pro jednotlivé stopy. Tento seznam je reprezentován te£kami v ²edém poli. Pokud je uzel monolitický, tak má jen jeden seznam stop. Pro p°ehlednost je je²t¥ kaºdá te£ka spojena p°ímkou s jeho uzlovou reprezentací, tak jak je znázorn¥no na obrázku C.1.
Okno s nastavením parametr· Okno nastavení pro jednotlivé uzly (5. obr. C.1). Toto okno se vyplní obsahem jen v tom p°ípad¥, pokud modul obsahuje v sob¥ parametry pro toto nastavení. Pokud modul tyto parametry neobsahuje, tak z·stane okno prázdné. Pokud bude obsahovat chybnou de nici parametr· tak budou programem ignorovány. Pro jednotlivé základní typy jsou v tomto okn¥ jiº p°íslu²né druhy vstupních objekt·.
Okno s náhledem a výb¥rem Okno náhledu (6. obr. C.1). P°i ozna£ení uzlu zobrazí jeho náhled a umoº¬uje jeho prohlíºení. K ovládání náhledu slouºí pár ovládacích prvk·. Nejv¥t²ím prvkem je posuvník, která p°edstavuje lokální £asovou osu uzlu, p°esunutím posuvníku do jiné polohy se p°esune náhled také do odpovídajícího místa. Pomocnými ovládacími prvky jsou ²ipky
C.3.
UIVATELSKÁ PÍRUKA GRAFICKÉHO ROZHRANÍ PROGRAMU
41
(⇐) (⇒) pod posuvníkem, mají funkci posunu náhledu o jeden snímek vp°ed nebo zp¥t. P°i del²ím stisku t¥chto ovládacích prvk· se plynule p°ehrává uzel dop°edu nebo zp¥t. Textové pole mezi t¥mito dv¥ma prvky ozna£ují £as na lokální £asové ose.
42
DODATEK C.
UIVATELSKÁ PÍRUKA
Dodatek D
Popis API pro vytvá°ení modul· Tato kapitola popisuje aplika£ní rozhraní pro vytvá°ení nových modul· v²ech t°í druh·. K vytvo°ení modul· jsou vºdy pot°eba zdrojové kódy jádra programu.
D.1 Základní popis t°íd basenode.h Soubor obsahuje de nici základních t°íd pouºívaných v programu, jako jsou nap°íklad jednotlivé uzly. T°ída NodeStruct je virtuální t°ídou, která de nuje a deklaruje obecné funkce uzl·. Umoº¬uje z uzl· získávat a do uzl· vkládat p°edem de nované parametry, také se stará o chybové hlá²ení a správnou identi kaci uzl·. T°ída InputNode de nuje základní algoritmy pro vstupní a funk£ní uzly. T°ída OutputNode de nuje základní algoritmy pro výstupní uzly Pro bliº²í seznámení s obsahem t°íd je moºnost nahlédnout do p°iloºené dokumentace.
plugin.h Tento soubor obsahuje deklaraci t°ídy Plugin. T°ída Plugin deklaruje základní funkce a prom¥nné, které by m¥l obsahovat kaºdá p°ipojitelný modul. Z této t°ídy jsou odvozeny v²echny moduly.
identi cator.h Toto je mezivrstva mezi t°ídou Plugin a InputNode nebo Output. Je ji pot°eba k vytvo°ení identi kátoru, kdy je p°i na£tení vstup· vytvo°ena a £eká na své pouºití. P°i jejím pouºití v edita£ní £ásti se z tohoto identi kátoru teprve vytvo°í uzel a je p°ipojen do stromu. T°ída Identi kátor p°ijímá a rozpoznává v²echny vstupní a výstupní atributy. 43
44
DODATEK D.
POPIS API PRO VYTVÁENÍ MODUL
videoframe.h Struktura pro p°edávání obrazových snímk· a zvukových vzork· mezi jednotlivými uzly. T°ída obsahuje ukazatele na struktury nesoucí obrazovou nebo zvukovou informaci a dále také parametry p°edávaných dat. U obrazu to je informace o obrazovém formátu a jeho rozli²ení. Jako standardní formát obrazu je pouºíván formát RGB - 8 bit· na kaºdou sloºku barvy a pro uloºení zvuku je pouºit formát Sample_formát_S16, kde je pouºito 16 bit· na vzorek.
D.2 Vytvá°ení modul· Nebude zde popsán ve²kerý postup pro vytvá°ení modul·, ale jen základní funkce. Dobrým postupem je nechat se inspirovat jiº implementovanými p°íklady, nebo tyto p°íklady upravit. Kaºdý modul se skládá ze dvou aº t°í £ástí podle pouºití. T°ída pro dynamické p°ipojení modulu je pro v²echny moduly stejná. T°ída pro p°ipojení musí být potomkem t°ídy Plugin a musí mít v jejím konstruktoru de novány následující hodnoty: type keyword info version icon
= = = = =
FUNCTION_MODUL; "rotate"; "Plugin rotace"; "1"; rotateico_xpm;
// // // // // //
typ modulu klí£ové slovo modulu (uzlu) informa£ní °et¥zec °et¥zec verze modulu ukazatel na pole s ikonou 50x50 pixel· ve formátu XPM
type - ur£uje typ modulu, podle pouºití jsou moºné t°i varianty FUNCTION_MODUL, INPUT_MODUL, OUTPUT_MODUL icon - ukazatel na ikonu gra ckého rozhraní uzlu v GUI a nemusí být striktn¥ nastavena, formát ikony je XPM keyword - jednozna£n¥ identi kuje uzel a jeho klí£ové slovo info - informa£ní °et¥zec o pouºití uzlu version - verze modulu
Funkce getNode(NodeStruct∗ _parent) p°ijímá ukazatel na rodi£e nov¥ vytvá°eného uzlu a vrací ukazatel na nov¥ vytvo°ený objekt uzlu. Funkce pro vrácení identi kátoru, pouºívaná u vstupních a výstupních modul· se jmenuje getIdenti cator(). Obecn¥ je u v²ech uzl· de nována funkce init(), která se volá ve stromové struktu°e rekurzivn¥ p°ed prvním pouºitím uzl·. Pokud je pot°eba, tak tato funkce nastaví a inicializuje v²echny prom¥nné a prost°edky pro správnou funkci uzl·.
D.3.
FUNKNÍ MODUL
45
D.3 Funk£ní modul Nejjednodu²²í variantou modulu je funk£ní modul. Funk£ní modul musí obsahovat de nici dvou objekt·. Jeden objekt je d·leºitý ke správnému na£tení a identi kování modulu viz. D.2 prom¥nná type se musí nastavit na FUNCTION_MODUL. Druhý objekt bude p°edstavovat samotný funk£ní uzel, p°es který budou p°ímo procházet audiovizuální data, tento objekt musí být odvozen od t°ídy InputNode. V tomto novém objektu uzlu je t°eba de novat funkci putParam(int index,typ_prom¥nné hodnota). Tato funkce se volá p°i p°ekladu skriptu a jsou do ní p°edávány postupn¥ jednotlivé parametry, které jsou v sob¥ nesou krom¥ vlastní hodnoty i po°adí v seznamu parametr·. Tyto hodnoty mohou být jen základních typ·, pro obslouºení kaºdého typu existuje jedna funkce. Tou nejd·leºit¥j²í funkcí je getFrame(uint64_t noFrame,int noStream). Její parametry jsou: poºadovaný snímek a ur£ení stopy poºadovaného snímku. V této funkci si musí uzel získat od svých potomk· poºadovaná data (to lze provézt pomocí jiº p°edde nované funkce getStandardFrame(noFrame,noStream) ). Pak uº jen sta£í zm¥nit tato data podle vlastního algoritmu a poslat je nad°azenému uzlu jako návratovou hodnotu.
Vstupní moduly Vstupní moduly obsahují mezistupe¬ mezi t°ídou Plugin a InputNode. To je z d·vodu vytvo°ení tzv. identi kátoru, který p°i jeho pouºití teprve vytvo°í daný uzel. U t°ídy odvozené od t°ídy Plugin musí být nastavená prom¥nná type, kde její hodnota musí být nastavena na INPUT_MODUL. Objekt odvozený od t°ídy Identi kátor na£ítá vstupní atributy a p°i vytvá°ení nového uzlu je v²echny tomuto uzlu p°edá. V novém objetu uzlu musí být de nována funkce getFrame(uint64_t noFrame,int noStream). Ta má stejná parametry jako u funk£ního modulu, ale rozdíl je v tom, ºe neobsahuje ºádné potomky. Obrazové nebo zvukové data musí vytvá°et nebo dekódovat z n¥jakého vlastního zdroje.
Výstupní moduly Parametr type t°ídy, která je odvozena od t°ídy Plugin, by m¥l obsahovat hodnotu výstupního uzlu - OUTPUT_NODE. De nice objektu uzlu musí být odvozena od t°ídy OutputNode, kde jiº jsou deklarovány základní funkce pro výstupní uzly. Hlavní funkcí tohoto uzlu je funkce insertFrame(VFrame* frame, int streamID), první parametr obsahuje strukturu s daty a druhý parametr ur£uje do které výstupní stopy mají být tyto data zapsána. Funkce close() oznamuje uzlu konec dat a provedou se ukon£ovací algoritmy nad výstupními prost°edky.
D.4 Kompilace modul· P°i kompilaci modulu je pot°eba soubor kompilovat jako dynamickou knihovnu s parametrem -shared, aby bylo moºné p°ilinkovat knihovnu b¥hem b¥ºícího programu. Pokud bude pot°eba pouºívat v modulu n¥které knihovny, které se nepouºívají ve stávajícím programu, je pot°eba program znovu zkompilovat s p°idanými parametry této nové knihovny.
46
DODATEK D.
POPIS API PRO VYTVÁENÍ MODUL
Dodatek E
UML diagramy Diagramy zde uvedené, jsou vygenerovány pomocí programu Umbrello a popisují implementaci n¥kterých t°íd a jejich souvislostí.
Obrázek E.1: Hierarchie uzl· a jejich závislosti
47
48
DODATEK E.
UML DIAGRAMY
Obrázek E.2: Struktura syntaktického, lexikálního analyzátoru a jejich typ·
Obrázek E.3: UML diagram struktur pro funk£ní modul operace posunutí
49
Obrázek E.4: UML vstupního a výstupního modulu
50
DODATEK E.
UML DIAGRAMY
Dodatek F
Testovací script 1 Input{ AV test1{ path = "test1.mp4"; // Vstupní soubor } AV test2{ path = "test2.mp4"; // Vstupní soubor } } Output{ #2 screen { width = 352; height = 240; } #1,2,A1 mp4 { width = 352; height = 240; filename = "output1.mp4"; } } Main[2,1]{ group(){ fade(1,0,255,255,10,80){ #1 test1(00:00:10.00,00:00:20.00,1,1); #2 test2(00:00:10.00,00:00:20.00); } } grayscale(){ #1 test1(00:00:20.00,00:00:30.00,1,1); #2 test2(00:00:20.00,00:00:30.00); } group(){ group(){
51
52
DODATEK F.
rotate(0,0,360,100){ #1 test1(00:00:30.00,00:00:40.00,1,1); #2 test2(00:00:30.00,00:00:40.00); } translation(0,0,0,100,200,100){ #1 test1(00:00:40.00,00:00:50.00,1,1); #2 test2(00:00:40.00,00:00:50.00); }
}
}
} scale(1,1,0,200,200,100){ #1 test1(00:00:50.00,00:01:00.00,1,1); #2 test2(00:00:50.00,00:01:00.00); }
TESTOVACÍ SCRIPT 1
Dodatek G
Obsah p°iloºeného CD Bin |-- Vscript `-- VscriptGUI Dokumentace |-- Vscript `-- VscriptGUI Html |-- Abstract | `-- index.html |-- RabsrtAJ | `-- index.html `-- RabstrCZ `-- index.html Src |-- Vscript | `-- src `-- VscriptGUI `-- src Test |-- Test1 `-- Test2 Text index.html install.txt readme.txt
- binární soubory programu a knihoven - binární soubory grafického rozhraní - dokumentace k programu a knihovnám - dokumentace k programu GUI - krátký abstrakt - roz²í°ený abstrakt v angli£tin¥ - roz²í°ený abstrakt v £e²tin¥ - adresá° zdrojových kód· k programu - adresá° zdrojových kód· k programu GUI - testovací skript 1 a vstupní soubory - testovací skript 2 a vstupní soubory - výchozí stránka práce - postup instalace programu - popis rozloºení CD
53
