eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Serverová aplikace pro on-line st°ih videa
Jan Matou²ek
Vedoucí práce:
Ing. Roman Berka, Ph.D.
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Web a multimedia
5. £ervna 2009
iv
Pod¥kování Cht¥l bych pod¥kovat svému vedoucímu práce panu Ing. Romanu Berkovi, Ph.D. za vedení mé práce. Dále Klubu Sinkuleho a Dejvické koleje za poskytnutí dlouhodobého hostingu pro toto dílo a Radku Petrá¬ovi, za implementaci klientské aplikace navazující na tuto práci.
v
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 5. 6. 2009
.............................................................
Abstract This bachelor thesis is an implementation of the server part of an internet based non-linear video editor. The main goal was to produce a fully-functional application, that would include standard tools for video, image and audio editing. Based on this goal, that was successfully reached, there are several enhancing options discussed in the work. Upon these options another thesis can be made. The program itself is designed to provide application interface for various types of client applications in aim to serve as the nal render of user cuts and eects on uploaded user multimedia.
Abstrakt Bakalá°ská práce je implementací serverové £ásti nelineární internetové st°iºny videa. Hlavním cílem bylo vytvo°ení funk£ní aplikace, která by zahrnovala standardní nástroje pro práci s videem, obrazem a zvukem. Tento poºadavek byl spln¥n a na jeho základ¥ jsou v textu rozvedeny moºnosti roz²í°ení funk£nosti, na které lze navázat dal²í diplomou prací. Samotný program je navrºen tak, aby poskytoval aplika£ní rozhraní pro r·zné typy klientských aplikací a slouºil pro koncový render uºivatelsky vybraných st°ih· a efekt· na vstupních multimédiích p°edem odeslaných na server.
vi
Obsah 1
2
Úvod
1
1.1
Vymezení cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Analýza procesu st°íhání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.1
St°ih . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.2
Render . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.3
Cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Cílová skupina
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.5
Vybrané standardní funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Návrh aplikace
4
2.1
Vstupy a výstupy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
4
2.2
Problematika p°enosu dat a její °e²ení
. . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Redundantní p°enos
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Stream vs. Pole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
P°ehráva£ videa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
P°ehráva£ audia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.5
Výb¥r technologií . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5.1
9
2.5.2
3
Navrhovaná aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klient
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1.1
Flash
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5.1.2
Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.5.1.3
Java, C++ a jiné . . . . . . . . . . . . . . . . . . . . . . . . .
10
Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5.2.1
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5.2.2
Ruby, JSP, ASP a jiné . . . . . . . . . . . . . . . . . . . . . .
11
Implementace
12
3.1
Architektura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2
Komponenty aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.1
API
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
Kontroler
3.2.3
Model
3.2.4
Databáze
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.5
Render Kontroler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
12 12 12
viii
OBSAH
3.2.6
4
7
13
15
4.1
Volání funkcí
15
4.2
Vstupy a výstupy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2.1
Vstupní multimédia
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.2.2
Vstupní uºivatelská data . . . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.1
Vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.2.2
Stopa
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Výstupy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Testování 5.1
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aplika£ní rozhraní
4.2.3
5
Linuxový shell
17
Srovnání výkonnosti
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Návaznost na práci
18
6.1
Manipulace s audiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
6.2
Roz²í°ení efekt· a parametr·
18
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Záv¥r
19
7.1
Napln¥ní cíl·
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
7.2
Úvaha nad reálným vyuºitím
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
7.3
Záv¥r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
Literatura
20
8
UML diagramy
21
9
Instala£ní a uºivatelská p°íru£ka
24
9.1
9.2
Instalace a nastavení serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.1.1
Seznam balík· pot°ebných pro fungování serveru
24
9.1.2
Nastavení serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Výpis aplika£ního rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
10 Obsah p°iloºeného CD
. . . . . . . . . . . .
25
Kapitola 1
Úvod 1.1
Vymezení cíl·
Cílem práce je serverová £ást softwaru umoº¬ujícího manipulaci s uºivatelskými videosekvencemi. Aplikace by m¥la být schopná nahrát soubor, vygenerovat náhledy pro pot°ebu uºivatele, manipulovat se stopami audia a videa ve vrstvách a vyrenderovat parametrizované výsledné video ke staºení. Klientská aplikace, která by tuto funkcionalitu uºivateli zprost°edkovala není sou£ástí práce, kv·li testovacím ú£el·m je v²ak ve velmi omezené mí°e implementována. Plnohodnotnou klientskou aplikaci vyuºívající pln¥ potenciál on-line st°ihu z webového prohlíºe£e napsal student VUT oboru STM Radek Petrᬠtaké jako bakalá°skou práci u pana Ing. Romana Berky, Ph.D. v roce 2009. Díky této aplikaci byly do serveru zaimplementovány funkce, které je²t¥ lépe °e²í problematiku on-line st°ihu. Tyto funkce jsou popsány v kapitole 2 Práce voln¥ navazuje na semestrální projekt p°edm¥tu Y36MM1 z roku 2008 s názvem St°ih videa online (auto°i Radek Petrá¬, Jan Matou²ek, Radek Jedli£ka, Petr Hu£ík). Výsledky a zku²enost z projektu umoº¬ují optimální volbu technologie a lep²í °e²ení problematiky.
1.2 1.2.1
Analýza procesu st°íhání St°ih
St°ih videa se skládá z £ásti, kdy uºivatel probírá jednotlivá multimédia, která chce do projektu za°adit, vybírá správné £ásti, odst°ihne zbytek, aplikuje efekt a vkládá je výsledné kompilace. V této £ásti není manipulováno s binárními daty multimédií. Generují se pouze aktuální náhledy, aby uºivatel vid¥l kam pozicuje titulky, nebo jak vypadá barevná úprava videa.
1
KAPITOLA 1.
1.2.2
ÚVOD
2
Render
Ve chvíli, kdy je uºivatel s projektem hotov, aplikuje vybrané textov¥ reprezentované kon gurace na skute£ná data. Spustí se render nového nálního videa, které si uºivatel následn¥ nap°íklad vypálí na DVD.
1.2.3
Cíl
Drtivá v¥t²ina amatérských volných i komer£ních aplikací, se jako celek instalují na klientskou stanici a fungují na vý²e zmín¥ném principu. Cílem této práce je p°esun renderov¥ orientované £ásti na vzdálený server za ú£elem opro²t¥ní od nutnosti instalace náro£ného softwaru.
1.3
Motivace
Vzhledem k aktuálnímu nárustu mobilních za°ízení schopných natá£et amatérské video sekvence publikovatelné na internetových portálech (YouTube, GoogleVideo, ...) roste pot°eba uºivatel· takové sekvence zpracovat do prezenta£ní podoby, obohatit je o hudbu, textový popis, p°ípadn¥ primitivní efekty (p°echod, atd). V¥t²ina takových za°ízení (mobilní telefon, DV kamera) sice ob£as p°ichází se softwarem na zpracování videa, takový software má ale mnohá omezení mezi n¥º pat°í:
•
nutnost neztratit instalátor
•
nutnost instalace p°i kaºdé p°einstalaci opera£ního systému
•
²patná implementace softwaru (odpovídající cen¥ telefonu/kamery)
•
chyb¥jící £eský p°eklad
•
výpo£etní kapacita uºivatelského po£íta£e nemusí být dosta£ující
N¥která za°ízení nejsou vybavena softwarem pro zpracování videa v·bec, v takovém p°ípad¥ si uºivatel m·ºe zakoupit poloprofesionální °e²ení mnohonásobn¥ p°evy²ující cenu jeho za°ízení, m·ºe si stáhnout open sourcovou aplikaci v¥t²inou nep°íli² intuitivn¥ navrºenou, dále se m·ºe se smí°it s videem v takovém stavu v jakém je a nebo se v nejhor²ím p°ípad¥ pokusí sehnat nelegální kopii poloprofesionálního softwaru. Vzhledem k t¥mto nedostatk·m a neustálému navy²ování p°enosových rychlostí internetových p°ípojek, je moºné nabídnout uºivatel·m komfortn¥j²í °e²ení v podob¥ online st°iºny.
Výhody online °e²ení
•
odpadá pot°eba instalace
•
odpadá pot°eba výpo£etního výkonu
•
uºivatel má stejná data k dispozici na r·zných po£íta£ích
•
stálá aktualizace softwaru, pouze jedna instance, ºádné balí£ky updat·
KAPITOLA 1.
ÚVOD
3
Nevýhody online °e²ení
•
náro£nost na p°enosovou kapacitu internetového p°ipojení uºivatele
•
technologická díra v sou£asných multimediálních moºnostech
•
výpo£etní kapacitu musí poskytnout server
•
výpo£etní kapacity osobních po£íta£· rostou stejn¥ tak jako p°enosové kapacity linek
1.4
Cílová skupina
Jak jiº z vý²e uvedených zmínek vyplývá, cílovou skupinou jsou amatér²tí uºivatelé, vlastníci mobilních za°ízení umoº¬ujících nahrávání neprofesionálních videosekvencí. Dále uºivatelé domácích digitálních kamer nespokojení se svým softwarem. Cílová skupina je velmi obsáhlá a proto by tato aplikace m¥la mít velkou ²anci na úsp¥ch v komer£ním vyuºití. Profesionální tv·rci videa o sluºbu nemohou mít zájem z n¥kolika d·vod·:
•
server-klient orientované profesionální st°iºny jiº existují
•
zam¥°ení této práce na men²í formáty z d·vodu p°enosu p°es Internet
•
minimální mnoºství efekt· a funkcí implementovaných v této práci
1.5
Vybrané standardní funkce
Po srovnání n¥kolika nejznám¥j²ích softwar· pro st°ih videa (Sony Vegas, Adobe Premiere, Kino, Cinerrela) by m¥la tato práce implementovat tento seznam standardních funkcí
•
vloºení digitáln¥ uloºeného multimédia do projektu
•
zmen²ený náhled videí v projektu
•
výb¥r £ásti audia/videa a vloºení do projektu
•
práce s vrstvami audia a videa
•
práce s opacitou vrstvy a stopy videa
•
práce s hlasitostí vrstvy a stopy audia
•
vkládání parametrizovaného textu
•
vkládáná barevných ltr·
•
vkládáná statických obrázk·
•
manipulace s velikostí a pozicí videa v projektu (video ve videu)
•
p°ípadná dynamizace t¥chto parametr· v £ase
Z d·vodu, ºe tato práce je uloºena na serveru, není moºné implementovat nahrávání videa uloºeného na páskových za°ízeních. Tuto funkcionalitu mohou dodat aº klientské aplikace.
Kapitola 2
Návrh aplikace 2.1
Vstupy a výstupy
Aby mohla aplikace spl¬ovat poºadavky vý²e uvedené v kapitole 1.5, je pot°eba zajistit pot°ebné vstupy, aby z nich byly vytvo°eny poºadované výstupy. Vstupními informacemi jsou uºivatelská multimédia a uºivatelem poºadované operace, výstupními pak výsledné video ke staºení. Aby bylo zachováno poºadované rozloºení celé aplikace na komponenty klient a server a bylo tedy umoºn¥no st°íhání po Internetu, m¥l by server implementovat aplika£ní rozhraní, které od klientských aplikací dostává jako vstupy textov¥ reprezentované p°íkazy s parametry a multimediální soubory, které p°ijme celé, aby na nich mohl poºadované p°íkazy provád¥t. Výstupy pak server dá k dispozici klientské aplikaci. Výstupy mohou mít formu textovou, pak je odpov¥¤ klientovi zaslána okamºit¥ v requestu, nebo formu multimediální a pak jsou b¥hem ur£ité doby vygenerovány pat°i£né soubory, které jsou klientovi p°ístupné na dané adrese.
2.1.1
Navrhovaná aplikace
Aplikace by tedy m¥la um¥t p°ijímat multimediální soubory a um¥t je zpracovat podle p°íkaz·. Klí£ovými body jsou proto výb¥r technologie pro komunikaci p°es Internet, výb¥r softwaru pro práci nad soubory s audio, video a obrázkovým obsahem. Schéma takového zpracování je na obrázku 2.1. Program pro komunikaci p°es Internet je vybrán jiº v samotném zadání této práce a je ním webový server a to z d·vodu, ºe v¥t²ina Internetových sluºeb je na práv¥ na tomto principu zaloºena.
Klí£ové funkce:
•
detekce formátu binárního souboru, detekce audio a video stop, detekce vlastností
•
konverze audia do náhledového formátu
•
konverze videa do obrázk· a náhledového formátu
•
manipulace s obrázky a ltry
4
KAPITOLA 2.
NÁVRH APLIKACE
•
manipulace se zvukem a ltry
•
konverze obrázk· a audiostop do výsledného video kontejneru
•
parsování klientských request·
•
univerzání formát pro získávání dat o souborech ze serveru
Obrázek 2.1: Schéma zpracování vstup·
5
KAPITOLA 2.
2.2
NÁVRH APLIKACE
6
Problematika p°enosu dat a její °e²ení
2.2.1
Redundantní p°enos
Z d·vodu maximálního vyuºití výhod a potla£ení nevýhod plynoucích z umíst¥ní render serveru v Internetu, kdy musí uºivatel odesílat v²echna svá multimédia pry£ a pak si stahovat náhledy a koncové vyrenderované video zpátky k sob¥, je d·leºité zvolit správné technologie a omezit v maximální mí°e redundantní komunikaci se serverem.
P°i ²patn¥ zvolené technologii
•
klientská aplikace (dále jen klient) ode²le videa, audio, obrázky na server
•
server vygeneruje velmi malý streamový formát pro náhled audia a videa
•
klient si otev°e stream kanál a na£te si celé video
•
uºivatel se rozhodne vyst°ihnou n¥kolik sekund uprost°ed videa
•
server p°ijme poºadavek na vyst°iºení kusu videa, vyrendruje video podle poºadavku a ud¥lá nový stream videonáhledu (uºivatel £eká)
•
klient si otev°e stream kanál a znova na£te celé video (uºivatel £eká)
P°i správn¥ zvolené technologii
•
klientská aplikace (dále jen klient) ode²le videa, audio, obrázky na server
•
server vygeneruje velmi malý nestreamový formát pro náhled audia a videa, který po²le klientovi zp¥t
•
klient provádí na tomto náhledu elementární triky pro vytvo°ení dojmu skute£ného efektu p°ímo v uºivatelském pc (díky malému formátu lze triky provád¥t v reálném £ase bez velké zát¥ºe uºivatelského pc)
•
uºivatel st°íhá, ale klient si ukládá pouze sou°adnice, hodnoty, klí£e a zobrazuje
•
uºivatel se rozhodne vyst°ihnout kus videa, klient mu p°ehraje jiº na£tené video bez poºadovaného kusu
•
uºivatel se rozhodne pro render a klient ode²le na server nasbírané hodnoty
•
server vygeneruje z p°ijatých klí£· a hodnot výsledné video
•
uºivatel si výsledné video stáhne k sob¥
Z uvedených p°íklad· moºných °e²ení vyplývá nutnost provád¥t co nejv¥t²í mnoºství úprav p°ímo v klientské aplikaci, aby se zabránilo prodlevám kv·li redundantnímu stahování stejných dat znova a znova.
KAPITOLA 2.
2.2.2
NÁVRH APLIKACE
7
Stream vs. Pole
e²ením tohoto redundantního problému je p°enos náhled· jako pole. Ve²keré technologie, které jsou dnes k dispozici p°ená²í video pouze jako stream, který má n¥kolik neºádoucích vlastností práv¥ pro st°ih videa a to:
•
b¥hem p°enosu streamovaného videa m·ºe docházet k po²kození aº ztrát¥ jednotlivých snímk· (tato nevýhoda plyne z faktu, ºe stream se p°ená²í protokolem UDP[8], jeº nezaru£uje p°ijetí v²ech packet· a jejich správné po°adí)
•
streamované video pot°ebuje speciální knihovy pro zpracování jednotlivých snímk·
Proto jsme se s kolegou Petrán¥m rozhodli pro náhled videa pouºít experimentální technologii Javascriptového p°ehráva£e zaloºeného na principu p°enosu obrázk· protokolem TCP (£ímº je zaru£eno 100% doru£ení v²ech obrázk· a ve správném po°adí.) Poté se p°ijaté pole obrázk· pustí podle p°edem ur£eného mnoºství snímk· za sekundu a je tak docíleno efektu videa. Nejsou pot°eba ºádné knihovny pro dekódování videa nebo pro extrahování aktuálního snímku.
2.3
P°ehráva£ videa
Následující text popisuje princip p°ehrávání náhledu videa vygenerovaného na serveru. Tento princip je vyuºíván v klientské aplikaci naprogramované kolegou Petrán¥m. A£koliv se jedná p°eváºn¥ o klientskou £ást, na zvoleném principu p°ehrávání náhledového videa je postavena velká £ást celé aplikace a vyºaduje po serveru vygenerování daného náhledu. P°ehrávání videa funguje jako vým¥na obrázk· v HTML elementu n¥kolikrát za sekundu. Celý postup je následující:
•
uºivatel nahraje video na server HTML uploadem
•
server z videa vygeneruje obrázky v malém p°edem nastavitelném rozli²ení nap°. 160 x 120 px s velmi nízkou kvalitou ve formátu JPEG
•
tyto obrázky binárn¥ p°evede do textové formy pomocí knihovny base64
•
tyto stringové °et¥zce uloºí do textového souboru s aditivními informacemi jako po£et snímk· za sekundu, rozli²ení, atd.
•
následn¥ si textový soubor klientská aplikace stáhne do prohlíºe£e pomocí AJAX technologie
•
díky vlastnosti webových prohlíºe£· zobrazit obrázky ve form¥ base64, je moºné zobrazit libovolný obrázek bez nutnosti dekódovat obrázek zp¥t do binární podoby
•
pomocí javascriptu se postupn¥ v²echny tyto zakódované obrázky zobrazí v daném mnoºství za sekundu a vytvo°í tak dojem videa
KAPITOLA 2.
8
NÁVRH APLIKACE
Tato hackerská nta
1 pro p°ehrávání má klí£ový d·sledek, umoº¬ující velmi efektivn¥
pracovat s videem p°ímo v okn¥ klienta bez nutnosti kontaktovat server. Pomocí Javascriptu m·ºe uºivatel v reálném £ase vymazat z pole libovolné £ásti, zkopírovat sekvence obrázk·, adresovat konkrétní obrázky p°ímo pomocí klí£e. Tímto odpadá jakákoliv pot°eba dekódovat video p°ímo u klienta. Dále odpadá i pot°eba provád¥t v reálném £ase úpravy obrázk·, které by také vyºadovaly speciální knihovny. V¥t²ina efekt· lze totiº nasimulovat p°ímo pomocí manipulace Javascriptu s DOMem. Nap°íklad vloºení titulk· znamená vytvo°ení nové vrstvy nad p°ehrávaným videem s poºadovaným textem. Práci s opacitou integruje Javascript také.
2.4
P°ehráva£ audia
Díky objevu hackerského p°ehrávání obrázk· p°ímo v prohlíºe£i nás napadla my²lenka p°ehrát audio úpln¥ stejn¥ a vyuºít tak bene t· pole také pro audio. Bohuºel po mnohadenním vývoji se mi stejného efektu nepoda°ilo dosáhnout, ne v²ak z d·vodu ne°e²itelnosti problému, ale z d·vodu jeho rozsahu. Problém vyºaduje d·kladný pr·zkum a testování. Proto z·stává náhled audia pro uºivatele nevy°e²en a otvírá tak moºnost navázat na tuto práci p°ípadnou dal²í diplomovou prací. D·vodem pro£ se nepoda°ilo implementovat náhledy a práci s audiem stejn¥ jako s videem je ten, ºe ºádný webový prohlíºe£ sám o sob¥ nedokáºe p°ehrát komprimovanou zvukovou stopu. Jedinou implementaci nabízí Internet Explorer, bohuºel pouze pro zvuk ve formátu MIDI, který je ze své podstaty tém¥° nepouºitelný.
2
Tento problém je moºné obejít pomocí vyuºití pluginu Flashe a to pouze pro p°ehrátí oné komprimované stopy. Tato cesta se vyuºívá velmi b¥ºn¥, prakticky ve²kerá hudba na Internetu se p°ehrává mini ashovým p°ehráva£em umíst¥ným na serveru, který se umístí do stránky jako EMBED element a ovládá se nap°íklad pomocí Javascriptu. Bohuºel ani toto není °e²ením pro ná² poºadavek, protoºe Flash bere za vstup audia stream, jehoº nevýhody jsou uvedeny vý²e. Ideálním poºadavkem je totiº situace, kdy si Javascript stáhne protokolem TCP kompletní pole string·, které reprezentují zakódované kousky binárního audia pomocí base64. A postupn¥ si potom tyto stringy p°ehraje (nap°íklad 1 string = 1 sekunda audia), coº umoºní nejen regulaci hlasitosti pro r·zné £ásti audio stopy, ale také p°ehrávání úsek· audia ve smy£ce atd. Problém se nachází v technologii Flash, která umoº¬uje p°ehrát audio pouze na vzdáleném serveru p°es UDP protokol a ºádá si od Javascriptu pouze adresu ke vzdálenému audiu, nikoliv samotná binární data uº lokáln¥ v rámci prohlíºe£e. Dále existují dv¥ moºnosti. Bu¤to rozsekat po sekund¥ audio na serveru a p°ehrávat jej jako pole adres vzdálen¥ (umoº¬uje stejné efekty jako by umoº¬ovalo p°ehrávání base64 string· lokáln¥), coº není nejhor²í °e²ení, ale jeho nevýhodou je ²patn¥ ovladatelné cachování t¥chto vzdálených kousk· audia a nutnost jiného p°ístupu k problematice.
autorem je Jacob Seidelin, vystavuje celý £lánek popisující tento nápad v£etn¥ príklad· na svém blogu [6], kde jako vyuºití této technologie uvádí javascriptové hry. 2 Teoretická ²ance pouºití na stejném principu jako u p°ehráva£e obrázk· existuje, uvádí ji na svém blogu John Reisig [5], stejným zp·sobem posílá stringové MIDI do javascriptu. Toto je v²ak stále omezeno pouze pro Internet Explorer a samotnou podstatnou MIDI formátu. 1
KAPITOLA 2.
9
NÁVRH APLIKACE
Druhou moºnost poskytuje nová verze technologie Flash 10, která umoº¬uje p°ehrávat lokální audio stopy a to ve formátu MP3, u kterých nov¥ zavádí metodu extract()[1], která poskytuje práci p°ímo s £íselnou reprezentací audio stopy a její modi kaci p°ímo u klienta nap°. zrychlení, zpomalení, generování zvuk· atd.. Toto je ideální pro my²lenku p°edání nacachovaných binárních dat Javascriptem p°ímo do ashového p°ehráva£e. Toto °e²ení je tedy moºné, má v²ak jednu nevýhodu. Tou je formát vstupních dat, které musí být striktn¥ reprezentované jako 32-bit Float se samplovací frekvenci 44,1 kHz a ne námi o£ekáváný vysoce komprimovaný formát Mp3, který poskytuje n¥kolikanásobn¥ vy²²í kompresní pom¥r. (aº 60MB vs 3MB). Bylo by také moºné opustit my²lenku generování a stahování audio náhledu na serveru a otev°ít pomocí Flashe 10 lokální zvuk a pracovat s ním p°ímo u klienta a nakonec jej odeslat na server s konkrétními klí£i pro render. Tento velmi slibný nápad bohuºel dokáºe zpracovat pouze lokální hudbu, nikoliv audio v libovolném formátu uloºené jako sou£ást videa. Zde kon£í výzkum, který jsem provád¥l s audiem a otvírá tak moºnost pro návaznou práci, která by se zam¥°ila práv¥ na optimální vy°e²ení tohoto problému.
2.5
Výb¥r technologií
2.5.1
Klient
Díky aplika£nímu rozhraní serveru, m·ºe existovat mnoºství r·zných klientských aplikací napsaných v r·zných technologiích. Dá se v²ak p°edpokládat, ºe kaºdá klientská aplikace bude o£ekávat ur£itý výstup serveru nap°íklad náhled· vloºeného videa
3 a tato funkcionalita
se proto bude muset pro v¥t²inu klientských aplikací dod¥lávat. Pro úplnost uvádím jazyky a technologie, ve kterých lze takové klientské aplikace napsat.
2.5.1.1
Flash
Flash je multimediáln¥ zam¥°ená proprietární technologie spole£nosti Adobe, která poskytuje mnoºství knihoven pro práci s videem, audiem a obrazem. Díky zku²enosti z vý²e zmín¥ného semestrálního projektu, na n¥º tato práce voln¥ navazuje, se ukázalo, ºe klientská aplikace naprogramovaná £ist¥ v tomto jazyce není úpln¥ dobrá z následujících d·vod·.
Nevýhody
•
komplikace udrºet stav aplikace p°i stisknutí refresh, zp¥t a vp°ed
•
nekompatibilita jednotlivých verzí pluginu Flash zp·sobující zamrzání a padání webového prohlíºe£e
•
zam¥°ení technologie Flash spí²e na streamovaná multimedia neº na moºnosti jejich editace
•
je vyºadován Flash plugin v prohlíºe£i
3 klienská aplikace kolegy Petrá¬e bere za vstup textové soubory s base64 textovou reprezentací t¥chto náhled·, jiná klientská aplikace m·ºe o£ekávat za vstup streamované ashvideo o ur£itém rozli²ení
KAPITOLA 2.
10
NÁVRH APLIKACE
4
•
p°enos audia/videa pouze jako UDP stream s rizikem ztrátovosti
•
proprietární technologie
•
programátorsky nep°átelské a nestabilní vývojové prost°edí bez alternativ
Výhody
•
integruje jak audio, tak video p°ehráva£
•
poskytuje velké mnoºství multimediáln¥ zam¥°ených knihovnen
2.5.1.2
Javascript
A£koliv nepodporuje p°ehrávání multimedií, poskytuje homogenní prost°edí pro práci s html elementy coº z velké £ásti nahrazuje poºadavek p°ehrávání videa, výhodn¥ jej lze kombinovat s funkcemi Flashe.
Nevýhody
•
neimplemetnuje ani audio ani video p°ehráva£, vyºaduje Flash plugin
•
omezená funkcionalita v prastarých prohlíºe£ích
Výhody
•
obrovské mnoºství svobodných knihoven, umoº¬ujících snadnout roz²i°itelnost
•
p°enos audia/videa p°es TCP jako pole dat bezeztrátov¥
•
implementován ve v²ech gra ckých prohlíºe£ích
2.5.1.3
Java, C++ a jiné
Dal²í moºností je napsat plnohodnou desktopovou aplikaci, která nebude vyuºívat webový prohlíºe£, v jazyce Java, nebo C++. Takové aplikace v²ak vyºadují mnohem v¥t²í úsilí a jsou £asov¥ náro£n¥j²í.
Nevýhody
•
vyºadují staºení binárního souboru z Internetu a jeho instalaci
•
£asov¥ náro£n¥j²í na napsání
•
vyºadují mnoºství knihoven
Výhody
•
homogenní programátorské prost°edí
•
moºnost ukládat data na disk uºivatele
•
moºnost provád¥t sloºit¥j²í efekty p°ímo na obrázcích, které jiº nelze simulovat trikem, bez kontaktování serveru
4
vyplývá z implementa£ních vlastností protokolu UDP[8]
KAPITOLA 2.
2.5.2
11
NÁVRH APLIKACE
Server
Serverovou £ást aplikace lze naprogramovat n¥kolika r·znými zp·soby v mnoha technologiích. Je moºné napsat si vlastní knihovny pro práci p°ímo s videem nebo obrázky, nebo zvolit jiº existující otev°ené knihovny a programy. Tvorba vlastních by byla velmi neefektivní a kopírovala by jiº osv¥d£ené vylad¥né profesionální programy. Proto je d·leºitý pr·zkum na poli svobodného softwaru. Jako nejlep²í °e²ení je pouºít server s linuxovou distribucí poskytující dostate£né softwarové zázemí v repozitá°ích pro práci s multimédii, narozdíl od Windows, které neposkytují prakticky ºádný software, který by se pro server hodil. Mezi klí£ové poºadavky pro výb¥r program· na zpracovávání audia, videa a obrázk· pat°ily nutnost konzolového rozhraní, licence programu, rozsah dokumentace, schopnost programu a po£et funkcí. Po pr·zkumu existujících program· jsem vybral:
•
pro zpracování audia program
SoX (Sound Exchange)[7],
který je ve zpracování
audia v konzoli zcela bezkonkuren£í ve v²ech poºadavcích
•
pro zpracování obrázk· program
ImageMagick[4],
který také nemá ve sv¥t¥ open
source konkurenci
•
pro zpracování videa program
FFMpeg[2],
star²í, mohutn¥j²í a schopn¥j²í obdoba
který se pro tuto práci hodí víc, neº jeho
MEncoder.
Je to proto, ºe se v kone£ném d·-
sledku serverová aplikace nezabývá aº tolik videem, jako spí²e prací s obrázky a audiem. Pro samotnou webovou aplikaci, která se bude starat o skriptování na webovém serveru a volat tyto vybrané programy je moºné pouºít technologie JSP, PHP, Ruby, ASP,... Tyto moºnosti jsou tém¥° ekvivalentní a dá se rozhodnout i podle osobní preference programátora. Já osobn¥ jsem preferuji jazyk PHP, který mi dovolí se více v¥novat výzkumu neº preciznosti kódu.
2.5.2.1
PHP
PHP má mnoho výhod pro výzkum v této oblasti, neumí v²ak manipulovat s vlákny. V okamºiku, kdy klientská aplikace vloºí multimediální soubor na server a dojde ke spu²t¥ní externího programu (nap°íklad SoX), který m·ºe soubor zpracovávat i n¥kolik hodin, nedojde k ukon£ení PHP skriptu a tudíº ani k ukon£ení HTTP poºadavku klienta. PHP skript b¥ºí, dokud nedob¥hne samotná aplikace a pak aº poºadavek ukon£í. To je velmi neºádoucí pro uºivatele, který by musel vy£kávat neº se kompletn¥ zpracují v²echny soubory. e²ení tohoto problému je popsáno v kapitole 3.2.
2.5.2.2
Ruby, JSP, ASP a jiné
Server by bylo moºné napsat i v t¥chto technologiích, které mají nepochybn¥ také mnoho p°edností a nevýhod jako je nap°íklad kódovací standard, p°ípadná omezení funk£nosti na linuxovém serveru. Tato variabilita je dána vyrovnanou technickou vysp¥lostí t¥chto jazyk· a také tím, ºe v¥t²ina kódu se provádí p°ímo v linuxovém shellu a není pot°eba tolik multimediálních knihoven.
Kapitola 3
Implementace 3.1
Architektura aplikace
Architektura serverové aplikace je naprogramována v návrhovém vzoru MVC (model-viewcontroller), který je typický pro webové aplikace. Model je reprezentován databázovými objekty a objekty pro práci s multimédii, controller se stará o chod celé aplikace podle volání API p°íkaz·. Vrstva View je reprezentována pouze ²ablonami k otestování naprogramované funkcionality, jinak se nachází aº v klientské aplikaci. Kaºdá klientská aplikace pot°ebuje sv·j vlastní model-view-controller pro simulaci efekt· na náhledovém videu a komunikaci s aplika£ním rozhraním serveru. Obrázek 3.1 zobrazuje schéma komunikace Render serveru, s jiº zmín¥nou klientskou aplikací napsanou Radkem Petrá¬em a zobrazuje i moºnost jiné desktopové aplikace napsané nap°íklad v Jav¥, nebo C++. Zárove¬ zobrazuje architekturu obou aplikací.
3.2 3.2.1
Komponenty aplikace API
Aplika£ní rozhraní serveru je sbírka procedur a funkcí, kterými se lze na server dotazovat a vykonávat tak poºadované funkce.
3.2.2
Kontroler
Kontroler se stará o chod celého programu, zpracovává volání API funkcí a pomocí t°íd modelu vytvá°í odpov¥¤ pro klientské aplikace.
3.2.3
Model
Poskytuje v t°ídách zapouzd°ené funkce pro zpracování informací a dat, konkrétní hodnoty ukládá v databázi.
12
KAPITOLA 3.
3.2.4
IMPLEMENTACE
13
Databáze
Slouºí pro uloºení dat z modelu, zárove¬ také pro vým¥nu informací mezi Kontrolerem a Render Kontrolerem.
3.2.5
Render Kontroler
Spou²tí se na pozadí po zpracování poºadavku od klienta za ú£elem co nejrychlej²ího ukon£ení HTTP spojení. P°i dlouhém zpracování multimédia by totiº klient musel zbyte£n¥ £ekat aº n¥kolik hodin.
3.2.6
Linuxový shell
Slouºí pro volání externích program· pro zpracovávání multimédií. Vykonává p°íkazy nakon gurované Kontrolerem ze vstupních uºivatelských dat, procesy jsou ovládány ve správném po°adí Render Kontrolerem, který se stará o jejich management, zárove¬ p°edává p°es databázi informace Kontroleru o jejich stavu.
KAPITOLA 3.
IMPLEMENTACE
Obrázek 3.1: Architektura aplikace
14
Kapitola 4
Aplika£ní rozhraní 4.1
Volání funkcí
Aplikace je postavena na webovém protokolu HTTP[3], tento protokol funguje na základ¥ request· (volání) n¥kolika typ·, z £ehoº nejb¥ºn¥j²í jsou POST a GET, pomocí nich je tedy moºné se dotazovat na server. Requestem GET se stahují informace ze serveru a zadává se ve form¥ URL nap°.
http://example.com/file/list Requestem POST se posílají data na server, má v²ak více £ástí £ást datovou a druhou £ástí je request GET. Klasickým p°íkladem POSTu je HTML formulá°. Datová £ást je pole a GET je op¥t URL. nap°.
http://example.com/file/insert array( ['srcod'] => 15, ['length'] => 20 ); P°edávání dat jako odpov¥¤ na request GET je vy°e²eno funkcí
json_encode();
tato
funkce bere za parametr pole, které p°evede do stringu a to celé se klientovi po²le funkcí
echo(); . Klient pak staºené pole ve form¥ strigu p°evede zp¥t do pole funkcí json_decode(); a zpracuje podle pot°eby.
4.2 4.2.1
Vstupy a výstupy Vstupní multimédia
Uºivatelská média jsou v r·zných formátech v r·zných kvalitách a je nutné je p°evést do formát· vhodných pro zpracování na serveru. Princip fungování st°iºny je takový, ºe vstupní video se p°evede na obrázky ve formátu JPEG v p°edem nastaveném výsledném rozli²ení.
15
KAPITOLA 4.
APLIKANÍ ROZHRANÍ
16
Vstupní audio se p°evede na WAV s p°edem nastavenou vzorkovací frekvencí. Vstupní obrázky se resamplují na nastavené rozli²ení do formátu PNG/JPEG (podle pr·hlednosti) a ze vstupního textu se vygenerují PNG obrázky s pr·hledným pozadím. Takto uni kovaná homogenní data se pak podle uºivatelského schématu nakopírují do projektového adresá°e. Nejprve je adresá° vypln¥n podkladovou barvou (£erné obrázky) v mnoºství výsledné délky renderu, pak jsou tyto obrázky bu¤to nahrazeny obrázky z poºadované video sekvence, nebo jsou spojeny s pr·hledným obrázky s textem. Tato operace se opakuje podle vrstev které si uºivatel p°idal do projektu. Audio je zpracováno velmi podobn¥, nejprve se vygeneruje podkladové ticho o délce výsledného renderu. Pak se z uni kovaného WAV audia okopíruje uºivatelem vybraný kus a tento kus se vloºí postupn¥ do ticha. Aº na konec vznikne jeden audio soubor.
4.2.2
Vstupní uºivatelská data
Uºivatel p°i st°íhání videa vybírá jen klí£ové hodnoty, podle kterých se st°íhá na serveru výsledné video, tyto hodnoty jsou následující.
4.2.2.1
Vrstva
Kaºdá vrstva je typu audio, nebo video, má ur£itou globální opacitu/hlasitost pro v²echny stopy do ní p°i°azené a po°adí ve kterém se aplikují stopy ve výsledném renderu.
4.2.2.2
Stopa
Do kaºdé vrstvy je moºné vloºit libovolné mnoºství stop z projektových multimédií. Kaºdá stopa má sv·j po£átek ve zdrojovém médiu (nap°. od 30. sekundy), svoji délku (nap°. 10 sekund), a po£átek v cílové vrstv¥ (nap°. od 80. sekundy). Dále pokud se jedná o video, obrázek nebo text, tak má svoji opacitu, jejíº 100% je opacita nastavená pro rodi£ovskou vrstvu, procentuelní vý²ku, ²í°ku, pozici a fade-in (p°echod z £erné do obrazu) a fade-out (p°echod obrazu do £erné) v sekundách. Pokud se jedná o audio, p°edstavuje opacita hlasitost a pozice a rozm¥ry nehrají roli. Pokud se jedná o text, nastavuje se navíc barva.
4.2.3
Výstupy
Posledním krokem zpracování projektu je vygenerování renderu pomocí programu FFMpeg, který bere za zdroj videa adresá° s obrázky, s parametrem po£et snímk· za sekundu, za zdroj audia výsledný audio soubor a toto celé vyrenderuje v uºivatelem zvoleném bitratu a formátu a poskytne uºivateli ke staºení.
Kapitola 5
Testování 5.1
Srovnání výkonnosti
Testována byla rychlost renderování identických projekt· v komere£ním studiu Sonic Foundry Vegas 3.0 a testovacím rozhraní serverové aplikace. Testovaným projektem byla 20 sekundová videostopa se 3 vrstvami za t¥chto podmínek.
•
Vrchní video vrstva byl text s 50% opacitou
•
Pod ní byla klasická video vrstva amatérského videa
•
Poslední vrstva byl zvuk amatérského videa
•
Vstupním formátem bylo video MPEG-2 s bitratem 1150kbps, rozli²ení 320x240 a audiem MP3 224kbps se samplovací frekvencí 44,1kHz stereo.
•
Výstupním formátem byl MPEG-4 s bitratem 2000kbps, rozli²ením 640x480 a audiem MP3 192kbps se samplovací frekvencí 44,1kHz stereo.
Výsledné rendery skon£ily v pom¥ru 1:6 na stejné výpo£etní kapacit¥ (notebook core duo 2GHz). Vegas vyrenderoval video za 30 sekund, jádro serverové aplikace za 3 minuty. Pro výpo£etní výkon serverové aplikace se v²ak dá p°edpokládat server, £i serverová farma o n¥kolikanásobn¥ v¥t²í výpo£etní kapacit¥. Dále jádro serverové aplikace není dosud optimalizované pro výkon a dá proto odhadovat zrychlení na stejné výpo£etní kapacit¥ aº k pom¥ru 1:3.
1
1 V sou£asné dob¥ není implementována funkce, která by namísto spojování obrázk· s obrázky o vrstvu níºe, jejichº výsledná podoba není ºádným efektem pozm¥n¥na v·£i originálu, tyto obrázky pouze zkopírovala. Samotné kopírování pak v·£i resamplování nevyºaduje tém¥° ºádný výkon.
17
Kapitola 6
Návaznost na práci 6.1
Manipulace s audiem
Jak jiº bylo zmín¥no, nepoda°ilo se dosáhnout stejného principu p°enosu audio vzork· v poli do klientské aplikace, kde by se k nim dalo p°istupovat podobn¥, jako k vzork·m videa v reprezentovaných obrázky v textové form¥. Jednou z moºností by mohl být p°enos audia pro p°ímé vloºení £íselné reprezentace zvuku do Flashe 10. Dal²í moºností by mohlo být zjednodu²ení audia a jeho p°evod do MIDI, které by p°ehrával samotný prohlíºe£ a nebo ponechat audio jako stream a zapracovat do ashového p°ehráva£e funkce pro práci s efekty a poslední moºností je pracovat s lokálními soubory pomocí Flash 10.
6.2
Roz²í°ení efekt· a parametr·
Tato práce byla postavena na demostraci nejzákladn¥j²ích efekt·, je moºné ale implementovat knihovny a funkce pro roz²í°ení práce na plnohodnotnou st°iºnu nap°íklad o:
•
práci se zrychlováním a zpomalováním p°ehrávání
•
o více p°echodových efekt· neº je ztmavení
•
o parametrizaci vlastností videa (jas, kontrast, barevnost,...) a audia (ekvalizér, kompresor,...)
18
Kapitola 7
Záv¥r 7.1
Napln¥ní cíl·
Tato práce napl¬uje v²echny p°edem vyty£ené cíle. Krom¥ hotové funk£ní aplikace schopné provozu p°inesla i spoustu cenných zku²eností ve zpracování multimediálních soubor· pomocí linuxových nástroj· ImageMagick a SoX. Dále otvírá moºnosti pro navazující výzkum jak v ro²i°itelnosti aplikace, tak v do°e²ení audio p°enosu do klientské aplikace.
7.2
Úvaha nad reálným vyuºitím
Díky ucelenému °e²ení v podob¥ klienské aplikace napsané kolegou Radkem Petrán¥m a serverové apliakci napsané mnou a webhostingem poskytovaným na Sinkuleho koleji v Dejvicích jsme se rozhodli aplikaci umístit pro svobodné uºívání na Internetu a v¥novat se její propagaci aº do chvíle, kdy se uchytí, nebo bude zcela odmítnuta.
7.3
Záv¥r
Výsledkem této bakalá°ské práce je funk£ní serverová aplikace, která umoº¬uje parametrizovanou práci se stopami uloºenými ve vrstvách. Na stopy lze aplikovat dynamickou prom¥nlivost opacity v £ase, nastavitelnou statickou velikost obrazu, nastavitelnou statickou pozici obrazu v £ase a vkládání parametrizovatelného textu. Manipulace s audiem umoº¬uje nastavitelnou hlasitost, fade-in a fade-out (nájezd a výjezd na okrajích stopy). Dále aplikace umoº¬uje parametrizovaný export multimédií pro náhled a parametrizovaný render výsledného projektu. Krom¥ t¥chto nástroj· je aplikace opat°ena funkcemi umoº¬ujících v maximální mí°e ²et°it dotazování klientské aplikace serveru. Tímto práce dosahuje minimálních poºadavk· pro skute£nou video st°iºnu a demonstruje skute£nou moºnost provád¥t st°ih videa p°ímo z webového prohlíºe£e uºivatele. Aplikaci bude moºné minimáln¥ po dobu 1 roku nalézt na adrese:
http://video.web.sin.cvut.cz
19
Literatura [1] Kaourantin.net Blog autorem £lánku Tinic Uro.
http://www.kaourantin.net/2008/05/adobe-is-making-some-noise-part-3/, stav z 20. 5. 2009. [2] FFmpeg Documentation o ciální dokumentace k FFmpegu.
http://ffmpeg.org/ffmpeg-doc.html,
stav z 5. 6. 2009.
[3] RFC 2616 de nice protokolu HTTP Protokol 1.1.
http://www.w3.org/Protocols/rfc2616/rfc2616.html,
stav z 5. 6. 2009.
[4] ImageMagick API o ciální dokumentace k ImageMagicku.
http://imagemagick.org/script/api.php,
stav z 5. 6. 2009.
[5] John Reisig Blog autorem £lánku John Reisig.
http://ejohn.org/blog/embedding-and-encoding-in-javascript/,
stav
z
20. 5. 2009. [6] Nihilogic Blog autorem £lánku Jacob Seidelin.
http://blog.nihilogic.dk/2008/04/making-javascript-video-player.html, stav z 20. 5. 2009. [7] SoX Documentation o ciální dokumentace k SoundExchange.
http://sox.sourceforge.net/sox.html,
stav z 5. 6. 2009.
[8] RFC 768 de nice protokolu UDP.
http://tools.ietf.org/html/rfc768,
stav z 20. 5. 2009.
20
Kapitola 8
UML diagramy Následující diagramy 8.1 a 8.2 reprezentují mnoºinu klí£ových t°íd pro práci s multimédii. Jedná se o t°ídu mExif, která detekuje základní vlastnosti multimediálního souboru jako typ, bitrate, rozli²ení,... Dále t°ída mProcess, která má na starost volání externích binárních program· pro zpracování multimédií pomocí p°íkaz· uloºených v t°íd¥ mExport. T°ída mPicture se stará o generování vkládaného textu a barevné ltry a t°ída mObalka °e²í dynami£nost parametr· v £ase. V diagramu 8.2 jsou uvedeny objektov¥ rela£ní modely, jejichº atributy se ukládají do databáze za ú£elem vým¥ny dat mezi kontrolerem webové £ásti a kontrolerem proces managementu.
21
KAPITOLA 8.
UML DIAGRAMY
Obrázek 8.1: Jednotlivé t°ídy modelu
22
KAPITOLA 8.
UML DIAGRAMY
Obrázek 8.2: Jednotlivé t°ídy objektov¥ rela£ního modelu databáze
23
Kapitola 9
Instala£ní a uºivatelská p°íru£ka 9.1
Instalace a nastavení serveru
Díky softwarovým poºadavk·m serverové aplikace je nejvhodn¥j²ím opera£ním systémem Linux, konkrétn¥ v tomto p°ípad¥ Debian GNU/Linux verze Lenny.
9.1.1
Seznam balík· pot°ebných pro fungování serveru
apache2-mpm-prefork, apache2-utils, apache2.2-common, libapache2-mod-php5, php-pear, php5cgi, php5-cli, php5-common, php5-imagick, php5-mysql, libmysqlclient15o, mysql-admin, mysql-client-5.0, mysql-common, mysql-server-5.0, php5-mysql, imagemagick, libimage-exiftoolperl, libexif12, libsox-fmt-alsa, libsox-fmt-base, libsox-fmt-mpeg, libsox-fmt-mp3, libsox0, sox, mpeg, php5 9.1.2
Nastavení serveru
Je t°eba zvý²it standardní maximální velikost uploadovaných soubor·, a také maximální délku vykonávání skriptu v
/etc/php5/apache2/php.ini
max_execution_time = 600 upload_max_filesize = 600M post_max_size = 600M 9.2
Výpis aplika£ního rozhraní
Ve²keré p°íkazy, kterými se lze na server dotazovat jsou sou£ástí testovacího prost°edí serveru a lze si je procházet v dokumentaci na adrese
http://video.web.sin.cvut.cz/debug/api
24
Kapitola 10
Obsah p°iloºeného CD
Obrázek 10.1: Obsah p°iloºeného CD
25
