Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Diplomant: Bc. Miroslav Suk Vedoucí diplomové práce: Ing. Zuzana Šedivá Oponent diplomové práce: Ing. Čestmír Kadlec
Přístupy k publikaci stream videa na webu.
školní rok 2010/2011
Prohlášení
Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 22. 04. 2011
.......................... Podpis
Poděkování Mé upřímné poděkování patří hlavně Ing. Zuzaně Šedivé za vedení při zpracovávání diplomové práce, za vstřícnost při poskytování informací a za bezprostřední reakce na mé dotazy. Další poděkování patří Ing. Lukáši Bittovi a Janu Jarošovi, kolegům z práce, za odbornou a technickou pomoc.
Abstrakt Práce se nejprve věnuje historii propojení videa s internetem od jeho počátků do současnosti a dále si klade dva hlavní cíle. Prvním cílem je poskytnout přehled o možnostech přístupu k řešení stream videa na internetu. V práci jsou zpracovány tři odlišné přístupy. Prvním je nákup komplexního řešení v podobě mediálního serveru. Druhým je pronájem specializované služby, která zajistí správu a distribuci streamů a umožňuje integraci do informačních systémů či webových stránek klienta služby. A konečně třetí přístup uvažuje, zda a jakým způsobem by bylo možné řešit tuto problematiku v prostředí dnešního internetu zdarma i pro podnikové a komerční účely. Druhým cílem, praktickým, je realizace kompletního projektu řešení konverze, uložení a distribuce stream videa v konkrétní firmě. Hlavním oborem podnikání firmy je tvorba webových stránek a aplikací včetně zajištění jejich provozu na vlastních serverech. Nejprve jsou zhodnoceny možné přístupy k řešení. Tyto jsou uvedeny v první části práce a dále je zde zpracována alternativa vývoje vlastními silami. Tato alternativa se ukázala v daných podmínkách jako ekonomicky nejvýhodnější a byla proto realizována. Výsledné řešení má formu webové služby, která je zcela nezávislá na platformě systému, kde bude využívána. A to hlavně pro možnost přípravy modulu do ve firmě používaných redakčních systémů. Ty jsou vyvinuty v jazyce PHP nebo na platformě .NET. Práce se dále věnuje problematice samotného řešení stream videa a to hlavně s důrazem na mechanismus zvaný HTTP Pseudo Streaming. Klíčová slova: video, streaming, webová služba, video on demand, pseudostreamování, konvertor, distribuce
Abstract The beginning of the thesis deals with history of interconnection between video and the internet from its origins to the present. The thesis has two main aims. The first aim is to provide an overview of main solutions how to provide stream video over the internet. In the thesis there are described three different solutions. The first solution is to buy a complex media server. The second one is to hire a special service which can provide video storage and its distribution over the internet. The service must allow integration to various information systems and web pages or web applications. The last part of the first aim speculates about possibilities how to solve the stream video distribution over the internet in a business and commercial domain without any expenses to provide the functionality. The second aim is a practical realization of a complete project. The content of the project is a solution of video conversion, storage and distribution over the internet in a real company. The main business activity of the company is the development and providing of web pages and applications on its own servers. At the beginning of the second part of the thesis there are evaluated possible ways how to solve the goal of the project. The possible ways are solutions that are mentioned in the first part of the thesis plus development of new a solution by the company itself. The last alternative has proved to be optimal from the economic point of view. The result of the project is a web service which is completely platform independent. So it is possible to use the web service in company’s content management systems that are developed in PHP or .Net. In the thesis there is also mentioned an issue of mechanism called HTTP Pseudo Streaming. Keywords: video, streaming, web service, video on demand, pseudo-streaming, converter, distribution
Darwin Streaming Server ..................................................................................... 24
3.3.2.
Helix DNA Server................................................................................................ 25
3.4. 4.
Srovnání ................................................................................................................... 26 Přehled služeb pro konverzi, skladování a distribuci videa ......................................... 26
Srovnání ................................................................................................................... 36 Základní přehled služeb pro publikaci a online konverzi videa zdarma ...................... 36
Srovnání služeb pro publikaci stream videa zdarma ................................................ 40 Realizace webové služby ............................................................................................. 41
6.1.
Cíle projektu............................................................................................................. 41
6.2.
Analýza výchozího stavu ......................................................................................... 43
6.3.
Alternativy řešení projektu a finální výběr řešení .................................................... 45
6.3.1.
Pořízení mediálního serveru a jeho integrace do infrastruktury .......................... 45
6.3.2.
Nákup služby pro konverzi a distribuci videa ...................................................... 46
6.3.3.
Vývoj vlastními silami ......................................................................................... 48
6.3.4.
Výběr řešení ......................................................................................................... 48
6.4.
Volba technologií a architektura projektu ................................................................ 48
6.4.1.
Hardware a připojení k internetu ......................................................................... 48
6.4.2.
Volba operačního systému (FreeBSD) ................................................................ 49
1. Úvod 1.1. Téma práce Mnohé práce věnující se tématu souvisejícímu s internetem a jeho technologiemi začínají tím, že informují o rychlém vývoji, nárůstu počtu uživatelů, růstu kapacit (jak datových linek, tak úložišť), o sdílení, o trendech současné doby, roli internetu v našem životě, o informační společnosti. A tato myšlenka je dobře obhajitelná, protože internet (a hlavně služba World Wide Web) nás skutečně denně v čím dál větší míře ovlivňuje. Stále více mezilidské komunikace probíhá právě prostřednictvím internetu a i tato práce by musela začínat obdobným způsobem. Je to ale lehce tendenční a technokratický pohled. Dovolte ale zmínit jednu kacířskou úvahu známého a uznávaného autora, geologa a sociologa Václava Cílka [46]: „Představuji si, jak u studny sedí Baludžové a hodnotí ten náš zběsilý západní svět a říkají si: ‚Těm se dá pomoci jedině tak, že jim zničíme internet, jinak se už nikdy nenaučí pořádně komunikovat jako člověk s člověkem.‘“ Tato práce se věnuje videu na internetu. Video je, stejně jako řeč či psaný text, prostředek komunikace. V současné době velmi vyhledávaný, protože umožňuje za kratší čas komunikovat mnohem více informací než psaná forma. Toho jsou si samozřejmě vědomi jak autoři webových portálů, tak i podnikatelé, pro které je webová prezentace jedním z pilířů jejich mediálního obrazu. V práci se věnuji technikám a prostředkům, jak nejsnáze a nejlevněji publikaci videa na webu řešit.
1.2. Cíle práce Tato práce si klade dva hlavní cíle. Jeden cíl teoretický a druhý praktický. Oba cíle se navzájem doplňují a v závěru práce dojde k jejich průniku. Prvním cílem, teoretickým, je zmapovat současnou nabídku možností pro publikování streamovaného videa a to ze dvou odlišných pohledů. Ten první je zaměřen na poskytovatele technologii streamovaného videa, tedy na ty, kteří vyvíjejí a provozují technickou infrastrukturu umožňující distribuci videa divákovi. A druhý pohled je zaměřen na uživatele, který chce publikovat své video na internetu. V rámci této části budou stručně srovnáni největší hráči na polích dodavatelů softwaru pro realizaci serverů se streamovaným videm a poskytovatelů služeb streamovaného videa a to se zaměřením na vhodnost pro cílového uživatele. Druhým cílem, praktickým, je připravit jednoduchou webovou službu, která bude využívána interně v rámci firmy, pro kterou pracuje autor práce. Firma se primárně zabývá 6
vývojem webových aplikací na bázi v tomto odvětví tradičních technologií (webový server Apache, jazyk PHP, databáze MySQL). Klienti mají k dispozici redakční systém pro správu webového obsahu. Občas chtějí do svého webu umístit streamované video. V současné době se toto musí realizovat ručně programátory (klient chce video na stránku, zašle video do firmy, zde se video konvertuje a následně programátor umístí na web). Webová služba by tento proces měla zjednodušit a výrazně zefektivnit. Kromě samotné webové služby je cílem též zhodnocení ekonomických dopadů nového řešení. Na závěr práce bude nastíněn možný rozvoj dané služby jak z hlediska komerčního nasazení (jaké finanční nároky by znamenal nutný nárůst infrastruktury, kdo by byl typický klient, atd.), tak z hlediska vymezení vůči existujícím řešením popsaným v první části práce.
2. Fenomén stream videa 2.1. Obecný úvod do problematiky 2.1.1. Video V celé následující práci je pojem video představován souborem binárních dat, jejichž interpretací v přehrávači digitálního videa získáme pohyblivý obraz. Pojmem video (nebude-li uvedeno jinak) tedy není myšleno ani zařízení pro přehrávání analogového nebo digitálního videa a ani samotný obsah video souboru ve smyslu jeho významu. Digitální video má svého předka ve videu analogovém. Ze základního pohledu na tuto problematiku je analogové video sekvence snímků, které jsou rychle za sebou zobrazovány za účelem vytvoření iluze pohybu. Rychlost střídání snímků je odvislá od účelu videa (běžný film, time-lapse video, slow motion video, atd.) a technických prostředků. Ve filmovém průmyslu se využívá frekvence 24 snímků za sekundu [2]. Tato hodnota byla empiricky stanovena s ohledem na fyzikální vlastnosti lidského oka. Digitální video je v principu to samé, pouze jednotlivé obrazy nejsou uloženy na pásu, ale v jednom souboru. Každý tento statický obraz má rozlišení (rozměry) shodné s rozlišením videa (např. digitální HD vysílání může mít rozlišení 1920 bodů v řádce na 1080 řádků, každý bod je tvořen čtvercem [3]). Takto vytvořené video je však v praxi nepoužitelné a to čistě z kapacitních důvodů současného IT. Video se musí tzv. komprimovat. Komprimovat video znamená aplikovat na video určitý algoritmus (nejvýznamnější budou zmíněny v následujících kapitolách), který zajistí snížení celkové velikosti souboru 7
s videem vypuštěním dat bez vlivu na kvalitu videa (tzv. bezztrátová komprese) a případně dat s vlivem na kvalitu videa (tzv. ztrátová komprese). Pokud by video nebylo komprimováno, dosahovalo by i na dnešní dobu astronomických velikostí v řádu terabyte (v podstatě počet snímků za vteřinu vynásobeno délkou záznamu a velikostí každého obrazu). V praxi by bylo nepoužitelné. Toto analogicky platí i pro zvukovou část video souboru. Komprimování zajišťuje software, kterému se říká „kodek“. Samotná funkcionalita a princip kodeků pro kompresi videa (audia) je samostatná a velmi rozsáhlá problematika nad rámec této práce. Principu kodeků se věnuje však celá řada kvalitních prací, za všechny např. J. Watkinson The MPEG Handbook či I.E.G. Richardson H.264 and MPEG-4 video compression. Pro účely této práce je postačující fakt, že prakticky každé video distribuované prostřednictvím internetu je určitým způsobem komprimované. A komprimované může být různými způsoby a v různé kvalitě. Kodeků je celá řada, mezi ně patří v současné době: MPEG-2, H.264/MPEG-4, DivX, VC-1/WM3. Stručně o nich v následující tabulce. Kodek
Základní informace
Klady
Zápory
MPEG-2
Uveden v roce 1994. Stal se standardem pro DVD video. Využívá se téměř výhradně pro DVB-T (digitální pozemní vysílání). Zvládá i videa ve vysokém rozlišení (HD)
Vysoká podpora, řada nástrojů pro zpracování videa i jeho přehrávání
Svým výkonem již nestačí součastným požadavkům
H.264/MPEG-4
Nástupce MPEG-2, poskytuje výrazně lepší výkon pro zpracování HD videa – je to v současnosti nejpoužívanější kodek pro HD video.
Ze současných kodeků disponuje nejúčinnější kompresí
Vysoké hardware nároky na kódování i dekódování videa
DivX
Vytvořen na základě kodeku MPEG-4 (verze 3). Jeden z nejrozšířenějších kodeků pro kompresi filmů (obzvlášť jeho opensource varianta XviD)
Široká podpora, dobrá kompresní kvalita v běžném rozlišení.
Není vhodný pro HD video
VC-1/WM3
Vyvinut společností Microsoft. Pracuje na podobném principu jako MPEG-4, ale není s ním kompatibilní. Vhodný např. pro Blue-ray a HD DVD disky
Široká podpora přehrávání
Menší výběr nástrojů na tvorbu videa
Tabulka 1: přehled video kodeků [autor] podle [25,26,27,33]
8
Přístupy, jak prostřednictvím internetu (jeho protokolů) šířit video, jsou v principu dva. Nejstarším a stále často používaným (v současné době hlavně v tzv. šedé zóně1) je způsob, kdy video (film) umístíme na nějakém k tomu určeném serveru a uživatel si následně video stáhne jako celý soubor, který si po dokončení stahování přehraje v počítači prostřednictvím softwarového přehrávače. Vzhledem k tomu, že tento způsob je velmi populární pro bezplatné stahování filmů a seriálů, je potřebné věnovat samostatnou kapitolu (kap. 2.1.4.) právním důsledkům takového jednání. Jen pro zajímavost – dle statistik serveru TorrentFreak se nejvíce stahovaným filmem za rok 2010 stal Avatar Jamese Camerona s prokázanými 16 580 000 ilegálními staženími [7]. Druhou možností je tzv. streamované video. Slovo stream zde v překladu znamená proud. Takže video si lze představit jako nepřerušovaný proud dat, kde je každý fragment přehrán ihned po stažení a nečeká se, až dojde ke stažení celého videa. Existují dvě varianty, a to buď varianta kdy je fragment po přehrání zahozen (tzv. live streaming) anebo varianta, kdy se fragmenty postupně ukládají na disk klienta (tzv. on-demand streaming). První varianta je typická pro přímé přenosy, na druhou narazíme podstatně častěji (např. youtube.com). Varianta, kdy se jednotlivé fragmenty videa ukládají na disk, má jednu zásadní výhodu pro uživatele – videem lze posouvat (můžeme si jednotlivé části opakovaně přehrát bez nutnosti dané – předem stažené - fragmenty videa znovu stahovat). V této práci se budu věnovat právě on-demand stream videu.
2.1.2. Webové portály sloužící k sdílení videa Webové portály určené k sdílení videa s tématem této práce též velmi souvisí, je rozumné jim věnovat samostatnou podkapitolu. Zde se zaměřením na obecnou problematiku – některým konkrétním projektům bude věnováno více prostoru v kapitole o současném stavu streamovaného videa a ještě blíže v kapitole věnující se přehledu služeb pro publikaci videa uživatelem. Cílem praktické části práce je realizace webové služby (co je to webová služba bude definováno v následující kapitole) zajištující konverzi a distribuci stream videa. Důvodem její realizace je rostoucí poptávka klientů po možnosti umístit si video na své webové stránky. Za tuto poptávku lze děkovat hlavně právě velké popularitě portálů umožňujících sdílet videa mezi uživateli. Webovým portálem sloužícím k sdílení videa rozumím webový server (s veškerou nutnou technickou a technologickou infrastrukturou) umožňující jeho návštěvníkovi 1
Pod pojmem šedá zóna, zde myslím různé servery, které slouží jako úložiště (např. rapidshare.com). Tyto servery kromě obsahu zcela legálního obsahují i obsah bez jasných autorských práv – byť podléhají stále větší kontrole
9
vyhledávat, sledovat, nahrávat a případně různě hodnotit a komentovat videa. Bez velkých průzkumů lze prohlásit, že aktuální jedničkou je portál youtube.com, který také umožňuje poměrně zajímavou a často užívanou věc – vykopírovat si ze stránky s konkrétním videem HTML2 kód a ten následně vložit do jiné webové stránky, kde se zobrazí video přehrávač s možností přehrát si dané video právě na té stránce (samozřejmě součástí přehrávače je logo portálu, kde je video fyzicky umístěno a odkaz na daný portál). Zde se přímo nabízí možnost vymezit realizovanou webovou službu oproti těmto portálům. Webová služba umožní jen zmiňovanou druhou možnost přehrávání (tzn. video nebude dohledatelné přes nějaký specifický portál, fyzicky bude umístěno na technických prostředcích provozovatele daného konkrétního webu a bude přehráváno v přehrávači, jenž bude mít design přizpůsoben dané webové stránce).
2.1.3. Webové služby Pojem webová služba bude skloňován napříč celou prací. O co tedy jde? Základní definice dle konsorcia W3C zní [15]: „A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards.“ Volně přeloženo: „jedná se o softwarový systém navržený pro podporu spolupráce strojů prostřednictvím sítě. Disponuje rozhraním definovaným ve strojově čitelném formátu (WSDL). Ostatní systémy spolupracují s webovou službou způsobem popsaným v definici rozhraní prostřednictvím SOAP zpráv zasílaných typicky využitím protokolu HTTP a XML serializací v kombinaci s ostatními webovými standardy.“ Webové služby jsou dohledatelné přes tzv. UDDI registr. Webové služby jsou tedy postaveny na třech základních technologiích [17]: -
protokol pro vzdálené volání procedur, zvaný SOAP, přenášející data zapsaná jako XML
2
-
jazyk pro popis poskytovaných služeb, zvaný WSDL
-
mechanismus pro nalezení služeb, kde spolu soupeří standardy zvané UDDI
HTML je značkovací jazyk používaný pro tvorbu webových stránek[14]
10
Obrázek 1: architektura webových služeb [16]
V praxi webové služby slouží k zajištění zpracování určitých vstupů a vrácení adekvátních výstupů, způsobem, který vytváří dojem, že dané zpracování je prováděno přímo v dané aplikaci.
2.1.4. Stahování videa a legislativa Existuje obecné povědomí, že stahování filmů není v České republice nelegální, tedy není právně postižitelné. To je pravda - ovšem jen při splnění podmínek tzv. běžného užití pro soukromou potřebu fyzických osob [4]. Běžné užití může být rozporováno tím, že člověk, který film stahuje, je přímo závislý na protiprávním jednání jiné osoby a také tím, že stahuje díla, která mohou být distribuována pouze do kin [5]. Pokud je toto prokázáno, jedná se o přestupek, kde výše pokuty může dosáhnout (dle aktuální novely zákona o přestupcích) 15000 Kč (§32, [6]). To platí pro všechna díla mladší 50 let, protože právě tolik let od vydání díla má autor právo na odměnu (§87, [6]). Jinou věcí je reálná vymahatelnost takových přestupků. Jsem silně přesvědčen, že v rámci sjednocování práva v EU dojde v blízké budoucnosti k přitvrzení legislativy v této oblasti i v České republice.
2.2. Historie Na počátku bylo slovo. To slovo bylo Internet. Přehnané? Ano, možná – ne však zcela. I uznávaný profesor teologie, religionistiky a filosofie Tomáš Halík mluvil na počátku ledna 2011 v pořadu České televize Planeta Země 20113 o internetu jako o novém
3
Celovečerní debata moderovaná Václavem Moravcem, vysíláno na ČT24 dne 11. 1. 2011
11
náboženství. K tomu, aby se internet stal takovým fenoménem doby, předcházela dlouhá cesta. Ruku v ruce s rozvojem internetu rostly možnosti pro šíření multimediálního obsahu v rámci této sítě. Základním limitujícím faktorem rozvoje byl tzv. datový tok – tedy množství dat, které je síť (internet) schopná přenést za určitý čas (základní jednotka je bit za sekundu – b/s). Komerční využití (a tedy masivní rozvoj) bylo umožněno až s dosažením určitého datového toku (stovky až tisíce bitů za sekundu) na tzv. poslední míli4. V ČR nastal zlom v letech 2004-2005 – tento údaj je však nutné brát jako čistě orientační, jen pro zařazení do kontextu (jedna věc je dostupnost technologií a jiná věc je jejich rozšíření, viz graf 1 – vysokorychlostní přípojky k internetu). Do té doby byl vysokorychlostní internet dostupný pouze velkým společnostem a na akademické půdě (v roce 2005 mělo přístup k vysokorychlostnímu internetu 5,1% domácností, v roce 2010 již 50,9% [24]). Počátky videa na internetu je tedy potřeba hledat právě tam.
Graf 1: Vysokorychlostní přípojky k internetu (v tisících) v ČR [23]
Psal se rok 1992 kdy Tim Dorcey na Katedře informačních technologií Cornell University napsal program CU-SeeMe pro Macintosh [1] (verze pro platformu Windows byla dokončena v roce 1994 [9]). Program určený pro videokonference (zajišťoval přenos obrazu v reálném čase mezi dvěma vzájemně propojenými počítači prostřednictvím internetu). Program CU-SeeMe jako první prakticky využil možnosti přenosu videa pomocí infrastruktury internetu. V roce 1994 spatřil světlo světa na univerzitě Cambridge zásadní termín: Video on Demand (VOD). První praktickou realizací VOD byl projekt této univerzity nazvaný 4
Poslední míle označuje tu část infrastruktury internetu která propojuje koncového zákazníka s jeho poskytovatelem připojení k internet[8]
12
Interactive TV trial. V rámci tohoto projektu byla zajištěna distribuce stream videa (konkrétně televizního vysílání) do 250 domácností za využití protokolu IP [12]. Prvním komerčním využitím stream videa na internetu byl projekt Hotelview Alana Sapersteina z roku 1993 [11]. Hotelview již na svém počátku obsahoval databázi stovek hotelů, o kterých poskytoval (a stále poskytuje) dvouminutové šoty – a to právě ve formě stream videa [10]. Následující roky přinesly ve světě poměrně bouřlivý vývoj v rámci WWW, proto se – pokud jde o historii – zaměřím již konkrétněji na milníky související blíže s tématem práce. V roce 1996 zakládá B. Kehle portál www.archive.org, jedna jeho rubrika je nazvána „Moving image collection“, která obsahovala spoty s různou tématikou (od kreslených seriálů po protiválečné dokumenty). Jednalo se o první webový portál organizující videa. V roce 1997 založil filmař R. Raphael portál ifilm.com sloužící jako archív krátkých filmů a filmových trailerů. V roce 1998 rozjíždí Steve Boss (společnost Break Media) portál big-boys.com (později přejmenovaný na break.com). Portál obsahuje řadu krátkých videí a umožňuje vyhledávání. Obsah portálu byl cílen na muže ve věku 18 až 35 let. Prvně se zde objevuje prvek známkování videí (konkrétně stupnice 1 až 5). Tato oblast se dále rozvíjí, ale je stále problém získávat videa přímo od uživatelů. Situace se dramaticky mění v letech 2003 až 2004, kdy dochází k založení několika portálů, které na tuto problematiku reagují. Musím zmínit metacafe.com, putfile.com a hlavně vimeo.com, jehož autoři (Zach Klein, Jake Lodwick) správně jako první podchytili nutnost dobře pracovat s uživatelskou základnou (aspekt sociálních síti, které v následujících letech zažily postupný boom a v současné době nabývají neustále na významu). Vimeo se hned od začátku vymezilo jako webový portál umožňující sdílení videí mezi svými uživateli, kde autory videí jsou právě jeho uživatelé [13]. Počátkem následujícího roku, tedy roku 2005, tři čerstvě přijatí zaměstnanci společnosti PayPal Chad Hurley, Steve Chen a Jawed Karim založili youtube.com. Youtube byl od začátku dobře technologicky (jako první umožnil skutečně pohodlné nahrávání videí běžnými uživateli) a hlavně marketingově zvládnutý projekt a i díky tomu lze zřejmě říci, že kdo nezná youtube, jako by nebyl. O youtube toho bylo, je a bude napsáno mnoho. Opět se jedná o látku mimo rozsah této práce. Důležité je, že zde někde končí prehistorie a historie streamovaného videa na internetu.
2.3. Současnost a pohled do budoucnosti Největším poskytovatelem služeb streamovaného videa je v současnosti bez velkých sporů Youtube.com (přes 2 miliardy přehrání videí denně a každou minutu plus 24 hodin 13
videa [28,30] mluví samo za sebe), s velkým odstupem ho následuje Dailymotion.com (s více jak 16 miliony videí a více jak 1 miliardou přehrání měsíčně [29]). Jak si lidé na sledování videa zvykají, stále roste obliba umisťovat video i přímo do jednotlivých stránek. Stále se ovšem nejedná o triviální záležitost a řada tvůrců než aby zajišťovala konverzi videa a jeho následné umístění na web svépomocí, využívá již třeba právě zmiňovaný youtube.com. Dobrým příkladem může být internetový obchod alza.cz, který tímto způsobem publikuje představení jednotlivých výrobků. Je patrné jednoznačné posílení prezentace informací pomocí audiovizuálního záznamu oproti psanému textu. Jedním z relevantních důvodů je prostý fakt, že za jednotku času sdělíme videem více informací než psaným slovem, další důvody osobně vidím spíše v rovině nových forem zábavy a trávení volného času. Výrazným trendem je jistě video ve vysokém rozlišení – HD video. Sledování HD videa není již jen výsadou DVD přehrávačů a experimentálního digitálního televizního vysílání, stává se stále dostupnějším. V HD již můžeme shlédnout i řadu streamovaných videí, byť jsou zde stále limity týkající se značných nároků na datový tok. Je třeba též akceptovat skutečnost, že to co bylo ještě před několika lety považováno za sci-fi, je dnes realitou – téměř každý školák průměrně movitých rodičů je schopen nahrát na svůj mobilní telefon video a v případě movitějších rodičů rovnou nahrát na Youtube a sdílet se svými kamarády. A nejen školák. I vystrašený student-demonstrant, který se stal svědkem brutálního zásahu ozbrojených složek právě třeba proti demonstrantům. Aktuální situace v severní Africe (leden – únor 2011) je toho dobrým příkladem. Dochází čím dál k většímu propojení technologií se sociálním životem. V současné době již internet ve sledování audiovizuálního obsahu předběhl tradiční televizi – obzvlášť u nastupující generace [18]. Ze statistiky ČSÚ týkající se použití internetu dle činností například vyplývá, že počet uživatelů sledující televizní vysílání na internetu mezi lety 2007 a 2009 vzrostl téměř o 140% (pro celkový přehled uvádím více v tabulce 1).
14
Tabulka 2: Použití internetu k vybraným činnostem v ČR [25]
Zároveň byla téměř dokončena digitalizace pozemního televizního signálu. Tohoto trendu jsou si vědomi i někteří velcí hráči na tradičním mediálním trhu. Dobrým příkladem je Česká televize. Na začátku letošního roku spustila inovovaný portál iVysílání (archiv pořadů české televize), spustila nové weby svých kanálů – ty jsou více propojeny se sociálními sítěmi a ve spolupráci se společností Samsung připravuje projekt hybridní televize HbbTV – jedná se o možnost přímého sledování pořadů z archivu (iVysílání) na televizní obrazovce [21]. To už je ale spíše budoucnost, byť blízká. Jasně čitelné jsou trendy, že bude docházet k výraznému průniku v současnosti stále ještě oddělených technologií. Konkrétně se jedná o televizi (resp. televizní vysílání), sociální sítě, chytré mobilní telefony a případně herní konzole. Dalším trendem bude individuální sledování televize [18] – streamované video přes internet by v budoucnu mělo zcela nahradit tradiční koncept televizního vysílání 15
(tzn. sledování televizních programů v jejich vysílacích časech). To znamená, že si pořady divák sám vyhledá a bude se na ně dívat individuálně. Reálným pohledem do budoucnosti je např. Google TV, která konceptuálně vyhovuje novým trendům (viz obr. 2) – propojuje klasickou televizi s vyhledávačem, video portály, sociálními sítěmi, řadou aplikací včetně elektronických obchodů atd.
Obrázek 2: Google TV: televize budocnosti [18]
Samozřejmě změna takového rozsahu s sebou může nést i určité sociální důsledky – např. probírání posledního dílu Ordinace v růžové zahradě bude muset být během polední pauzy nahrazeno něčím jiným. Společnost se bude dále atomizovat a na to budou muset reagovat i vývojáři nových technologií. Další výzvou bude potřeba jinak řešit vyhledávání obsahu. Je čím dál těžší najít relevantní obsah a to z třech hlavních důvodů – optimalizace stránek pro vyhledávače (cílem není poskytnout relevantní obsah, ale dobře se umístit ve vyhledávači), neustálý nárůst množství webů a placené odkazy. V této souvislosti se stále více mluví o tzv. sémantickém webu – web dostane schopnost vyhledávat podle významu obsahu [20]. Budoucnost je ve 3D. Tuto a obdobné věty čteme téměř každý den. Je potřeba počítat s tím, že tato módní vlna se jen tak před něčím nezastaví a možná s sebou přinese i zcela nové technologie a postupy. Třeba se dočkáme skutečného 3D videa na nových zobrazovacích zařízeních (současné 3D video je docíleno stereoskopií -jedná se tedy o iluzi třetího rozměru na dvojrozměrném zobrazovacím zařízení). Více se můžeme přiblížit „skutečnému“ 3D obrazu určitou pokročilejší formou projekce, třeba na bázi aktivní 3D projekce, která je postavena na tomto principu [31] : „Střídavě jsou promítány obrazy pro levé a pravé oko. Frekvence střídání obrazů by měla dosahovat hodnoty 120Hz. Během jedné sekundy je tak promítnuto 60 obrazů pro každé oko. Jeden snímek je tedy zobrazen 16
pouze 1/120 sekundy. Jak ovšem zaručit, aby každé oko vidělo jen ten snímek, který je pro ně určen? Klíčem jsou opět speciální brýle. Ty jsou synchronizovány se zobrazovacím zařízením a střídavě zatmívají levé a pravé oko ve stejné frekvenci. Důsledkem je, že každé oko vždy uvidí jen obraz pro něj určený.“ Příkladem takového zařízení a inspirací do budoucna může být zařízení typu CAVE5. Jedno takové zařízení bylo postaveno na půdě ČVUT v Praze v letech 2006-2007 v rámci Rozvojového projektu MŠMT. V této formě je např. pro domácí sledování filmů samozřejmě nepoužitelné. Zatím se používá pro virtuální realitu a existují i speciálně pro CAVE vyvinuté aplikace – např. Syzygy nebo VDM pro zobrazování chemických struktur [32]. Všechno je otázkou vývoje. Třeba se ukáže, že je to slepá kolej a bude vymyšlen úplně přístup k technickému řešení 3D zobrazení.
Obrázek 3: Vizualizace zařízení typu CAVE sestaveném na půdě ČVUT v Praze [32]
3. Přehled streamovacích serverů 3.1. Metodika výběru Cílem této kapitoly není poskytnout vyčerpávající seznam všech streamovacích (či obecněji mediálních) serverových řešení, ale poskytnout čtenáři základní orientaci
5
Zařízení pro virtuální realitu. Poprvé vyvinutu na a Univerzitě v Illinois a prezentováno na konferenci Siggraph v roce 1992 [32]
17
v problematice. Nejedná se tedy o taxativní výčet všech dostupných možností, ale o demonstrativní výčet, jehož limit byl stanoven na 5 z důvodu přehlednosti výkladu. Kritériem výběru dané pětice vybraných řešení je stanovení relativní významnosti na trhu. Toto složené kritérium porovnává významnost a obecnou známost výrobce, úspěšnost ve vyhledávači Google po zadání klíčového fráze „streaming media server“ a zjistitelnou uživatelskou základnu. Dále by měla být zastoupena freeware (opensource) řešení a to v poměru 2:3. Aplikováním výběrového kritéria jsem vybral následující produkty: Wowza Media Server, Adobe Flash Media Server, Windows Media Services, Darwin Streaming Server, Helix DNA Server.
3.2. Komerční produkty 3.2.1. Wowza Media Server
Wowza Media Server je komplexní serverové řešení vyvinuté společností Wowza Media Systems, Inc. Server může být provozován na jakékoliv platformě podporující Java Runtime Enviroment. K dispozici jsou instalační balíčky pro Windows, Linux, Mac OS X. Wowza Media Server je navržen pro 64 bitové systémy a dokáže jejich výkon maximálně využít, výkon limituje pouze hardware – Wowza jako první dosáhla výkonu 10Gbps streamování pro VOD [36]. Wowza je navržena tak, aby dokázala efektivně spolupracovat s klasickými PC, mobilními zařízeními, IPTV a dalšími zařízeními připojenými pomocí protokolu IP. Dále Wowza umí zasílat stream do celé řady nejvýznamnějších přehrávačů z různých platforem – Adobe Flash player, MS Silverlight player, Apple QuickTime player a do přehrávačů na 3GPP6 telefonech (Blackberry, Android, Symbian). Obdobně širokou podporou platforem disponuje Wowza i v oblasti podporovaných protokolů pro samotný přenos videa: RTMP, RSTP/RTP, MPEG-TS, HTTP, NFS/AFS, ICY.
6
The 3rd Generation Partnership Project – partnerský projekt vytvořený v prosinci 1998 podepsáním dohody „The 3rd Generation Partnership Project Agreement“. Cílem bylo vytoření jednotných standardů pro telefony „třetí generace“ [37]
18
Obrázek 4: Wowza podporuje řadu protokolů a klientů [36]
Jedná se o poměrně mladý produkt – verze 1.0 byla distribuována v roce 2007, přesto v roce 2009 obdržel ceny „Streaming Media Readers' Choice Awards“ v kategoriích „Best Streaming Innovation“ a „Server Hardware/Software“ [34] – s velkým předstihem za dalšími finalisty Adobe a Microsoft. V roce 2010 se ve stejné kategorii objevila Wowza též mezi třemi finalisty [35]. Wowza je vhodná pro live stream, pro VOD, hodí se i pro provoz IPTV. Wowza Media Systems, Inc. reagoval dobře na fakt, že standard H.264 je již silně podporován jak zařízeními pořizujícími video, tak přehrávači. Z tohoto důvodu Wowza Media server využívá výhradně H.264 (pro audio pak AAC), což výrazně zjednodušuje workflow přípravy videa a tím i snižuje náklady [36]. Další, podrobnější, informace uvádím pro úplnost a snazší srovnání s ostatními v přehledové tabulce. Kritérium
Hodnoty a vlastnosti
Výrobce
Wowza Media Systems, Inc.
Licence
proprietární
Cena
0 – cca 18000 Kč za licenci na 1 server nebo 1200 Kč/měsíc (dle verze)
Dostupné verze
Wowza Server Developer - pro nekomerční účely zdarma - limit na 10 současných konexí Wowza Server Evaluation - zdarma na 30 dní - funkcionalita stejná jako verze Subscription Wowza Server Subscription -
standardní verze produktu platba standardně formou měsíčních poplatků, 19
Kritérium
Hodnoty a vlastnosti upgrade jsou v ceně Wowza Server Perpetual -
stejné funkce jako Subscription platba za licenci nesmí být používáno pro poskytování služeb
Podporované OS
Windows, Linux, Mac OS X
Požadavky na hardware
Dual-core nebo quad-core, min. 1 GB RAM, dva disky v RAID 0, rozhraní pro gigabit ethernet
Podporované přenosové řenosové protokoly
RTMP, RSTP/RTP, MPEG-TS, TS, HTTP, NFS/AFS, ICY
Podporované multimediální kontejnery7
QuickTime, MP4, FLV
Podporované kodeky videa
H.264
Uživatelská podpora
Fórum na stránkách, uživatelská podpora na základě základ formalizované e-mail komunikace
Tabulka 3: Technické echnické vlastnosti Wowza Media Server [zdroj: autor]
3.2.2. Adobe dobe Flash Media Server
Historie Media Serveru sahá do roku 2002, 2002 kdy společnost nost Macromedia vydala Flash Player 6, jehož součástí částí byla komponenta nazvaná Flash communication cation Server MX. Tento server sloužil pro řadu úkolů úkol a výrazně tím zvýšil použitelnost technologie Flash. Krom Kromě např. distribuce on-demand demand videa (což je pro tuto práci klíčová klíčová funkcionalita) umožňoval umož vzájemnou komunikaci jednotlivých aplikací – využití např. u on-line line real-time real her apod. Momentálněě aktuální je verze 4. Ta disponuje plnou podporou 64 bitových systémů systém a je dostupná pro operační operač systémy Windows a Linux [41]. Stejněě jako server Wowza je
7
Multimediální kontejner obaluje 1 a více datových proudů proud (typicky audio a video), dále může m obsahovat titulky atd. Dále obsahuje informace, informace, jaké kodeky byly použity na komprimaci audia a videa
20
i produkt společnosti Adobe dostupný v několika verzích (o nich blíže v přehledové tabulce), nicméně pro všechny verze platí, že dokážou na klientské straně spolupracovat pouze s přehrávači z portfolia Adobe – technologie Flash a AIR. To znamená, že jeho použití není vhodné tam, kde se předpokládá, že část cílové skupiny bude využívat zařízení, které nepodporují technologii Flash (např. iPhone, iPad, atd.). Pro přenos streamů pracuje s protokoly HTTP, RTMP a RTMFP (Real Time Media Flow Protocol – nový protokol pro komunikaci v reálném čase podporovaný přehrávači Adobe Flash Player od verze 10.1; mimo jiné přináší podporu multicastu). V aktuální verzi došlo též k posílení bezpečnosti transferu streamů a přibyla podpora IP multicast broadcast8 [39]. Velmi zajímavé je spojení Adobe a Amazon v produktu Adobe Media Server on Amazon Web Services™. Řešení ideální pro klienty, kteří nemají hardwarovou infrastrukturu a nechtějí mít vysoké počáteční investice [40]. V této variantě stačí k nasazení mít účet pro webové služby u Amazon, SFTP a SSH klienta, Flash přehrávač a kreditní kartu [40]. Tato verze pak dostupnou funkcionalitou odpovídá variantě Enterprise. Kritérium
Hodnoty a vlastnosti
Výrobce
Adobe Systems Inc.
Licence
proprietární
Cena
Cca 23000 Kč – 103000 Kč (u verze Enterprise se cena stanovuje individuálně dle klienta)
Dostupné verze
Flash Media Streaming Server 4 - Verze pro jednotlivce, malé a střední podnikání - Základní funkce VOD a live streamingu Flash Media Interactive Server 4 - verze určená pro malé a střední podnikání Flash Media Enterprise Server 4 -
verze pro velké společnosti plný rozsah funkcionality
Adobe Flash Media Server on Amazon Web Services -
stejné funkce jako Enterprise platba za poskytování služeb principem výrazně snižuje počáteční investici do infrastruktury
8
IP multicast broadcast je metoda jak doručovat co nejúsporněji stejný stream (např. vysílní IPTV) do určité množiny koncových zařízení tak, aby se pro každé koncové zařízení nevytvářel vlastní stream (což je tzv. Unicast)
21
Kritérium
Hodnoty a vlastnosti
Podporované OS
Windows (MS Windows Server 2008, MS Windows Server 2003), Linux (Red Hat Enterprise Linux Server 5.3, Linux CentOS 5.3)
Požadavky na hardware
3,2 GHz Intel Pentium 4 (dual Intel Xeon nebo výkonnější doporučený), min. 2 GB RAM pro 32-bitové systémy (4 GB pro 64-bitové), 1 Gb Ethernet karta
Podporované přenosové protokoly
RTMP, HTTP, RTMFP
Podporované multimediální kontejnery
MP4, FLV
Podporované kodeky videa
Sorenson Spark, On2 VP6, H.264
Uživatelská podpora
Na velmi slušné úrovni – od fór na webu až po speciální placené programy podpory v režimu „24 x 7 x 365“ v různých verzích podle typu klienta (Enterprises, Developers, Individuals,…)
Tabulka 4: Technické vlastnosti Adobe Flash Media Server [zdroj: autor]
3.2.3. Microsoft Windows Media Services (IIS Media Services)
V technologiích zajišťujících přípravu a distribuci streamovaného videa je dalším velkým hráčem Microsoft. Jeho MS Windows Media Services (nástupce NetShow Server pro Windows NT, aktuálně ve verzi 9) je robustní platforma pro live streaming i VOD použitelná v sítích internetu (intranetu) [42]. Využití této platformy je výhodné tam, kde již další součásti infrastruktury využívají software Microsoft (Windows Server 2008, webový server IIS,…) a to i z toho podstatného důvodu, že Windows Media Services jsou součástí těchto produktů. Další vlastností této platformy je, že přehrávač videa také musí být z rodiny softwaru společnosti Microsoft (nebo kompatibilní produkty). Pokud uvažujeme přehrávání v rámci webové stránky, typicky je v současné době používán do Windows integrovaný Windows Media Player nebo přehrávač v rámci technologie Silverlight (reakce Microsoftu na technologii Flash). Prvním skutečně velkým nasazením této technologie 22
v ČR byl projekt ČT v rámci internetového vysílání a zpravodajství z ZOH Vancouver 2010 (Microsoft CZ uvádí, že během olympiády si plug-in pro podporu Silverlight stáhlo půl miliónu uživatelů [43]). Tato technologie je vhodná jak pro stream video, tak pro IP broadcast (rádio, televize), distribuci filmů a i IPTV [44]. Jak už z textu vyplývá, podporuje unicast, multicast distribuci a řadu dalších funkcí jako smooth streaming – o tom v následujícím odstavci. Jako poměrně progresivní řešení se mi zdá integrace Media Services přímo do webového serveru IIS. Toto řešení přináší několik zajímavých výhod – mezi hlavní (týkající se samotného provozování serveru) patří plná podpora protokolu HTTP a eliminace nutnosti instalovat další serverový software. Zásadní novou funkcionalitou je jistě tzv. smooth Streaming [45]: „Smooth Streaming je to nejdůležitější a nejpokročilejší z celých IIS Media Services. Smooth Streaming umožňuje klientovi přehrávat vždy co nejkvalitnější videozáznam vzhledem k jeho možnostem – bitrate, výkon počítače, velikost přehrávače. Videozáznam je na serveru uložen ve více kvalitách a klient si sám podle svých možností volí, jakou kvalitu chce stahovat. Možnost automatického přepínání bitrate nabízejí už i WMS, ale Smooth Streaming umožňuje tyto změny kvality provádět velice dynamicky a s důrazem na to, aby přehrávání nebylo přerušeno, takže WMS zde byly výrazně překonány.“ Další variantou je Live Smooth Streaming – ten dělá totéž, ale live, takže rovnou v reálném čase vytváří několik variant přímého přenosu. To ale klade vysoké nároky na hardware, takže se jedná o technologii možnou, ale ne zcela finančně dostupnou. Kritérium
Hodnoty a vlastnosti
Výrobce
Microsoft Corporation
Licence
proprietární
Cena
Součást jiných produktů (konkrétně Windows Server 2008 a IIS)
Dostupné verze
Limity záleží na použité verzi Windows Server 2008 nebo IIS. Lze stahovat doplňky.
Podporované OS
Windows (MS Windows Server 2008)
Požadavky na hardware
1 GHz Intel Pentium 4, min. 512 GB RAM pro 32-bitové systémy, 1 Gb Ethernet karta
Podporované přenosové protokoly
RSTP, HTTP
Podporované
ASF 23
Kritérium
Hodnoty a vlastnosti
multimediální kontejnery Podporované kodeky videa
Typicky WMV9, 9, ale kontejner ASF podporuje řadu kodeků
Uživatelská podpora
Zdarma je dostupná podpora v podoběě knihovny (technet.microsoft.com) a přímé ímé možnosti kontaktovat technickou podporu Microsoftu přes řes webové formulá formuláře
Tabulka 5: Technické echnické vlastnosti Microsoft Windows Media Services (IIS Media Services) [zdroj: zdroj: autor] autor
3.3. Opensource (freeware) produkty 3.3.1. Darwin arwin Streaming Server
Darwin Streaming Server byl první, který byl dostupný zdarma. První verze vyšla v roce 1999 a hned od začátku za átku podporoval moderní kodek H.264. Byl vyvinut spole společností Apple jako opensource varianta jeho známějšího znám jšího produktu QuickTime Streaming Server, byl postaven i na jeho kódu [47]. Tím, že je provozován opensource komunitou, komunitou přišel o oficiální podporu ze strany Apple. Původně taktéž určen en pouze pro platformu Mac OS X, ale rychle byl portován i na platformu Windows, Linux, FreeBSD, Solaris. Kritérium
Hodnoty a vlastnosti
Výrobce
Apple, Inc.
Licence
Apple Public Source License
Cena
Zdarma (i pro komerční užití)
Dostupné verze
Aktuální je verze 6.0.3
Podporované OS
Mac OS X, Windows, Linux, FreeBSD, Solaris
Požadavky na hardware
Minimální nezjištěny.
Podporované přenosové řenosové protokoly
RSTP, RTP
Podporované multimediální kontejnery
MOV, MP4
24
Kritérium
Hodnoty a vlastnosti
Podporované kodeky videa
H.264
Uživatelská podpora
Diskusní fóra uživatelů a vývojářů
Tabulka 6: Technické vlastnosti Darwin Streaming Server [zdroj: autor]
3.3.2. Helix DNA Server Rozšířeným freeware řešením je též Helix DNA Server. Jedná se o freeware verzi jinak komerčního produktu Helix Universal Streaming Server, které je vyvíjen matadorem na poli streamování videa a hudby – společností RealNetworks. První verze Helix DNA Serveru byla vypuštěna v roce 2003 [48]. Freeware verze má řadu omezení. Jednou z hlavních zřejmě je, že podporuje pouze streamování ve formátech RealAudio a RealVideo. Takže klient musí být vybaven Real přehrávačem. RealVideo používala ještě Česká televize v první verzi projektu vysílání jako doplněk k Windows Media Player, ale jinak se tento formát dostává spíše do pozadí v oblibě. Na druhou stranu si poradí i s live streamingem a podporuje standardní protokoly RTSP/RTP a HTTP. Kritérium
Hodnoty a vlastnosti
Výrobce
RealNetworks, Inc.
Licence
RealNetworks Public Source License
Cena
Zdarma (pro nekomerční užití)
Dostupné verze
Aktuální je verze 11.1
Podporované OS
Windows (Server 2003), Linux, Solaris
Požadavky na hardware
Minimální nezjištěny.
Podporované přenosové protokoly
RTSP/RTP, HTTP
Podporované multimediální kontejnery
RM (RealMedia)
Podporované kodeky videa
Díky frameworku DtDriver je možné implementovat do DNA serveru celou řadu kodeků, ale s ohledem na podporované kontejnery je použitelný jen kodek RV
Uživatelská podpora
Diskusní fóra uživatelů a vývojářů, online dokumentace
Tabulka 7: Technické vlastnosti Helix DNA Serveru [zdroj: autor]
25
3.4. Srovnání Ze srovnání vybraných řešení jednoznačně vyplývá několik závěrů, které stojí za zmínění. Prvním je skutečnost, že výrobci komplexních řešení (tedy Adobe a Microsoft) jak na straně serveru, tak na straně klienta striktně podporují své technologie (v Microsoft včetně OS). Nejuniverzálnějším komerčním řešením je zcela jistě Wowza, která si poradí s celou řadou formátů a protokolů. Zajímavé je též řešení kdy na všechna videa aplikuje jeden kodek a jím zjednodušuje workflow. Není tedy divu, že v roce 2009 vyhrál tento software ceny za nejlepší inovaci a nejlepší software v oblasti streamování videa. U produktu od Microsoft je zajímavý fakt, že je již přímo integrován a to jak do webového serveru, tak do OS Microsoft Server 2008. To ho předurčuje pro použití právě tam, kde je již využíván software Microsoft. Na klientské straně se snaží propagovat technologii Silverlight jako odpověď na úspěch technologie Flash. Uvidíme, jak bude Silverlight v budoucnu úspěšný. Adobe Flash Media Server zaujal hlavně poměrně progresivní reakcí na fenomén webových služeb – varianta jeho produktu využívajících webových služeb Amazonu. Odpadá tak nutnost disponovat vlastní infrastrukturou, protože je využívána infrastruktura Amazonu a to jak pro samotný výpočetní výkon, tak na datová úložiště. To může být do budoucna perspektivní řešení například pro různé start-up projekty, kde by mohlo být riskantní provádět velké investice do infrastruktury. Navíc je zde i jinak postaven obchodní model, kdy jsou služby pronajímány a placeny měsíčními paušály. Z uvedených řešení zdarma je pro komerční účely reálně použitelný Darwin – tedy první opensource produkt v této kategorii. Jeho výrobce, Apple, se od jeho podpory distancuje a vše nechává na komunitě vývojářů. U Helix DNA serveru je značně omezující skutečnost že u klientů podporuje jen zastaralý kontejner RealMedia. Celkové srovnání vybraných řešení je uvedeno v tabulce v příloze 1.
4. Přehled služeb pro konverzi, skladování a distribuci videa Předchozí kapitola se věnovala mediálním (streamovacím) serverům. To je řešení vhodné, pokud se rozhodneme provozovat webový portál typu stream.cz nebo internetovou televizi, či potřebujeme zajišťovat specifické nároky na funkcionalitu a potřebujeme značnou flexibilitu. Podmínkou takového řešení (snad kromě využití Adobe Flash Media 26
postaveném na webových službách Amazon) je mít k dispozici adekvátní hardware – to však není levná záležitost. Pokud ale potřebujeme ve svém webovém portfoliu či například na firemním intranetu umisťovat stream videa, existují i jiná řešení. Následující kapitola bude věnována přístupu, kdy se využívá služeb pro konverzi, skladování a distribuci videa. Tyto služby disponují API9 do různých programovacích jazyků a díku tomu umožňují videa integrovat přímo do daných webových stránek (některé včetně administrace videí) tak, že se zdají být jejich nedílnou součástí. Samozřejmě i toto řešení přináší jistá úskalí a nevýhody – pro někoho může být jednou z nevýhod skutečnost, že videa nemá uložená na svých serverech, ale u poskytovatele služeb.
4.1. Metodika výběru I v tomto přehledu byl stanoven limit počtu popisovaných služeb na pět z důvodu přehlednosti výkladu. Vzhledem k tomu, že se nejedná o tolik medializovaný segment, nejsou dostupné relevantní statistiky a existuje řada podobných služeb, byla stanovena jasná omezující kritéria a prvních pět relevantních výsledků získaných pomocí vyhledávače Google tvoří daný výběr. Kritéria byla stanovena tato: -
Přehledný web služby.
-
Služba musí umět ukládat, konvertovat, distribuovat a spravovat videa.
-
Služba musí podporovat on-demand streaming.
-
Služba musí disponovat API pro jazyky standardně používané při tvorbě webových aplikací.
-
Dostupná dokumentace API bez nutnosti registrace.
-
API musí umožňovat i nahrání videa.
-
Jasný způsob placení za poskytnuté služby.
-
Zaměření na business klienty.
Aplikováním kritérií byly vybrány tyto služby: Viddler, Wistia, Vzaar, Panda, Buto.tv. Informace jsou získány převážně z oficiálních webových stránek služeb.
9
API = Application Programming Interface = rozhraní pro programování aplikací
27
4.2. Přehled vybraných služeb 4.2.1. Viddler
Viddler je komplexní platforma pro práci s videem na internetu, která umožňuje jak samotné nahrávání videí, jejich sdílení a komentování v rámci jejich webu, tak díky API i na klientských webech. Pro nekomerční účely je k dispozici zdarma s tím, že se v přehrávači videa zobrazují reklamy a je zde pevný limit na maximální velikost jednoho videa (500 MB), limit na měsíční datový tok (2 GB) a kapacitní limit úložného prostoru (také 2 GB). Zajímavým typem uživatelského účtu je „Partner“, který je také zdarma, ale i pro komerční účely. Je zde podmínka, že se bude na stránkách klienta zobrazovat reklama na Viddler a videa na stránce klienta budou zobrazena nejméně 5000 krát měsíčně. Vzhledem k výše uvedeným požadavkům je ale nejvíce zajímavý účet pro business klienty. Účet pro business klienty začíná na poplatku cca 1780 Kč / měsíc a může růst až na cenu, která je stanovena administrativně přímo provozovatelem. Mezi oběma hranicemi je možné si měsíční paušál nechat spočítat pomocí jednoduché kalkulačky, která porovnává tři veličiny: průměrný počet přehrávaných videí měsíčně, průměrnou délku videa a průměrný datový tok měsíčně. Varianta business přináší celou řadou funkcionalit včetně detailních statistik (např. lokality, ze které divák video sleduje), logování aktivity a hlavně zmiňované API pro všechny hlavní webové programovací jazyky. Podporuje také HTML5 a tak umožňuje přehrávat video i tam, kde není podporována technologie Flash – např. iPhone, iPad. Kritérium
Hodnoty a vlastnosti
Provozovatel
Viddler, Inc.
Typy klientský účtů
Personal (500MB na velikost videa, 2 GB limit na celkovou kapacitu videí, 2 GB na měsíční datový tok) Partner (Reklama na Viddler a minimálně 5000 návštěv měsíčně) Business (standard pro business klienty)
Cenové podmínky
Od 0 Kč po individuální cenu v závislosti na nárocích 28
Kritérium
Hodnoty a vlastnosti Business účet od cca 1780 Kč / měsíc. Hlavní podmínkou je datový tok, pokud je více než 4 TB / měsíc, cena se stanoví individuálně.
Flash Player (mají vlastní u kterého je možné přizpůsobit barvy), HTML5
WWW adresa
www. viddler.com
Tabulka 8: vlastnosti služby Viddler [zdroj: autor]
(*) – Vztaženo vždy k nejvyššímu typu účtu
4.2.2. Wistia
Na rozdíl od Viddler je Wistia zaměřena výhradně na business klientelu. Má velmi propracované měření statistik videí, což může být silný marketingový nástroj. Wistia nabízí tři typy klientských účtů, kde pouze třetí, nejdražší, nabízí plnou podporu API pro integraci správy a přehrávání videí přímo do klientských webů. API ani v nejvyšší verzi nepodporuje ukládání videí – to je řešeno pomocí JavaScript widgetu. API je zde postaveno jinak než např. u již zmiňovaného Viddler. Zde nemá implementovanou funkcionalitu do různých jazyků, ale využívá standardizovaných volání skriptů, které vrací odpovědi buď v JSON nebo XML. To znamená, že si vývojáři musí napsat svou sadu tříd a metod zajišťujících komunikaci s Wistia.
29
Za zmínku stojí funkcionalita teplotních map. Wistia totiž nesleduje „pouze“ kdo, kdy a odkud se na video podíval, ale ukládá i informace, zda se na některé některé části č videa podíval vícekrát. Zároveňň provádí agregaci těchto t údajů a výsledná data zobrazuje graficky (viz obr. 5). Analýza takového výstupu může m že podat zajímavé informace, které části videa jsou buď tak zajímavé nebo tak ttěžko žko srozumitelné, že si je uživatelé poušt pouštějí vícekrát nebo naopak poskytne informace o tom, kde video svého diváka ztratí (nedodívá se do konce).
Plus (obsahuje vše potřebné ebné pro správu videí, API jen pro vložení přehrávačee do klientských stránek) Deluxe (oproti variantě Plus více marketingových funkcionalit) Super (oproti variantě Deluxe navíc API pro integraci do klientských stránek)
Cenové podmínky
1400 Kč / měsíc – 6800 Kč / měsíc
Limity na velikost videa
Není
Limity na počet čet videí nahraných měsíčně
Není
Limity na velikost úložného prostoru
20 GB (možnost dokoupit další prostor)
Limity na datový tok
100 GB / měsíc (možnost dokupovat navýšení)
API podporované jazyky
Podporuje komunikaci v JSON a XML. Nabízí též javascript widget pro nahrávání (ukládání) videa na servery Wistia. Je připraveno ještě klasické API pro Ruby 30
Kritérium
Hodnoty a vlastnosti
Podporované vstupní formáty videa
MOV, MP4, M4V, AVI, WMV, ASF, MPG, VOB, MOD, 3GP
Podpora HD videa
Ano
Podporované přehrávače
Flash Player, HTML5
WWW adresa
www. wistia.com
Tabulka 9: vlastnosti služby Wistia [zdroj: autor]
4.2.3. Vzaar
Vzaar byl založen původně proto, aby zajišťoval video hosting pro eBay. Od roku 2008 nabízí své služby business klientům. Obchodní model je (podobně jako u všech ostatních) postaven na měsíčních poplatcích za poskytované služby a výše poplatků se odvíjí primárně od měsíčního datového toku – to platí pro varianty účtů Professional a Business. Pokud se klient nevejde do limitů těchto služeb (datový tok větší jak 4 TB / měsíc), je pro něj připraven účet Enterprise, kde se podmínky domlouvají individuálně. Vzaar nezpoplatňuje velikost úložného prostoru, zákazník má k dispozici neomezený úložný prostor. Vzaar na rozdíl od ostatních přímo umožňuje nahrávat i rovnou kodovaná videa (ve formátu, který je použitelný jako proud), tím je přeskočen proces automatického kódování. To může být zajímavé například tehdy, pokud autoři videa chtějí mít zcela pod kontrolou jeho výslednou kvalitu. Dále přímo nabízí značné volby pro způsob zpracování videa (včetně formátu obrazu, rozlišení,…). Vzaar z vybraných služeb nejvíce naplnil představy o podpoře pro vývojáře. Vzaar cílí právě na integraci svých služeb do webových aplikací klientů. Disponuje kvalitně zdokumentovaným API do všech významných jazyků používaných při tvorbě webu.
31
Obrázek 6: Vzaar - schéma použití API [49]
Kritérium
Hodnoty a vlastnosti
Provozovatel
Vzaar Limited
Typy klientský účtů
Professional, Business, Enterprise (individuální nastavení i cenová politika)
Cenové podmínky
870 Kč / měsíc – 26700 Kč / měsíc
Limity na velikost videa
Professional - 1GB, Business - 2 GB
Limity na počet čet videí nahraných měsíčně
Omezeno pouze datovým tokem
Limity na velikost úložného prostoru
Neomezeně
Limity na datový tok
50 GB / měsíc – 4 TB / měsíc síc u standardně paušálně placených účtů
API podporované jazyky
Ruby, Java, .NET, PHP, Scala, Objective C
Podporované vstupní formáty videa
ASF, AVI, FLV, M4V, MOV, MP4, 3GP, WMV
Podpora HD videa
Ano
Podporované přehráva řehrávače
Flash Player, HTML5
WWW adresa
www. vzaar.com
Tabulka 10:: vlastnosti služby Vzaar [zdroj: autor]
32
4.2.4. Panda
Panda vznikla v podobné době jako ostatní zde uváděné služby a to konkrétně v roce 2008. Autoři si byli dobře vědomi mezery na trhu, která v té době byla, a dokázali ji využít. Od začátku využívali Amazon Web Services a první verze byla postavena na software enkodéru ffmpeg, který bude použit v praktické části této práce. Obchodní model Panda je postaven trochu jinak než u předchozích. Zde se nepracuje s datovým tokem, ale s počtem dedikovaných enkodérů (u Panda co enkodér to jedno jádro procesoru). A dále má jinou cenovou politiku pro USA a pro země EU (ceny pro EU jsou vyšší). Možnosti jsou od 1 dedikovaného enkodéru po 9. Je též zpoplatněn upload datový tok částkou za každý nový GB. Dále Panda nabízí účet zdarma pro účely testování (zde je ale značně omezující limit na velikost videa – 10 MB) a účet pro velké podniky apod., kde je možné individuální nastavení a logicky je tím i individuální cena. Co se týče podpory pro vývojáře nabízí Panda kompletní knihovny pro PHP, Python, Ruby a .NET a dále díky zdokumentovanému RESTful10 rozhraní je možné dopsat API i do jiných jazyků, které podporují JSON. Pro upload videí je používán plug-in, který funguje tak, že primárně zkouší, zda je možné využít standard HTML5 a pokud ne, tak nahraje Flash nahrávač. Tím je zajištěna kompatibilita jak se staršími webovými prohlížeči, tak se zařízeními nepodporujícími Flash (jako již dříve zmiňovaný iPhone atd.). Vzhledem k tomu, že Panda stále využívá služeb Amazonu, nabízí zajímavou možnost i svým zákazníkům, kteří mají silně vytížené weby – Amazon CloudFront CDN. Tato služba Content Delivery Network umožňuje následně doručovat videa divákům z geograficky nejbližších serverů. Podmínkou je vytvoření účtu ještě přímo u Amazonu a jeho následná správná konfigurace. Kritérium
Hodnoty a vlastnosti
Provozovatel
PandaStream Ltd
Typy klientský účtů
Neexistují klasické účty, platí se podle nároků (stanoveno počtem dedikovaných enkodérů).
Cenové podmínky
Cca 1950 Kč / měsíc – 17500 Kč / měsíc + jednotný poplatek cca 4 Kč za každý nahraný GB.
10
REST je architektura rozhraní navržená pro distribuované prostředí. Na rozdíl od XML-RPC nebo SOAP není REST orientován procedurálně ale datově. REST tedy určuje jak přistupovat k datům [50].
33
Kritérium
Hodnoty a vlastnosti
Limity na velikost videa
5 GB
Limity na počet čet videí nahraných měsíčně
Není
Limity na velikost úložného prostoru
Není
Limity na datový tok
Není
API podporované jazyky
Hotové knihovny pro PHP, Python, Ruby, .NET. Jinak lze napsat API na bázi REST i pro jiné jazyky.
Podporované vstupní formáty videa
AAC, AVI, 3GP, FLV, MOV, MP4, MPEG, WEBM, WMV
Podpora HD videa
Ano
Podporované přehráváč řehráváče
Flash Player, HTML5
WWW adresa
www. pandastream.com
Tabulka 11:: vlastnosti služby Panda [zdroj: autor]
4.2.5. Buto.tv
Poslední vybranou službou v této kategorii je Buto.tv. Buto.tv je nejpodobnější nejpodobn službě Panda, pokud jde o funkcionalitu, a službě služb Vzaar, pokud jde o obchodní model. model Ten je tedy postaven na třech řech variantách úúčtů lišících se datovým tokem, více v přehledové řehledové tabulce. Co se týče čee zajímavých funkcionalit, tak Buto.tv jako první př přišel p s možností tzv. klikatelných videí – videí, které v určitém časovém rozmezí obsahují ahují v určitých místech klikatelné né obrazce. Po kliknutí se provede určitá ur itá akce, typicky se zobrazí poloprůhledný polopr box s textovou informací. informací Služba Buto.tv si je též vědoma popularity Youtube a z toho důvodu umožňuje ňuje přímou publikaci videí (a také zákaz jejich publikace) publi určených pro veřejnost i právěě na youtube.com. Nutností je vytvořit vytvo it si na youtube.com youtube účet a ten provázat s účtem čtem buto.tv. Další zajímavostí této služby je orientace i na diváky s poruchou
34
sluchu – služba ve všech svých variantách podporuje snadnou tvorbou titulků, které se dají dále využít i pro SEO11. API je řešeno podobně jako u služby Panda. Existují hotové knihovny pro PHP a Objective C (využitelné hlavně pro aplikace běžící na iOS) a dále existuje REST API, které zde ale podporuje komunikaci jen v XML (na rozdíl od ostatních, které podporují i JSON). Buto.tv nemá plug-in pro přímý upload videa z klientských webových stránek. Video je potřeba nejprve nahrát na klientský web server a pak odeslat službě Buto.tv pro další zpracování. Kritérium
Hodnoty a vlastnosti
Provozovatel
Big Button Media Ltd
Typy klientský účtů
Standard (limit na datový tok 75 GB / měsíc) Plus (limit na datový tok 160 GB / měsíc) High Demand (individuální nastavení)
Cenové podmínky
Standard – cca 2800 Kč, Plus – cca 5600 Kč
Limity na velikost videa
1 GB
Limity na počet videí nahraných měsíčně
Není
Limity na velikost úložného prostoru
Není
Limity na datový tok
75 GB nebo 160 GB (v případě individuálně – účet High Demand)
API podporované jazyky
PHP, Objective C + REST
Podporované vstupní formáty videa
Dle webu služby všechny hlavní včetně DVD (VOB)
Podpora HD videa
Nezjištěno
Podporované přehráváče
Flash, HTML5
WWW adresa
get.buto.tv
Tabulka 12: vlastnosti Buto.tv [zdroj: autor]
11
SEO = Search Engine Optimization. Jedná se o postup jak optimalizovat webové stránky tak, aby dosahovaly lepších výsledků v internetových vyhledávačích.
35
4.3. Srovnání Všechny srovnávané služby jsou si ve velké míře podobné a to včetně svých webových prezentací, názvosloví i obchodních modelů (až na službu Panda). Větší rozdíly najdeme v úrovni zpracování API, kde nejvíce zaujala služba Vzaar. Každý z produktů pak nabízí nějakou zajímavou nadstavbu, která může být pro některé klienty i rozhodující. U Wistia jsou to například teplotní mapy sledování videí, u Buto.tv titulky a klikací oblasti ve videích a u třeba u Panda využití Content Delivery Network v rámci infrastruktury Amazon CloudFront. Pokud jde o cenové podmínky, jsou si produkty podobné, ale zde hodně záleží na způsobu používání služby klientem. Pokud by klient hledal finančně optimální řešení, musel by si nejprve sám odhadnout, kolik může mít diváků, kolik videí chce publikovat, jaký odhaduje datový tok a pak se pokusil propočítat výslednou cenu u jednotlivých služeb. Pro všechny platí, že jsou solidní a finančně velmi výhodnou alternativou k provozu vlastního streamovacího serveru. Co však může být pro některé klienty problematické, stejně jako u ostatních SaaS aplikací, je skutečnost, že data jsou uložena (a spravována) u cizích subjektů.
5. Základní přehled služeb pro publikaci a online konverzi videa zdarma Tato kapitola bude oproti předchozím poměrně stručná. Je uvedena pro úplnost. Jako první bylo představeno komplexní řešení vyžadující i investice do hardware, přes využití paušálně placených služeb a musí být tedy zmíněna i alternativa zdarma. Pokud se rozhodneme
využít
pouze
online
enkodér,
mění
se
proces
publikace
videa
z automatizovaného na ruční. Takové video je třeba vybrat, poslat ke konverzi a následně umístit, typicky do webové stránky. Výhodnou takového řešení je, že majitel videa zkonvertovaným videem fyzicky disponuje a může použít užít svůj vlastní přehrávač, který nenese logo poskytovatele. Použití služeb na konverzi, publikaci, sdílení je výhodné tehdy, pokud na dané video chceme nalákat co nejvíce diváků, a chceme zajistit, aby bylo dobře dohledatelné.
5.1. Metodika výběru V této kapitole bude vybráno šest služeb. Tři zaměřené na konverzi a publikaci stream videa a tři zaměřené jen na jeho konverzi. 36
Způsob výběru služeb určených pouze na konverzi videa byl zvolen následující: první tři relevantní služby nalezené vyhledávačem Google po zadání hledaného výrazu „Free Online Video Converter“. Opět existuje celá řada podobných služeb s různě kvalitní konverzí (co do možností nastavení, komfortu uživatelského rozhraní, tak i do kvality samotného výsledku konverze). Cílem zde není vybrat nejlepší nebo služby komplexně popsat, byť by to bylo zajímavé samostatné téma, ale upozornit, že existuje i tato alternativa a vybrané tři služby porovnat v několika základních bodech. Způsob výběru služeb na konverzi a publikaci stream videa byl jiný. Byli vybráni tři nejvýznamnější hráči. Kritéria byla tři: jedno tvrdé – celkový počet videí k přehrání v dané službě, druhé měkké - obecné povědomí a třetí opět tvrdé - možnost snadného získání HTML kódu pro zakomponování videa do jiných stránek.
5.2. Vybrané online video konvertory dostupné zdarma 5.2.1. Zamzar Zamzar je služba, která umí konvertovat nejen videa, ale i řadu jiných typů medií a dokumentů (a to z a do rozličných formátů – v nabídce je jich skutečně celá řada). Zdarma si poradí se soubory do 100 MB a kromě konverze nahraných videí dokáže i stahovat stream videa (např. z youtube.com) a ukládat je ve formátech klasického videa. Zamzar12 funguje bez nutnosti registrace. Vyberete soubor, který chcete konvertovat a zadáte emailovou adresu, kam vám přijde notifikace, až bude konverze videa dokončena.
5.2.2. MediaConverter Další vybranou službou je MediaConverter, který při použití zdarma limituje velikost videa na 100 MB a 5 konverzí během relace (sezení)13. Pokud má uživatel vyšší nároky, je nutno zařídit si placený účet. MediaConverter je zaměřen výhradně na konverzi videa a nabízí i pokročilé možnosti nastavení jako například výběr video/audio kodeku, video/audio bitrate14, rozlišení videa a možnosti vybrat jen určitý úsek z videa. Oproti Zamzar byla konverze videa rychlejší, ale uživateli se nezobrazuje podrobnější informace o průběhu konverze, pouze malý
12
Zajímavostí je název služby – Zamzar – nese v sobě totiž odkaz na povídku Franze Kafky Proměna, kde se hlavní hrdina Řehoř Samsa během noci zkonvertoval z člověka na odporný hmyz. 13 Relace (sezení, session) je označení pro trvalé spojení mezi klientem a serverem 14 Počet bitů použitých za jednotku času
37
progressbar15. Dále zde není notifikace na email, takže uživatel musí nechat otevřený prohlížeč a čekat na informaci, že je video zkonvertováno. To může být u velkých videí poněkud nepříjemné. A oproti službě Zamzar poskytuje v základním nastavení výrazně horší výsledky co do kvality videa.
5.2.3. OnlineVideoConverter Poslední z vybraných služeb v této kategorii je OnlineVideoConverter. Z vybraných má nejméně přehledné uživatelské rozhraní a nejvíce obtěžuje reklamou. Zdarma nabízí konverzi videí do 125 MB. Neumožňuje ale detailnější nastavení konverze a podporuje nejméně výstupních formátů. Opět zde není notifikace na email, takže se na konverzi musí čekat. Na druhou stranu zde není limit na počet konverzí a služba poskytuje srovnatelnou kvalitu videa jako Zamzar.
5.3. Srovnání vybraných online video konvertorů Nejrozporuplnější výsledky konverze byly pozorovány u služby MediaConverter a zajímavý byl přístup u služby Zamzar, kdy po skončení konverze videa přijde e-mail obsahující odkaz pro stažení zkonvertovaného videa. Klient služby tedy nemusí čekat s otevřeným webovým prohlížečem, než konverze proběhne. Vybrané služby byly podrobeny krátkému testu. Test spočíval v tom, že bylo vybráno krátké video na youtube.com (originální videoklip I can’t explain kapely The Who, rozlišení 640 × 480, délka 00:02:06). Dané video bylo postupně všemi konvertory převedeno do formátu AVI. Výsledky testu v následující tabulce, zeleně jsou označeny nejlepší hodnoty a naopak červeně nejhorší. Zamzar
MediaConverter
OnlineVideoCon.
Celkový čas konverze (mm:ss)16
2:58
2:05
1:41
Průměrná rychlost stah. zkonv.
177
423
403
15
Prvek uživatelského rozhraní graficky znázorňující průběh určité operace (např. kopírování souboru) 16 Údaj je u Zamzaru jen přibližný, protože notifikace o dokončení konverze přichází do e-mailové schránky. U všech je pak složen z času stažení videa z youtube.com do konvertoru a z doby samotné konverze
38
Zamzar
MediaConverter
OnlineVideoCon.
20,8
10,2
19,5
videa (Kb/s) Velikost výsledného souboru (MB) Porovnání kvality
Tabulka 13: test online video konvertorů [zdroj: autor]
Z výsledků jasně vyplývá, že nejlepší kvalitu videa poskytuje Zamzar za cenu nejdelšího
čekání
na
konverzi,
opačné
výsledky
dává
MediaConverter
a OnlineVideoConverter je uprostřed, ale s tím, že potřebuje nejkratší čas na samotnou konverzi. Největší nabídka vstupních a výstupních formátů byla u Zamzaru, ale všechny nabízejí stěžejní a v dnešní době používané formáty a to jak klasického videa, tak formáty určené pro stream video.
5.4. Služby pro publikaci stream videa zdarma 5.4.1. YouTube YouTube je největší. Tečka. Proto zde musí být uveden jako první. V současnosti nemá žádnou konkurenci. Tím, že se dostal pod křídla Google, jen získal a dál roste. Řada lidí i firem využívá jeho služeb, protože jsou zdarma a fakt, že mají ve svých stránkách unifikovaný přehrávač (pokročilejší uživatelé si ho dokážou vzhledově přizpůsobit) s reklamou na YouTube jim nevadí. YouTube je též využíván jako online video konvertor zdarma: lidé si nahrají video na YouTube a následně si ho pomocí nástrojů, podobných těm, které byly představeny v předchozí kapitole, stáhnou. YouTube dále nabízí i komplexní API do hlavních jazyků, které jsou využívány pro vývoj webových aplikací (Java, .NET, PHP, Python). YouTube umožňuje nahrávat až 20 GB velké soubory, disponuje pro jiné poskytovatele služeb nedostupnou infrastrukturou a hlavně: toto všechno nabízí zdarma. 39
YouTube též podporuje stereoskopii. Je možné nahrávat 3D video a následně ho přehrávat ve dvou módech: V módu pro sledování s brýlemi a v módu šilhání [51], kdy se snažíme pravým okem dívat na levou část obrazu a levým okem na pravou část. To je jistě zajímavá a pokročilá funkce.
5.4.2. Vimeo Alternativou k YouTube je komunitní Vimeo, které nabízí i placený účet pro pokročilejší funkce a výrazně vyšší limity pro datový tok apod. Účet zdarma je omezen na datový tok 500 MB / týden a 1 HD video / týden. Vimeo je specifické tím, že striktně vyžaduje potvrzení autorství u nahrávaných videí a potvrzení, že se nejedná o komerční video. Tím si Vimeo získává specifické postavení a autorskou i diváckou obci a prakticky není využitelné firemní klientelou. Vimeo stejně jako YouTube umožňuje kromě samotného vykopírování kódu s videem (HTML obsahující kód pro vložení přehrávače s daným videem do webových stránek) i se více integrovat za využití API a to rovnou dvou jeho variant – jednoduchého a pokročilého. Obě varianty pracují na principu již dříve zmiňovaného principu REST a je na výběr komunikace v jazyce JSON nebo XML. Jednoduchá varianta je zaměřená na získávání videí, jejich seznamů a informací o nich. Pokročilé API podporuje i nahrávání videí apod.
5.4.3. Dailymotion Poslední z vybraných je Dailymotion, které opět nabízí podobné funkcionality jako předchozí dvě služby. V oblasti API je však rozsáhlejší než Vimeo - dává k dispozici API pro PHP a JavaScript. Jedná se o klasické knihovny pro PHP a Javascript, pomocí kterých je možné programovat vlastní specifickou funkcionalitu (v mezích API). Dailymotion umožňuje po bezplatné registraci nahrávat videa o maximální délce 20 minut a velikosti 2 GB. Pokud tyto limity uživateli nestačí, musí si vytvořit účet určený pro režiséry či producenty a smí tímto způsobem publikovat jen svou vlastní tvorbu (prakticky totéž jako u každého videa na Vimeo).
5.5. Srovnání služeb pro publikaci stream videa zdarma Technologicky, v počtu videí i v počtu diváků jednoznačně vede YouTube. Vimeo je určené pouze pro vlastní tvorbu a nekomerční účely a Dailymotion se pohybuje mezi těmito dvěma službami.
40
Pokud by se některá z uvedených služeb měla užívat pro komerční účely, tak to reálně může být YouTube – za předpokladu, že se využije maximum z jeho potenciálu. Nemá smysl ho používat pro videa určená pro sledování interně v rámci informačního systému. Na druhou stranu pokud by pomocí jeho API byla napsána aplikace spravující všechna cíleně veřejně šířená videa, umožňovalo by jejich majiteli mít nad nimi značnou kontrolu. To může být užitečné například pro snadné řízení části marketingové kampaně týkající se právě cíleného šíření určitých videí.
6. Realizace webové služby 6.1. Cíle projektu Hlavním cílem projektu je poskytnout klientům snadnou možnost vkládání videí do svých stránek bez nutnosti kontaktování poskytovatele webových stránek. Většina danou společností dodávaných webových stránek je vybavena standardizovaným redakčním systémem (administračním rozhraním).
Obrázek 7: Náhled uživatelského rozhraní redakčního systému používaného firmou [zdroj: autor]
41
Technickým cílem projektu je vytvořit jednoduché univerzální rozhraní, které by umožňovalo snadnou implementaci modulu do daného redakčního systému či jiných systémů a zároveň umožňovalo snadnou implementaci videí do veřejné části webu (buď ve formě doplňkového obsahu či galerie videí). Redakční systémy a i weby jsou programovány buď v PHP (většina případů) nebo v .NET. Technické řešení tedy musí být nezávislé na platformě použité pro konkrétní webovou aplikaci a mělo by počítat se snadnou možností rozšíření kapacit (výpočetní výkon, datová kapacita, konektivita). Nicméně v první fázi se počítá se zájmem v řádu jednotek (maximálně desítek) stávajících klientů. Funkcionalita bude samozřejmě zároveň nabízena novým klientům, kde poptávka po takové funkcionalitě existuje. Jaký ale bude mezi klienty skutečný zájem, je otázkou budoucnosti, proto by se firma ráda vyvarovala velkých počátečních investic. Požadavky na distribuci videa odpovídají standardům běžným na dnešních portálech s videem. Dostupnost videí by neměla být komplikována nutností otevírat porty, které nejsou standardně otevřeny při procházení webu. Bylo by tedy výhodné, kdyby řešení fungovalo na stejném protokolu jako HTTP (typicky port 80) tak, aby byla eliminována možnost, že jiné porty typicky určené pro stream video (RTMP, RSTP) budou blokované firewallem. Řešení by mělo být bez velkých komplikací rozšířitelné o podporu HD videa a mělo by k tomu využívat nejpoužívanější kodek H.264/MPEG-4 – a to jak pro standardní video, tak pro HD video. Dále by mělo být umožněno přehrávat video i na mobilních zařízeních, které nepodporují technologii Flash (za využití možností, které poskytuje HTML5). Shrnutí technických požadavků projektu: -
Snadná implementace do existujících redakčních systémů.
-
Nezávislost na platformě webové aplikace.
-
Možnost snadného navýšení kapacit s tím, že první verze by měla být schopná obsloužit řádově desítky klientů.
-
Dostupnost statistik o využívání služby klienty pro možnost aplikace různých obchodních modelů (bude rozvedeno v dalších kapitolách).
-
Využití protokolu HTTP.
-
Podpora HD videa a kodeku H.264/MPEG-4.
-
Možnost video přehrávat v HTML5 (kvůli mobilním zařízením nepodporujícím Flash a přípravě na blízkou budoucnost, kdy se HTML5 stane rozšířeným standardem moderních internetových prohlížečů).
42
V následujících podkapitolách bude nejprve analyzována současná situace ve formě v oblasti disponibility hardware, konektivity a softwarového vybavení. Následně budou analyzovány jednotlivé alternativy přístupu k řešení projektu. Po volbě alternativy bude tato alternativa realizována a v textu budou popsány klíčové prvky implementace a to až do fáze testovacího provozu. Následně bude řešení zhodnoceno a bude nastíněn jeho případný další rozvoj.
6.2. Analýza výchozího stavu Pokud si chce klient firmy v současné době umístit video na svůj web, má v podstatě jedinou možnost – kontaktovat firmu, která dané video v rámci svých časových kapacit připraví do žádané podoby a na web umístí a to ještě s tím faktem, že se nejedná o streamované video, ale částečně o pseudo-stremované video (pojem je vysvětlen v kapitole 6.4.8) bez možnosti vyhledávání v částech videa, které ještě nejsou stažené. Zda je činnost účtována zvlášť, či je součástí správních poplatků nebo je prováděna zdarma, je vždy otázkou konkrétní smlouvy a nastavení podmínek. Jak je ale zřejmé, není to zrovna efektivní proces. Firmě se tím blokují lidské kapacity, které se podobnými úkoly rozptylují od aktivit na jiných projektech a klient musí kvůli jednomu videu čekat někdy i celé dny. Firma disponuje v současné době celkem 13 servery u dvou server housingových společností a několika dalšími servery připojenými do internetu přímo ze sídla firmy či pobočky – ty mají ale specifický účel a nejsou pro tuto analýzu důležité – s jednou výjimkou a to je server, který v současné době nemá praktické využití a je možné ho k internetu připojit ze sídla společnosti. Přehled serverů pro provoz a podporu provozu webových aplikací uvádím pro přehlednost na následujícím obrázku (obr. 8).
Obrázek 8: Schéma zapojení serverů firmy do internetu [zdroj: autor]
43
Jak je z obr. 8 patrné, sídlo společnosti je k internetu připojeno rychlostí 1 Gbit/s, což je konektivita zcela naddimenzovaná při současném způsobu využití. Pro představu uvádím příklad využití 1 Gbit/s konektivity měřenou na routeru, který je v racku společně se 6 servery, které jsou umístěny u Master Internet (grafy 2 až 4). Na těchto serverech je hostována většina webových stránek provozovaných firmou. Z grafů je patrné, že síťová přípojka je výrazně vytížena jen vždy pravidelně v jeden čas – a to, když se zálohují data. Sídlo společnosti vytěžuje přípojku ještě podstatně méně.
Graf 2: Denní statistika vytížení sítě (NIX - vnitrostátně) u firemních serverů v Master internet [zdroj: master internet]
Graf 3: Roční statistika vytížení sítě (NIX - vnitrostátně) u firemních serverů v Master internet [zdroj: master internet]
Graf 4: Roční statistika vytížení sítě (transit) u firemních serverů v Master internet [zdroj: master internet]
Onen v současné době nevyužitý server nedisponuje takovým výpočetním výkonem jako servery umístěné v server housingových centrech, jedná se spíše o stroj vhodný pro provoz v rámci malého podniku. Konkrétně jde o server HP ProLiant v konfiguraci uvedené v tabulce 14.
Tabulka 14: Konfigurace serveru HP ProLiant [zdroj: autor]
Co se týká základního software, tak kromě dvou serverů, kde je používán operační systém Microsoft Windows Server 2003, je všude používán FreeBSD, což je léty praxe osvědčený operační systém vhodný právě pro server[53]. U serverů určených pro hostování webových aplikací je nainstalován buď webový server Microsoft IIS a .NET (tam kde je použit operační systém MS Windows Server 2003) nebo webový server Apache 2.2 a PHP 5.2.14 (nebo PHP 5.3.5) - na všech zbývajících. Standardně používaným databázovým systémem je MySQL 5.1.
6.3. Alternativy řešení projektu a finální výběr řešení 6.3.1. Pořízení mediálního serveru a jeho integrace do infrastruktury Nákup některého mediálního serveru z uvedených v kapitole 3 je řešení vhodné pro provoz robustního portálu zaměřeného na distribuci videa či provozování IPTV apod. Pro projekt specifikovaný v kapitole 6.1 je takové řešení značně naddimenzované a v zásadě neřeší samotný problém – po pořízení a zprovoznění mediálního serveru by se musel ještě řešit způsob jak implementovat komunikaci s mediálním serverem do redakčních systémů. V případě, že bychom ale o takovém řešení skutečně uvažovali, tak dle srovnání mediálních serverů v kapitole 3.4 a požadavků na projekt v kapitole 6.1 by jako vítěz vyšel produkt Wowza a to hlavně z těchto důvodů: -
Nezávislost na platformě.
-
Nezávislost na cílovém přehrávači.
-
Podpora protokolu HTTP.
Pro provoz mediálního serveru Wowza by se ještě musel pořídit odpovídající hardware, čímž by se náklady na celkovou implementaci značně zvýšily. Pro představu jsou uvedeny minimální náklady, které je nutné realizovat před začátkem řešení integrace do redakčních systémů (ceny z 6. 4. 2011): 17
RAID = Redundant Array of Independent Disks – diskové pole vytvořené z nezávislých disků. Zde jsou zapojeny v tzv. RAID 1 – jedná se o zrcadlení disků, tedy stejná data jsou uložena současně na obou discích pro případ, že by jeden disk měl technickou poruchu.
45
-
Pořízení Wowza ve verzi Subscription s licencí pro provoz na jednom serveru: cca 17 000 Kč.
-
Pořízení odpovídajícího Hardware (např.: server HP DL120 G6 G6950 + 2 x HDD HP 1TB 3G SATA 7.2K v RAID 1, cena převzata z ceníku velkoobchodu Atcomp 6. 4. 2011 a zaokrouhlena na celé tisíce): cca 32 000 Kč.
Počáteční investice by tedy byla přibližně kolem 49 000 Kč bez DPH. Uvedená cena zde slouží jen pro orientaci, v jaké cenové hladině by se investice pohybovala.
6.3.2. Nákup služby pro konverzi a distribuci videa Nákup služby pro konverzi a distribuci videa, např. některé služby z uvedených v kapitole 4.2 je scénář výrazně reálnější než nákup celého mediálního serveru. Zde se totiž přeskočí investice do pořízení software a hardware a rovnou se může přistoupit k integraci do webových aplikací, což dle kvality dostupných API je různě náročná záležitost, ale záležitost zcela jistě dobře řešitelná. Dle srovnání v kapitole 4.3 by se pravděpodobně nejlépe hodila služba Vzzar a to hlavně díky kvalitě API. Alternativou by mohla být služba Panda, které je zajímavá svou jinou obchodní politikou. Skutečný výběr by byl složen z více kritérií – to není účelem této práce, zde jde o získání rámcové představy o finančních nákladech dané služby (blíže v kapitole 6.6). Tyto služby jsou ale designovány pro použití v rámci jednoho portálu či firemního intranetu. Tím, že by firma danou službu dále zprostředkovávala jednotlivým klientům, musela by být vytvořena ještě podpůrná aplikace, která by onu koncovou distribuci řešila. Schéma by mohlo vypadat následovně:
46
Obrázek 9: Schéma komunikace mezi jednotlivými prvky projektu při využití nákupu služby [zdroj: autor]
Výše měsíčních poplatků se bude výrazně lišit podle velikosti datového toku (v případě Vzaar) či nároku na výkon (v případě služby Panda). Služba Vzaar nabízí v nejlevnějším cenovém balíčku (tzn. měsíční paušál cca 870 Kč) datový tok 50 GB na stahování videí. Při úvaze, že se datový tok průměrného videa bude pohybovat kolem 300 kB/s a průměrná délka videa bude 10 minut, tak jednoduchým propočtem (50 GB / (300 kB/s x 600s)) lze zjistit, že základní balíček by stačil na přibližně 290 zhlédnutí videí celkem za všechna videa a všechny klienty, kterým by byla dané služba zprostředkována formou modulu do redakčního systému, což by pro začátek mohlo být dostatečné, ale do budoucna by bylo zřejmě nutné limit navýšit. V základním balíčku by roční provoz služby přišel na 12 x 870 = 10 440 Kč bez DPH a bez dalších poplatků (platební transakce atd.). Služba Panda má, jak je uvedeno v kapitole 4.2.4, postavenu obchodní politiku jinak než všechny ostatní srovnávané služby. Nabízí dedikovaný enkodér s datovým úložištěm za měsíční paušál cca 1 950 Kč + poplatek 4 Kč za každý 1 GB uploadu. Při úvaze, že velikost průměrného videa se bude pohybovat od desítek do stovek MB, by průměrné náklady na upload jednoho videa činili částku kolem 1 Kč, což lze při plánovaném využití považovat za náklady zanedbatelné (budou v řádu stovek korun ročně). Cena za pronájem jednoho dekovaného serveru u Panda činila ročně 1950 x 12 = 23 400 Kč bez DPH a bez dalších poplatků (platební transakce atd.). 47
6.3.3. Vývoj vlastními silami Poslední uvažovanou alternativou je vývoj vlastními silami. Hlavní výhodou této alternativy je fakt, že umožní maximální přizpůsobení požadavkům. Hlavní nevýhodou je riziko, že kvalita výsledku nebude odpovídat požadavkům. Náklady tohoto řešení jsou činěny spíše náklady ušlé příležitosti, kdy dochází k alokaci lidských zdrojů pro vývoj a k alokaci výpočetní techniky, která by mohla být využita za jiným účelem. Vzhledem k požadavkům definovaným v kapitole 6.1 a předběžné analýze lze očekávat časovou náročnost na programování aplikace a konfigurace serveru do 70 člověkohodin včetně testování. Což znamená, že při interní hodinové sazbě ve firmě by celkové náklady nepřekročily 14 000 Kč.
6.3.4. Výběr řešení Vzhledem k faktu, že má firma k dispozici nevyužitý server a vzhledem ke skutečnosti, že je firma schopna vyvinout řešení vlastními silami a disponuje všemi dalšími nutnými prostředky, jeví se vhodná třetí alternativa. Skutečnost, že i v obou zbývajících alternativách jsou zřejmé další náklady spojené s integrací, tak celkové náklady na řešení vlastními silami se ještě relativně sníží. Dalším, ne nepodstatným faktem je, že veškeré softwarové prostředky pro realizaci daného projektu je možné volit takové, kdy používání v rámci licence je možné zdarma i pro komerční účely – či je lze používat pro komerční účely v ceně, která je podstatně nižší než u jiných (komerčních) produktů.
6.4. Volba technologií a architektura projektu 6.4.1. Hardware a připojení k internetu Pro první verzi projektu (a jeho testovací provoz) bude využit dostupný server (viz kapitola 6.2), který disponuje dostatečným výpočetním výkonem pro plánovaný počáteční rozsah projektu. V případě, že by v budoucnu kapacitně nestačil, lze u tohoto stroje jednoduše rozšířit operační paměť a úložný prostor. Jelikož se jedná o jednoprocesorový stroj, bude úzké místo – vzhledem k výkonu potřebnému pro kódování videí – právě zde. Případným možnostem rozšíření bude věnována samostatná kapitola 6.8. Server bude připojen k internetu ze sídla firmy pomocí 1 Gbit přípojky. Jak již bylo uvedeno, tato přípojka svou kapacitou umožňuje zcela dostačující datový tok pro realizaci projektu – kdyby se celé pásmo alokovalo pouze pro stahování videa (extrémní případ), 48
dokázalo by při datovém toku 300kb/s na video obsloužit bez poklesu kvality služby (zpomalené načítání videa a jeho zadrhávání) až 3 000 diváků, což je počet více jak 100 krát převyšující odhadované maximum.
6.4.2. Volba operačního systému (FreeBSD) Při volbě operačního systému je situace velmi jednoduchá. S ohledem na skutečnost, že má být projekt realizován s co nejnižšími náklady, padá volba na ve firmě osvědčený FreeBSD, tedy operační systém na bázi Linuxu, který je vyvíjen již přes 30 let [53]. Jak už název napovídá, je dostupný zdarma a poskytuje vše, co má serverový operační systém mít – hlavně bezpečnostní kvality a solidní výkon.
6.4.3. Volba webového serveru (Apache) S ohledem na zkušenosti serverových administrátorů ve firmě bude zvolen webový server Apache. To má své zcela racionální důvody, za které mluví i celosvětová statistika (graf 5) a pro srovnání i statistika z Čech (graf 6). Apache stále drží výrazné prvenství (pro zajímavost v březnu 2011 byl Apache použit celosvětově na 179 720 332 webových sídlech s podstatným náskokem na druhý Microsoft IIS s 57 644 692 použitími [55]). Apache je používán hlavně na systémech postavených na bázi linuxových operačních systémů. Konkrétně bude použita verze 2.2.17 – aktuální verze v době tvorby projektu (duben 2011).
Graf 5: Statistika rozšíření webových serverů [55]
49
Graf 6: Statistika rozšíření webových serverů v ČR [56]
Vzhledem k charakteru projektu by vhodnou alternativou k Apache mohl být webový server Lighthttpd, který je výrazně odlehčen, aby dokázal odolávat tisícům požadavků za vteřinu [54]. Díky těmto vlastnostem si ho pro servery, které distribuují stream video, oblíbil i největší hráč na trhu – Youtube. Zajímavá je jistě skutečnost, že server Lighthttpd oproti Apache – je vybaven podporou pouze jednoho procesoru a jednoho vlákna – webové prezentace tak musejí být pouštěny v rámci webového serveru, ale ve svém vlastním procesu. Daní za rychlost je výrazné omezení možnosti konfigurace. To ho předurčuje stát se webovým serverem specifických aplikací a ne univerzálním služebníkem jakým je Apache.
6.4.4. Volba programovacího jazyka (PHP) S ohledem na znalosti autora práce, je možné nad Linuxem a serverem Apache uvažovat o využití pouze jazyka PHP. Nicméně dle statistik o využití skriptovacího jazyka PHP a jeho všeobecné popularitě se nejedná o nedostatek, ale o skutečně vhodný jazyk pro realizaci daného projektu. Možnou alternativou by bylo použití .NET (jako robustnější platformy), ale to by musela být jinak zvolena platforma a licenční politika. PHP patří k nejpoužívanější skriptovací jazykům pro webové aplikace u nás i ve světě (je potřeba rozlišovat sféru nekomerční a komerční – v té na předních příčkách soupeří hlavně Java, .NET) [57,58]. PHP je oblíbené hlavně pro rychlost s jakou se lze obstojně naučit a rychlost s jakou v něm lze aplikaci vyvinout. Dalším důvodem jeho obliby je to, že je dostupné zdarma. PHP podporují i komplexní vývojová prostředí jako NetBeans či Eclipse. Na „rozložení sil“ dobře ukazují výsledky ankety, které se v roce 2009 účastnilo 925 respondentů, uveřejněné na mystik.blog.root.cz (graf 4). 50
700 PHP 600
Java (případně i s JSP)
500
.NET (ASP.NET, C#, a další) PERL
400
JSP (samostatně) 300
C/C++ Ruby/RoR
200
Smalltalk
100
Grails (Groovy on Rails) 0 Graf 7: Jaký jazyk používáte pro tvorbu webových aplikací? [57]
Stručně k historii PHP. V roce 1994 dal Rasmus Lerdorf dohromady kombinaci skriptů v Perlu, aby mohl evidovat přístupy na jeho stránky. O tyto skripty začal být zájem a byly vydány jako balíček „Personal Home Page“ tools (původní význam PHP). K tomuto dopsal ještě skriptovací jádro společně s nástrojem pro analýzu vstupu z formulářů v HTML – toto bylo nazváno PHP/FI nebo PHP2. To bylo v roce 1995. Poté se rozšířil kruh hlavních vývojářů PHP a bylo přidáno jednoduché API (Application Programmers Interface). Vzniklo přelomové PHP 3 [59]. V současné době se používá PHP 5, které se dá již nazývat objektově orientovaným programovacím jazykem, a pracuje se na vývoji PHP 6. Poměrně dlouhou dobu vedle sebe běžely verze PHP 5.2 a 5.3. V současné době končí oficiální podpora bugfixů18 verze 5.2 a doporučuje se všem správcům webů přejít na PHP 5.3. PHP 5.3 přináší řadu nových prvků (při zachování zpětné kompatibility s PHP 5.2). Mezi hlavní novinky (které už ale u jiných robustnějších jazyků dávno existují) patří podpora jmenných prostorů, anonymní funkce, nový garbage collector pro lepší práci s pamětí a zvýšení výkonu samotného jádra PHP [61]. Na serveru je nainstalováno PHP 5.3.5 rozšířené o Suhosin patch. Suhosin patch (nebo Suhosin modul) je neoficiální rozšíření PHP týkající se hlavně vylepšení bezpečnosti.
6.4.5. Volba databázového systému (MySQL) Volba databázového systému byla jednoduchá. MySQL je ve firmě zavedené pro malé až střední projekty jako standard. Administrátoři mají navíc dlouholeté zkušenosti
18
Bugfix je označení pro vydání update s opravou chyb nalezených od minulého bugfixu
51
a pro tento projekt je použití tohoto databázového systému výkonnostně zcela dostačující a navíc finančně velmi výhodné – MySQL je opět dostupné zcela zdarma. MySQL je celosvětově oblíbené volně dostupné řešení pro relační SŘBD (systém řízení báze dat). V současnosti za jeho vývojem stojí švédská společnost MySQL AB. MySQL disponuje API například pro PHP, C, PERL, Java a další. Aktuální je verze 5, která na rozdíl od předchozích podporuje procedury, pohledy, triggery a transakce. V MySQL se využívají dva základní skladovací mechanismy pro tabulky. Prvním je MyISAM (podpora fulltextového vyhledávání) a druhý je innoDB (podpora transakcí). Je mezi nimi samozřejmě více rozdílů, stejně jako mezi jednotlivými verzemi. Více informací lze nalézt např. zde: http://dev.mysql.com/doc/. Na serveru bude použita aktuální verze 5.5.
6.4.6. Zvolená technologie – platforma LAMP Výsledkem volby technologií je platforma, která pro svou popularitu dostala i vlastní název – LAMP, tedy Linux, Apache, MySQL, PHP. Jedná se o zcela standardní přístup k vývoji webových aplikací, které nejsou natolik robustní, že by tyto technologie přestaly dostačovat – a nejde jen o výkonové nároky, ale i o rozsah projektu. Integrovaná prostředí jako .NET umožňují výrazně snazší kolaboraci vývojářů a údržbu projektu jako takového. Samozřejmě platforma LAMP nezískala takovou popularitu jen proto, že umožňuje snadný vývoj webových aplikací, ale také proto, že je celá dostupná zdarma i pro komerční účely.
6.4.7. Zvolený nástroj konverze videa (FFMPEG) Posledním (ale ne významem) technologickým prvkem projektu musí být prostředek, který zajistí konverzi videa dle dodaných požadavků na konverzi. Požadavkem na nástroj je, aby byl dostupný zdarma, poskytoval kvalitní výsledky a bylo ho možné spouštět přes příkazovou řádku. Danými požadavky se výběr možných adeptů podstatně zúžil. Vyhrála kolekce software FFMPEG. V projektu bude použita konkrétně jeho utilita ffmpeg, která je přímo určená pro použití z příkazového řádku a umožňuje konverzi videa z a do řady formátů. Nutným doplňkem je knihovna libavcodec, která obsahuje všechny potřebné audio a video kodéry a dekodéry. Vhodným doplňkem je pak knihovna libx264, která je přímo určena pro kódování pomocí kodeku H.264/MPEG-4 AVC. FFMPEG je primárně určen do prostředí linuxu, jsou ale běžně dostupné i kompilace pro Microsoft Windows. FFMPEG je možné používat napřímo jen pomocí příkazové řádky, což znesnadňuje jeho použití běžnými uživateli, ale pro použití na serveru je to stav zcela vyhovující. Jedinou podmínkou je mít povolenu možnost volat přímo ze skriptu vykonávání jiného programu Tato možnost bývá defaultně zakázaná. Veškeré nastavení konverze a další 52
činnosti programu se předává pomocí rozsáhlé sady parametrů. Ukázka použití utility ffmpeg z příkazové řádky na několika jednoduchých příkladech: #zjisteni informaci o zdrojovem souboru (delka, rozliseni, bitrate,…) ffmpeg –i soubor.avi 2>&1 #konverze videa dle defaulnich paramteru z AVI do FLV ffmpeg -i insoubor.avi -f flv outsoubor.flv #vytvoreni snimku z videa v pozadovany cas (25 vterina) v rozliseni #852x480 ffmpeg –i insoubor.avi -ss 25 -vframes 1 -s 852x480 image2 outsoubor.jpg
-sameq -y -f
#konverze videa z AVI do FLV se zmenou rozsileni a bitrare audia a #videa za pouziti knihovny libx264 ffmpeg -i insoubor.avi -vcodec libx264 -vpre medium -s 352x288 -ab 192k -f outsoubor.mp4
-b 200k
6.4.8. Pseudo-streamování Na tomto místě je nejvyšší čas vysvětlit již několikrát v práci zmíněný pojem pseudostreamování, či lépe řečeno HTTP Pseudo-Streaming. V kapitole 2.1.1 bylo vysvětleno co je Video-On-Demand a jak funguje. Jedním z významných atributů je možnost posouvání se v rámci videa (tzv. seek). Při využití HTTP protokolu je standardně možné se posouvat v rámci fragmentů videa, které byly již staženy do dočasné složky v počítači – není možné tedy přeskočit část videa, která ještě není stažena na disk počítače na straně klienta. To je výrazná nevýhoda, kterou i některé významné portály s videem nedokázaly zatím odstranit (např. Vimeo.com). Řešením je buď zvolit jiný protokol (např. RTMP) nebo použít mechanismus zvaný HTTP Pseudo-Streaming. Použití RTMP protokolu s sebou přináší ale některé nevýhody. Pomineme-li skutečnost, že musíme mít server schopný distribuovat video pomocí protokolu RTMP, zbývají minimálně dvě komplikace na straně klienta. První komplikací je to, že RTMP posílá data na portu 1935, který bývá často blokován (korporátními) firewally. Druhou nevýhodou je, že RTMP je tzv. true-streaming protokol, což vyžaduje po klientovi, aby měl vždy lepší konektivitu, než je datový tok videa [64]. I to je důvod, proč má mechanismus pseudo-streamování význam a využívá ho třeba i tolikrát zmiňovaný Youtube. Princip je v tom, že po inicializaci videa v přehrávači přehrávač z metadat videa načte seznam tzv. seekpointů. To jsou místa v souboru s videem (určené vteřinami a i bajty), kde jsou tzv. keyframy. V těchto bodech je možné kontaktovat server a to tak, že se v parametru 53
za názvem souboru předá metodou GET19 parametr obsahující identifikaci pozice ve videu (buď časem, nebo bajty), odkud se chce divák dívat (v praxi při posunu jezdce v přehrávači se nalezne nejbližší následující seekpoint a jím se kontaktuje server). Server následně vrátí video od požadovaného keyframe a přehrávač začne stahovat video právě od tohoto místa. Jak z textu vyplývá, soubor s videem musí obsahovat seznam oněch klíčových bodů v metadatech [63] – to není samozřejmá záležitost a enkodér musí být schopen o tato metadata video soubor obohatit. HTTP Pseudo-Streaming má samozřejmě i své nedostatky, těmi hlavními jsou pokles bezpečnosti (u protokolu HTTP lze snadněji odchytávat pakety) a dlouhá odezva při posunu ve videích delších jak 15 minut [62]. Existují i techniky, jak pseudo-streamování vyřešit tam, kde není možné využít modul do webového serveru. Jednou z možností je obsloužit činnost, kterou by jinak prováděl přímo modul serveru, skriptem. Řešení to není ideální, ale je to legitimní alternativa. Skript v zásadě udělá tu věc, že „uřízne“ část souboru a začne načítat soubor od požadovaného bajtu, s tím, že podvrhne hlavičky souboru. V nejprimitivnější variantě může kód skriptu v PHP vypadat následovně [65]:
Pokročilejší řešení si samozřejmě s daným úkolem poradí výrazně sofistikovaněji, velmi populární je Xmoov-PHP (http://stream.xmoov.com/), ale stále se jedná o alternativní řešení, pokud není možné (z různých důvodů) využít k tomuto účelu přímo webový server. Další moderní možností je tzv. HTTP Dynamic Streaming, který je realizován pomocí zvláštního pluginu do Flash (od verze 10.1). Tento mechanismus funguje tak, že stahuje
19
GET je metoda HTTP pro odesílání dat na server, kdy jsou data součástí URI
54
paralelně krátké segmenty (o délce několika vteřin) zdrojového videa, následně je možné se posouvat v rámci oněch stažených segmentů.
6.4.9. Globální architektura projektu Při řešení globálního návrhu projektu je potřeba si znovu připomenout, jaké jsou klíčové požadavky. Tedy hlavně nezávislost na programovacím jazyku a platformě cílové webové aplikace a redakčního systému, snadná možnost implementace do jednotlivých projektů a škálovatelnost. Výsledkem je návrh, který obsahuje tři oddělené a samostatné složky. První složkou bude řídící webová služba (dále WS), která bude zprostředkovávat management videí klienta a distribuci videa. Druhou složkou je místo, kde bude prováděna samotná konverze videí a následná distribuce videa (dále DS), těchto míst může být 1 až n, podle nároků na výkon a kapacitu (buď fyzických serverů, nebo virtuálních serverů – více v kapitole 6.7). A konečně třetí složkou je databáze s metadaty videí a s daty o klientech webové služby (pro upřesnění: zde je klientem myšlen redakční systém a na něj napojený web. Nicméně oním konečným zákazníkem je stejně klient firmy - fyzická nebo právnická osoba). Pro lepší představu poslouží následující schéma:
Obrázek 10: Schéma architektury projektu [zdroj: autor]
55
V první verzi projektu budou WS i DS umístěni na jednom stroji. To je do budoucna nepřijatelný stav, ale pro účely testovaní a první zavádění do praxe stav dostatečný. Tím, že je oddělena webová služba komunikující s klientem a místo, kde dochází ke zpracování videí, je potřebné se zamyslet, jak řešit upload / download souborů. Řešení, kdy by vše probíhalo v rámci komunikace s webovou službou, je sice elegantní (minimálně z toho důvodu, že by byl klient zcela odstíněn od DS a případných změn v jeho implementaci v budoucnu), ale přinášelo by značnou redundanci datových toků. Problém byl tedy vyřešen tak, že webová služba místo aby sama zajišťovala nahrávání zdrojových videí a distribuci hotových streamů, tak poskytuje klientovi URI, na který má zaslat zdrojové video anebo z kterého má klient stahovat stream. Podrobněji bude vysvětleno v kapitolách 6.5.2 a 6.5.3.
6.5. Implementace 6.5.1. Návrh databáze Návrh databáze vychází z faktů, že potřebujeme udržovat informace o obsahu video záznamů, o jejich uložení, o klientech, o počtu zhlédnutí videí a využití jednotlivých DS – návrh databáze všechny tyto skutečnosti musí reflektovat. Co se týče zvoleného databázového enginu, lze na serveru použít MyISAM nebo InnoDB. Každý má své pro a proti. Zde byl zvolen InnoDB, byť je při některých dotazech (např. COUNT nad databází či u agregačních funkcí) pomalejší, ale za to na rozdíl od MyISAM podporuje transakce a cizí klíče. Díky možnosti využití cizích klíčů není tak snadné narušit integritu databáze jako při použití enginu MyISAM.
56
Obrázek 11: Schéma DB [zdroj: autor]
Relační databáze obsahuje celkem 9 základních tabulek nutných pro zajištění hlavní funkcionality. Nejdůležitější je tabulka videos, kde jsou uloženy všechny důležité informace, včetně místa uložení (atribut id_storage) a identifikace klienta (majitele) videa (atribut
id_client).
Velký
význam
mají
též
tabulky
clients_activity_log
a videos_conversion_log, kde jsou ukládány podrobné informace o průběhu komunikace klienta s webovou službou a o průběhu konverze videa. Tyto tabulky jsou též stěžejním informačním zdrojem pro ladění funkcionality a řešení případných stížností na funkcionalitu. Tabulka video_storages udržuje data o jednotlivých DS. Návrh tabulky rovněž počítá s možností, že by v budoucnu mohl chtít klient svůj vlastní dedikovaný DS. Účel ostatních tabulek by měl být dostatečně zřejmý z obrázku 11.
57
6.5.2. Popis implementace DS Jak již bylo uvedeno, DS slouží ke konverzi videa, jeho uložení a následné distribuci. Tyto jednotlivé části jsou na sobě nezávislé, blíže o každé v následujících podkapitolách.
6.5.2.1.
Uložení zdrojového videa
DS obsahuje jeden vstupní bod. Na ten (jehož URI získá klient pomocí funkce WS, viz kap. 6.5.3) je zaslán proud binárních dat, která jsou po autentizaci klienta a ověření platnosti URI uložena ve formátu zdrojového souboru do úložiště videí čekajících na konverzi. Ověření platnosti vstupních dat probíhá v několika úrovních. První úrovní je identifikace klientské relace – při komunikaci s WS je vytvořena relace (viz kap. 6.5.3), každá relace má jednoznačný identifikátor (hash). Zde dojde k ověření, zda je identifikátor platný a zda relace již nebyla ukončena. Druhým prvkem identifikační části URI je identifikátor samotného linku pro nahrání videa. Po ověření platnosti i tohoto atributu URI dojde k ověření HTTP hlaviček. Skript, který zajistí z klientského redakčního systému odeslání souboru pomocí protokolu HTTP, nemá přesně předepsanou podobu. Musí však do hlaviček HTTP přidat 2 nové a to X-File-Size a X-File-Name (viz kap. 6.5.4). Následně dojde k ověření ekvivalence standardní HTTP hlavičky Content-Length s X-File-Size, pro ujištění, zda je nám skutečně zasílán zdrojový soubor. Po dokončení nahrání souboru je aktualizována DB – u videa dojde mimo jiné k aktualizaci atributu waiting_to_upload. Tím dojde k zařazení videa do fronty videí čekajících na konverzi. Ukázka stěžejních částí kódu vstupního bodu:
58
// Overime vstupni parametry if( isSet($_GET['sessionidhash'], $_GET['uploadlinkhash']) && strlen($_GET['sessionidhash']) == USED_HASH_LENGTH && strlen($_GET['uploadlinkhash']) == USED_HASH_LENGTH && isset($headers['Content-Type'], $headers['Content-Length'], $headers['X-File-Size'], $headers['X-File-Name']) && $headers['Content-Type'] === 'multipart/form-data' && $headers['Content-Length'] === $headers['X-File-Size'] ) { // Pripojime se k webove sluzbe $client = new soapclientNusoap('http://vods/_ds_ws/?wsdl', true); // Overime platnost linku a uzivatelske session, pokud OK, // vrati se nam ID videa $params = array( 'sessionidhash' => addslashes($_GET['sessionidhash']), 'uploadlinkhash' => addslashes($_GET['uploadlinkhash']) ); $videoID = $client->call('getVideoID', $params); // Ziskani dat zdrojoveho videa $content = file_get_contents("php://input"); } ?>
6.5.2.2.
Konverze videa
Po uložení zdrojového videa následuje fáze konverze videa – stěžejní část celého projektu. Konverzi má na starost skript, který je pouštěn cronem20. Skript při svém startu ověří, zda není spuštěn paralelně s dalším stejným skriptem, který svou činnost ještě neukončil – to je provedeno pomocí vytvoření prázdného souboru a následně ověření jeho existence (pokud soubor existuje, znamená to, že v předchozí periodě spuštěný skript ještě nedoběhl a nová instance se ukončí). Po dokončení běhu skriptu dojde ke smazání daného souboru. Následně skript načte první soubor ve frontě čekajících na konverzi (nejdéle čekající soubor – možnost prioritizace zatím není implementována – je pouze možné spustit konverzi konkrétního videa tím, že se konverznímu skriptu předá parametrem ID daného videa). Poté se zahájí samotný proces konverze pomocí funkce exec zavolaného programu ffmpeg. Parametry konverze jsou buď defaultní nebo určené atributy
width, height,
audio_bitrate, video_bitrate (viz schéma DB), pokud jsou tyto u videa nastaveny. Důležitý je atribut ext, který určuje, zda bude výsledný kontejner videa FLV nebo MP4. Podle toho 20
Cron je linuxový program běžící na pozadí zajišťující periodické spouštění jiných programů
59
se určují další parametry konverze – při volbě MP4 je využita externí knihovna libx264 s přednastavením medium pro střední kvalitu kódování videa (vhodný poměr doby konverze, velikosti zkonvertovaného videa a jeho kvality). Touto knihovnou je dosaženo kvalitnějších výsledků konverze než při použití defaultní knihovny libavcodec. Pokud je proces konverze úspěšně dokončen, budou z videa pořízeny snímky (náhledy). Počet snímků je stanoven konstantou (základní nastavení je 5 náhledů). Postup výběru framů videa pro pořízení náhledů je následující. Délka videa se rozdělí na stejně dlouhé části, jejichž délka odpovídá počtu náhledů plus dva. Náhledy jsou pořízeny z framů na začátku druhého až předposledního úseku. Pro snímky byl zvolen kompresní formát JPG. Po dokončení konverze videa dojde k aktualizaci informací o daném videu a od té doby je dostupné pro distribuci do přehrávačů (řízení způsobu publikace je přenecháno na aplikační logice cílové aplikace, pomocí WS je možné pouze určit, zda je video publikované nebo nepublikované – to má ale pouze informační význam, více v kap. 6.5.3) Během celého procesu konverze se vytváří protokol, který je následně uložen do logu dané konverze. Pokud během konverze dojde k závažné chybě, jsou o ní administrátoři informováni formou emailů zaslaných konverzním skriptem. Ukázka zdrojového kódu stěžejní části skriptu a protokolu po úspěšně dokončené konverzi:
Pokud video prošlo úspěšně procesem konverze, je možné ho zasílat do přehrávačů. Při využití kontejneru MP4 odpadá nutnost využívat Flash přehrávač a lze využít i možnosti poslední verze HTML, tedy verze 5. Tato verze obsahuje novou značku video, pomocí které lze video umístit do HTML stránky následujícím způsobem:
Distribuce videa je řešena tak, aby podporovala i tento způsob. WS dodá klientovi URI, ze kterého je možné začít stahovat soubor se stream videem. URI však nevede přímo k souboru, ale na neexistující adresu. Ta je rozpoznána serverovým modulem pro přepis adres. Na serveru Apache k tomu slouží modul zvaný mod_rewrite (tento modul je v současné době velmi populární a řada webů ho využívá pro tvorbu takzvaných Cool Url`s21). Důvod je zřejmý – skrytí skutečného úložiště videí a to jak z bezpečnostního hlediska, tak z hlediska možnosti realizace změn v úložišti videí bez nutnosti změn adres. # ukazka prepisu adresy pomoci mod_rewrite na lokálním vývojovém # serveru (http://ds.vods/app/29-4d9a3ac7543aa2.68365498/video.mp4) RewriteEngine on RewriteRule ^([a-z0-9\.-]+)/video\.([a-z0-9]{3,4})$ http://127.0.0.1/vods_ds/data/streams/$1.$2 [L,QSA]
Klientem v tomto případě může být jak Flash přehrávač, tak i jakýkoliv jiný přehrávač, který je schopný přehrávat buď FLV nebo MP4 videa. První verze distribuce streamu byla implementována způsobem, kdy byl stream zasílán PHP skriptem. Toto řešení je též možné. Mezi jeho výhody patří, že umožňuje na úrovni aplikační logiky ošetřit detailněji stavy, kdy např. není video k dispozici atd. Nicméně tento přístup není všeobecně doporučovaný, protože zatěžuje více server.
6.5.3. Popis architektury a implementace WS Příprava webové služby v PHP není zcela triviální záležitost, nelze ji „naklikat“ jako např. v prostředí Microsoft Visual Studia v .NET projektu. Naštěstí je možné jádro PHP obohatit o knihovny tříd, které implementaci webové služby usnadňují. Nejprve je nutné 21
Cool Url`s je populární označení pro tvorbu tzv. dobře čitelných URL, kdy je například místo adresa.cz/clanky.php?id_clanku = 53 použito adresa.cz /53-clanek-o-necem. Důvod užití je v tomto případě spíše marketingová záležitost, ale má i zřejmý technický význam – skrytí implementačního prostředí. Můžeme např. přejít z JSP na ASP.Net bez nutnosti změn adres, ztrát pozic ve vyhledávačích, atd.
62
rozhodnout se jaký protokol zvolit. Jsou v zásadě dvě možnosti – jednodušší XML-RPC nebo komplexnější SOAP [66]. Podpora XML-RPC probíhá na nižší úrovni, kdy jsou připraveny pouze základní funkce pro komunikaci, ostatní (příprava struktur, kódování odpovědí, atd.) musí být implementováno programátorem. V PHP5 je možné použít implicitní extenzi nebo použít populární knihovnu NuSOAP pro PHP 5. V projektu bude použita právě knihova NuSOAP pro PHP5. Mezi výhody této knihovny patří, že umí dobře pracovat s WSDL (číst i generovat). Webová služba bude mít dvě části – první bude zajišťovat komunikaci s klientskou webovou aplikací a druhá s jednotlivými DS (první verzi tedy pouze s jedním). V následujících podkapitolách budou popsány jednotlivé funkce. Implementace webové služby za pomoci NuSOAP probíhá následovně. Nejprve se naprogramují jednotlivé funkce a poté se založí SOAP server, do kterého se tyto funkce zaregistrují s tím, že se popíšou takovým způsobem, aby byl onen popis NuSOAP schopen přečíst a následně vygenerovat WSDL (pokud se vytváří instance SOAP serveru s podporou WSDL). Známá poučka říká, že praktická ukázka vydá za několik odstavců. Následuje tedy krátká ukázka zdrojového kódu:
63
configureWSDL('vodws','urn:vodws'); // Registrace funkce pro pouziti v SOAP $server->register('authClient', array('id' => 'xsd:int','hashpass'=>'xsd:string'), array('return' =>'xsd:string'), 'urn:vodws', 'urn:vodws#authClient', 'rpc', 'encoded', 'Auth client for further operation' );
// nasledujici funkce je includovana ze skriptu soap.functions.php /** * Funkce overi identitu klienta * pokud OK, tak zalozi session a vrati jeji ID * * @param int $clientId * @param string $hashPass * @return string */ function authClient( $clientId, $hashPass) { $logObj = new ActivityLog('authClient'); $logObj->setInput(func_get_args()); $result = 0; $sessKey = ''; $clientSession = ClientSession::start($clientId, $hashPass); if($clientSession instanceof ClientSession) { $sessKey = $clientSession->getSessionKey(); $result = 1; $logObj->setResult($result); $logObj->setOutput($sessKey); $clientSession->addLog($logObj); } return $sessKey; } ?>
6.5.3.1.
Funkce authClient
Účelem této funkce je ověřit identitu klienta a vytvořit relaci s klientem. Relace nemá omezenou časovou platnost – praxe ukáže, jestli nebude nutné platnost relace omezit určitým časovým limitem. Funkce po úspěšné autentizaci vrátí hash, který využívají ostatní 64
funkce pro identifikaci relace. Vstupními parametry je ID klienta a hash vytvořený pomocí algoritmu SHA256 složený z ID klienta a privátního klíče, který má klient přidělen. Hash je převeden z binární hodnoty na textovou hexadecimální interpretaci. Vstupy funkce Parametr
Typ
Hodnota
clientid
celé číslo
ID klienta
hashpass
text (64)
Hash vytvořený pomocí algoritmu SHA256 složený z ID klienta a privátního klíče
Parametr
Typ
Hodnota
sessionid
text (64)
Náhodný řetězec vytvořený pomocí algoritmu SHA256
Výstupy funkce
6.5.3.2.
Funkce getVideo
Funkce getVideo dodá webové aplikaci informace o konkrétním videu. Odpovědí funkce je struktura. Výstup funkce získaný pomocí protokolu SOAP vypadá následovně: <SOAP-ENV:Envelope SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="urn:vodws"> <SOAP-ENV:Body> <ns1:getVideoResponse xmlns:ns1="urn:vodws"> <description xsi:type="xsd:string">popis videa 1 4593983125 <width xsi:type="xsd:int">352 288truetrue38flvhttp://ds.vods/.../video.flv <snapshoturi xsi:type="xsd:string">http://cesta
65
Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
Hash vytvořený pomocí algoritmu SHA256 složený z ID klienta a privátního klíče
Parametr
Typ
Hodnota
data
asoc. pole
Výstupy funkce
6.5.3.3.
-
label (titulek videa, text) description (popis videa, text) filesize (velikost souboru v bajtech, celé číslo) duration (délka videa, celé číslo) width (šířka videa, celé číslo) height (výška videa, celé číslo) converted (stav konverze, boolean) published (příznak publikace, boolean) views (počet zobr. videa, celé číslo) container (kontejner videa, text) uri (URI odkud lze stahovat video, text) snapshoturi (URI na hlavní náhled videa, text)
Funkce getVideoList a getPublishedVideoList
Funkce getVideoList a getPublishedVideoList slouží k získání seznamu všech videí klienta. Rozdíl mezi nimi je zřejmý – funkce getVideoList vrací všechna videa, funkce getPublishedVideoList jen těch s povolenou publikací. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
Parametr
Typ
Hodnota
data
asoc. pole
Výstupy funkce
-
videoid (ID videa, celé číslo) label (titulek, text) duration (délka videa, celé číslo) converted (stav konverze, boolean) published (příznak publikace, boolean) container (kontejner videa, text) 66
Parametr
Typ
Hodnota -
6.5.3.4.
snapshoturi (URI na hlavní náhled videa, text)
Funkce addVideo
Funkce pro přidání videa klientem. Přidání videa funguje na dvě etapy. V první dojde k založení videa v DB, kdy jsou pomocí funkce addVideo předány informace o videu. Funkce po úspěšném založení videa v DB vrátí speciální URI, na kterou je možné do doby platnosti URI (defaultně nastaveno na 1 hodinu) zaslat zdrojové video pomocí protokolu HTTP. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
sabel
text
Titulek videa
description
text
Popis videa
streamformat
text
Volba kontejneru
width
celé číslo
Šířka obrazu videa. Pokud je 0, použije se šířka zdrojového videa.
height
celé číslo
Výška obrazu videa. Pokud je 0, použije se výška zdrojového videa.
videobitrate
celé číslo
Video bitrate, který je požadován od streamu
audiobitrate
celé číslo
Audio bitrate, který je požadován od streamu
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo video založit, False v opačné situaci.
videoid
celé číslo
ID nově založeného videa
uploaduri
text
URI kam je možné přes protokol HTTP zaslat zdrojové video
uritouploader
text
URI, které je možné použít do iframe pro vložení předpřipraveného HTML5 uploaderu
Výstupy funkce
67
6.5.3.5.
Funkce updateVideoData
Jak již název napovídá, tato funkce je určena ke změně informací u videa. Změnit lze jen titulek a popis. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
Hash vytvořený pomocí algoritmu SHA256 složený z ID klienta a privátního klíče
label
text
Titulek videa
description
text
Popis videa
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo video upravit, False v opačné situaci.
Výstupy funkce
6.5.3.6.
Funkce publishVideo
Nastavení příznaku o stavu publikování videa. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
ID videa
publish
boolean
Má-li být, či nemá-li být video publikováno
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo změnit nastavení, False v opačné situaci.
Výstupy funkce
68
6.5.3.7.
Funkce deleteVideo
Zavoláním této funkce přestane klient dané video vidět. Nicméně smazané video zůstane minimálně po určitou dobu jak v databázi, tak fyzicky na serveru. Jedná se tedy o nastavení dalšího příznaku v DB. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
ID videa
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo změnit nastavení, False v opačné situaci.
Výstupy funkce
6.5.3.8.
Funkce getSnapshotList
Funkce getSnapshotList vrátí seznam všech náhledů vytvořených z daného videa. Z nich lze pak vybrat náhled, který se zobrazí v přehrávači před spuštěním videa. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
ID videa
Parametr
Typ
Hodnota
data
Pole s asoc. Polem
Výstupy funkce
6.5.3.9.
-
snapshotid(ID náhledu, celé číslo) time (čas v sekundách, celé číslo) main (příznak hlavního náhledu, boolean) uri (URI odkud je možné stáhnout náhled, text)
Funkce setMainSnapshot
Funkce slouží k nastavení hlavního náhledu z videa. 69
Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
snapshotid
celé číslo
ID náhledu
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo změnit nastavení, False v opačné situaci.
Výstupy funkce
6.5.3.10.
Funkce setVideoView
Funkce slouží k uložení záznamu o skutečnosti, že dané video bylo zobrazeno (či začalo jeho skutečné přehrávání – zde je ponechána volnost pro koncovou aplikaci). Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
ID videa
useragent
text
Informace o prohlížeči a operačním systému diváka
httpreferer
text
Informace odkud divák na stránku s videem přišel
remoteaddr
text
IP adresa diváka
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo změnit nastavení, False v opačné situaci.
Výstupy funkce
6.5.3.11.
Funkce getAllViews
Funkce vrátí informace o všech zhlédnutích daného videa. Zde je prostor pro rozšíření funkcionality v případě nutnosti sledovat více informací o divákovi. Vstupy funkce 70
Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
videoid
celé číslo
ID videa
Parametr
Typ
Hodnota
data
pole s asoc. polem
Výstupy funkce
-
6.5.3.12.
time (čas uložení záznamu, text – formát RRRR-MM-DD HH:MM:SS) userip (IP diváka, text) useragent (informace o prohlížeči a systému diváka, text) userreferer (informace odkud divák na stránku s videem přišel, text)
Funkce endSession
Funkce slouží ke korektnímu ukončení relace s klientem. Po ukončení relace přestane být platné volání funkcí s identifikátorem ukončené relace a přestane být platná URI pro nahrání zdrojového videa. Vstupy funkce Parametr
Typ
Hodnota
sessionid
text (64)
Identifikátor relace
Parametr
Typ
Hodnota
result
boolean
True pokud se podařilo změnit nastavení, False v opačné situaci.
Výstupy funkce
6.5.3.13.
Funkce getVideoID
Tato funkce je definována v jiném WSDL dokumentu (jedná se o podpůrnou webovou službu, která je provozována na jiné URI a slouží pouze pro DS). Tato funkce není dostupná klientské webové aplikaci a slouží pro ověření platnosti uživatelské relace a platnosti URI pro nahrání zdrojového videa. Vstupy funkce 71
Parametr
Typ
Hodnota
sessionidhash
text (64)
Hash sestavený z ID relace klienta a klíče
uploadlinkhash
text
Hash vytvořený při vytváření URI pro upload (při volání funkce addVideo)
Parametr
Typ
Hodnota
videoid
celé číslo
ID videa, pro které DS přijímá zdrojový soubor
Výstupy funkce
6.5.4. Popis implementace testovacího klienta WS Pro ověření funkcionality webové služby bylo vhodné vytvořit testovacího klienta pro odladění chyb a ověření, zda WS poskytuje dostatek funkcí nutných pro rozumnou implementaci modulu do redakčních systémů. Testovací klient je velmi jednoduchá webová aplikace, která je zaměřena čistě na komunikaci s WS a umožňuje též otestovat upload videí (testování datových a paměťových limitů atd.). V kapitole 6.5.3. byla uvedena ukázka implementace funkce pro autentizaci klienta, zde je tedy vhodné ukázat druhou část – tedy volání funkce pro autentizaci: getError(); if ($err) { exit('
Pro otestování přehrávání byl zvolen populární Flashový přehrávač JW player, který disponuje příjemným javascriptovým API a podporuje i HTTP Pseudo Streaming. Více informací o přehrávači JW player např. zde: http://www.longtailvideo.com/players/jw-flvplayer/. S využitím JW playeru je vložení videa do HTML stránky velmi jednoduchou záležitostí.
Potíž nastala u řešení uploadu zdrojového videa pomocí protokolu HTTP. Postup zasílání standardním způsobem, kdy se soubor odešle přes HTML formulář a čeká se na reakci serveru, zde není příliš vhodný. U velkých zdrojových videích by totiž byla odezva kriticky dlouhá (např. při rychlosti uploadu 100kB/s a velikosti videa 100MB by proces uploadu trval nejméně 17 minut). Je proto potřeba řešit tento problém jiným způsobem. Alternativou je využít Flash aplikaci umístěnou do HTML stránky, která zajistí upload na pozadí včetně průběhu uploadu (typický progress bar). Jinou alternativou je využít nové možnosti HTML 5 a pomocí něho zajistit upload souboru na pozadí. Tento postup je využit v testovacím klientovi WS. V HTML verze 5 bylo do DOM22 přidáno nové rozhraní XMLHttpRequest level 2, které na rozdíl od předchozí verze podporuje i upload souboru na pozadí. Nevýhodou zvoleného řešení je podmínka, že klientský prohlížeč musí podporovat alespoň částečně standard HTML 5 a musí mít rozhraní XMLHttpRequest level 2 – v době psaní práce aktuální verze nejrozšířenějších prohlížečů (Firefox 4, Internet Explorer, Opera, Google Chrome) již těmto podmínkám vyhovují. Při implementaci se autor práce inspiroval ukázkovým příkladem publikovaným na webu 3site.eu (www.3site.eu/jstests/upload) (autor Andrea Giammarchi), kde byl dobře vysvětlen přístup k rozhraní XMLHttpRequest level 2. Využití tohoto nového rozhraní celý proces výrazně zjednodušuje a hlavně umožňuje využít přímo vlastností standardu HTML a prohlížeče bez nutnosti užití externích pluginů a technologií. Rozhraní XMLHttpRequest level 2 obsahuje atribut upload, který odkazuje na objekt XMLHttpRequestUpload, který obsahuje (mimo jiné) události onabort, onerror, onloadstart, onprogress, onload, pomocí kterých lze dobře řídit průběh nahrávání 22
Document Object Model = objektový model dokumentu
73
a i aktualizovat HTML stránku, aby byl uživatel informován o průběhu uploadu souboru. Ukázka jednoduchého využití XMLHttpRequestUpload v kombinaci s javascriptem, HTML a CSS pro znázornění průběhu uploadu (tzv. progress bar): <script type="text/javascript"> sendFile({ file: fileToUpload, url: fileUploadUrl, onprogress:function(progressResponse) { $("#Bar").css('width', Math.round((progressResponse.loaded / progressResponse.total) * $("#Progress").width()) + 'px'); $("#Sent").html(size(progressResponse.loaded) + " z celkem " + size(progressResponse.total)); } });
Odeslání souboru se provádí metodou send() z rozhraní XMLHttpRequest level 2. Před odesláním je možné též přidat potřebné HTTP hlavičky (kvůli ověření vstupu na serveru, atd.). V testovacím klientovi je odesílací kód následující: <script type="text/javascript"> xhr = new XMLHttpRequest; xhr.open("post", handler.url, true); xhr.setRequestHeader("If-Modified-Since", "Mon, 26 Jul 1997 05:00:00 GMT"); xhr.setRequestHeader("Cache-Control", "no-cache"); xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest"); xhr.setRequestHeader("X-File-Name", handler.file.fileName); xhr.setRequestHeader("X-File-Size", handler.file.fileSize); xhr.setRequestHeader("Content-Type", "multipart/form-data"); xhr.send(handler.file);
6.5.5. Reakce na nutnost HTTP pseudo-streamování Doposud popsané řešení zatím nepočítá s mechanismem pseudo-streamování popsaným v kapitole 6.4.8. Pro podporu pseudo-streamování je potřeba rozšířit většinu prvků, konkrétně webový server, konvertor videa a cílový přehrávač. Webový server musí být rozšířen o modul h264_streaming_module. Ten je možné stáhnout např. z této stránky: http://h264.code-shop.com/trac/wiki/Mod-H264-Streaming74
Apache-Version2. Pro nekomerční užití je dostupný zdarma, pro komerční účely přijde jeho pořízení dle potřebné licence od cca 1 000 Kč (1 webový server) do 25 000 Kč (50 webových serverů). Po instalaci se musí aktualizovat konfigurační soubor Apache (httpd.conf) o následující řádky: LoadModule h264_streaming_module /cesta/k/mod_h264_streaming.so AddHandler h264-streaming.extensions .mp4
Z příkazu je zřejmé, že je nastavena podpora jen pro MP4 – to není chyba, ale reflektování skutečnosti, že tento modul podporuje HTTP Pseudo Streaming jen u MP4 (ne u FLV). Dalším krokem je aktualizace konverzního skriptu. Zde je potřeba zkonvertované video rozšířit o tzv. keyframes (viz kap. 6.4.8). Použitý nástroj FFMPEG tuto schopnost má. Je potřeba přidat parametr -g, kterým se vytváří tzv. group of pictures, což v terminologii FFMPEGu odpovídá keyframes. Hodnotou parametru je pak číslo určující po kolika rámečcích se má vytvořit keyframe. #konverze videa s keyframe z kazdeho 10 frame ffmpeg -i insoubor.avi –g 10 -f mp4 outsoubor.mp4
To ale není vše, co je potřeba udělat. V příkladu uvedenou konverzí dojde k umístění seznamu keyframes na konec souboru s videem. To je ale špatně, protože je důležité, aby tento seznam byl doručen jako první při stahování videa. Na konci pro HTTP Pseudo Streaming nemá valný význam, jelikož je již celý soubor stažen a je tedy možné se ve videu pohybovat i bez mechanismu pseudo-streamování [63]. Řešení ale opět existuje. Vzhledem k tomu, že je použit skriptovací jazyk PHP, lze použít např. knihovnu MOOV relocator. Tato knihovna umí přesunout ony potřebné informace z konce souboru na jeho začátek. Použití knihovny je velmi jednoduché. Po dokončení konverze videa stačí následující kód: setInput($inFile); // definice vystupniho souboru $moovReloc->setOutput($outFile); // Presunuti potrebnych metadata na zacatek souboru $moovReloc->fix(); ?>
75
Poslední, co se musí udělat, je dát vědět přehrávači o tom, že je na serveru podporován HTTP Pseudo Streaming. Technika je individuální přehrávač od přehrávače (a hlavně samotný přehrávač musí též podporovat tento mechanismus). V testovacím klientovi je použit JW player. V jeho případě se jedná o triviální záležitost. Stačí doplnit tyto parametry při vytváření instance přehrávače:
6.6. Hodnocení investice V kapitole 6.3 byly zhodnoceny počáteční investice dle jednotlivých variant. Náklady a efektivnost investice by bylo vhodné analyzovat podrobněji. Dle [68] existuje několik základních metod pro hodnocení návratnosti investic do podnikové informatiky. Všechny tyto metody však pracují s řadou předpokladů, které ovšem v plánovaném horizontu nemusí nastat nebo nastanou, ale dosáhnou jiných hodnot, než bylo předpokládáno. Je vhodné použít více metod a jejich výsledky vzájemně porovnat. Na základě výsledků porovnání následně zvolit vhodnou investici. Zde vzhledem k malému rozsahu investice bude zvolena jedna metoda, a to právě z důvodu obtížnosti stanovení hodnot vstupních parametrů (viz následující odstavec). Bude použita statická metoda (ROI – Return On Investment), která je uznávána praxí díky snadnému výpočtu a snadnému zjištění celkové hodnoty investice. V případě nejednoznačnosti výsledků metody ROI by bylo možné využít např. dynamickou metodu NPV (Net Present Value = Čistá Současná hodnota) pro další srovnání investic. V současné finanční teorii je dávána NPV přednost před jinými způsoby hodnocení – některé důvody proč tomu tak je, jsou následující [68]: -
respektuje faktor času,
-
je brán v úvahu efekt příjmů a výdajů po dobu životnosti investice,
-
ukazuje přínos investice k růstu tržní hodnoty podniku. 76
Nevýhodou této metody je dle [68] obtížně stanovitelná hodnota cashflow a nutnost stanovení odhadu požadované výnosnosti v době hodnocení. Hodnota požadované výnosnosti by se měla měnit v závislosti na vývoji tržního prostředí, což v době dnešních turbulencí na bankovním trhu určení požadované hodnoty značně komplikuje. Zvolená metoda má několik vstupních parametrů, které je nyní potřeba vyčíslit a odůvodnit jejich hodnoty. Zde jsou uvedeny všechny potřebné parametry pro všechny tři možné varianty investice uvedené v kapitole 6.3: -
Nákup HW (dostatečně výkonný server pro provoz mediálního serveru Wowza) (CHW): 32 000 Kč bez DPH.
-
Nákup mediálního serveru Wowza (licence pro 1 server) (CMSW): 17 000 Kč bez DPH.
-
Průměrná roční cena za elektřinu (CE) při non-stop provozu serveru a průměrném vytížení: 4110 Kč. Odhad vychází z průměrného odběru 100W a cenně za mWh 4689,67 Kč (dle ceníku E-On platného od 1. 1. 2011 a zařazení do sazby D 02d – jednotná sazba střední spotřeba), tedy: 100W x 24h x 365d x (4689,67 / 1000) = cca 4110 Kč.
-
Roční cena pronájmu služby stream videa Panda (CPP): 12 x 1950 Kč = 23 400 Kč. U této varianty se nepočítá s průměrným nákladem 1 Kč na upload jednoho videa.
-
Roční cena pronájmu Vzaar (CPV) 10 440 Kč. Zde se uvažuje základní balíček – tedy měsíční limit 50 GB.
-
Vývoj vlastními silami (CVS) 14 000 Kč.
-
Plánovaná doba životnosti investice (n) 5 let.
-
Průměrný počet zákazníků (PZ) - 10 ročně. Stanovit počet klientů, kteří budou mít o danou službu zájem je velmi komplikované. Jedná se skutečně o odhad, kdy se počítá se zájmem cca 12% klientů firmy ročně.
-
Zisk z nasazení služby do jednoho modulu redakčního systému klienta (Z) 3 000 Kč. Zde jde opět o odhad a jedná se o zisk z použití této služby ne z prodeje modulu jako takového.
-
Cena licence pseudo-streamovacího modulu do webového serveru Apache (CMA) 1 000 Kč.
77
6.6.1. Hodnocení varianty nákupu mediálního serveru V této alternativě je podstatná prvotní investice. Dále se pak jedná již jen o nutné náklady na údržbu a elektřinu. Výpočet návratnosti investice metodou ROI spočívá v porovnání průměrného zisku z investice k jejím nákladům. V tomto případě výpočet vypadá následovně: ܴܱ= ܫ
Výnosnost této alternativy dle metody ROI je 43,1%.
6.6.2. Hodnocení varianty pronájem služby Zde jsou náklady investice rozpuštěny do celé délky životnosti investice. V této alternativě odpadá jak počáteční investice, tak další náklady spojené s provozem atd. Způsob výpočtu byl vysvětlen v kapitole 6.6.1, takže nyní již samotný výpočet nejprve pro variantu služba Panda: ܴܱ= ܫ
Výnosnost investice dle metody ROI při variantě pronájmu služby Vzzar je 57,5%.
6.6.3. Hodnocení varianty vývoj vlastními silami Realizace vlastními silami je poslední uvažovaná alternativa a zároveň alternativa skutečně realizovaná. Tato alternativa má jednu velkou výhodu a to sice tu, že za jiných okolností nutná investice do HW je zde eliminována existencí vhodného a neužitého zařízení. ܴܱ= ܫ
Výnosnost této alternativy je dle metody ROI 84,4%.
78
6.6.4. Interpretace výsledků a zhodnocení Z výsledků porovnání jednotlivých variant investice dle metody ROI a se stanovením životnosti investice na 5 let vyplývá jednoznačné pořadí jednotlivých alternativ. Překvapivě nejhůře si stojí varianta pronájmu služby Panda oproti druhé možnosti z tohoto typu investice (Vzaar). Je potřeba si ovšem uvědomit, že v případě nárůstu zájmu ze strany klientů by náklady na pronájem služby Vzaar rostly výrazně rychleji (viz srovnání obchodních modelů v kap. 6.3.2) a tím by se rozdíl výsledků metody ROI snižoval. Varianta nákupu mediálního serveru Wowza i včetně nutného nákupu HW se v pětiletém horizontu umístila mezi Vzaar a Panda. Zde je ale potřeba si uvědomit riziko vyšších dodatečných nákladů při integraci do redakčních systémů. Varianta vývoje vlastními silami při použití metody ROI jednoznačně zvítězila. V případě, že by nebyl ovšem k dispozici požadovaný HW, bylo by již otázkou, zda by se při zaručení dostupnosti a adekvátní kvality služby nevyplatilo využít službu Vzaar. V případě velkého zájmu by byla nutná investice do rozšíření HW, což by hodnotu ROI zhoršilo. Všechny alternativy počítají se stálým zájmem klientů, se stálou cenou elektřiny a abstrahují od dodatečných nákladů na integraci. Je tedy nutné je brát jako orientační, nicméně rozdíly mezi jednotlivými alternativami jsou jednoznačné.
6.7. Rozvoj a budoucnost Současné technické řešení odpovídá nárokům kladeným v cílech projektu. Díky použitým technologiím se podařilo náklady projektu stlačit na minimum a to bez velkého vlivu na požadovanou funkcionalitu. Zvolené řešení též podporuje rozšíření kapacit systému (přidáním dalších DS). Pokud by došlo v budoucnu k velkému nárůstu poptávky po dané službě, muselo by dojít k inovaci jak na úrovni technického řešení, tak obchodního modelu.
6.7.1. Technická inovace Výrazný nárůst nároků na kapacitu a kvalitu služby by znamenal nutnost změn v infrastruktuře zajišťující danou službu. V první řadě by bylo vhodné umístit server do firemního racku pronajatého u server housingové společnosti (v tomto konkrétním případě by šlo zřejmě o Master Internet) z důvodu zajištění kvalitnějšího zázemí provozu a tím i vyšší dostupnosti. Po tomto kroku by ale musela být věnována pozornost připojení k internetu. Pásmo 1Gbit se zdá být 79
dostatečné i v případě opravdu značného zájmu o službu videa, ale přesto by bylo vhodné zajistit, aby v krizových případech extremního vytížení nedošlo k nedostupnosti webů umístěných na dalších serverech v racku (za stejným routerem). To by šlo vyřešit např. technikou packet markingu, tedy technikou kdy na routeru dojde k označení paketu dle IP adresy serveru a zařazení do přiděleného pásma. Dle grafu 2, kap. 6.2 je zřejmé, že pro bezproblémový provoz webů stačí 100Mbit/s, takže by se dalo pásmo rozdělit např. 900Mbit/s pro video a 100Mbit/s pro weby či jiná varianta vycházející z reálných potřeb na rozdělení pásma – samozřejmě v případě, že by služba videa byla provozována na samostatném serveru (to je z předchozího textu patrné – zde je toto uvedeno pro úplnost). S nárůstem požadavků na kapacitu a výpočetní výkon je možné se vyrovnat v zásadě dvěma způsoby. Buď postupně navyšovat fyzický počet serverů zajišťujících konverzi a distribuci videa anebo virtualizovat. Či ještě modifikovat přístup tak, že na samostatném zařízení (ať již fyzickém či virtuálním) bude docházet jen ke zpracování zdrojového videa a zkonvertované video bude následně buď přes sběrnici (v případě virtualizace) nebo přes ethernet odesláno na server zajišťující uložení streamů a jejich distribuci. Toto řešení by umožňovalo lépe zajišťovat specifické požadavky pro jednotlivé činnosti – konverze videa má jiné nároky na procesor a paměť než jeho distribuce. Nakupování nových serverů podle rostoucích nároků v čase má v podstatě dvě hlavní výhody. Jednak rozložení investice na delší období a jednak - při využití dalšího server housingu - rozložení na více připojení do páteřní sítě a tím zajištění zvýšené dostupnosti. Plný efekt by byl ale dosažen pouze tehdy, pokud by všechny streamy byly fyzicky dostupné na všech serverech – tedy v zásadě koncept CDN23 a nebyly tímto krokem řešeny problémy s kapacitou (či jen částečně – u všech serverů by muselo být navíc řešeno navyšování úložné kapacity). To by ale mělo skutečné reálné využití až tehdy, pokud by se firma nebo některý její zákazník rozhodl provozovat zcela plnohodnotný portál s videem. Pokud by se v budoucnu služba osvědčila a byl by o ni větší zájem, než jak je plánováno v cílech projektu (kap. 6.1), bylo by zřejmě efektivnější provést větší a jednorázovou investici do nákupu dostatečně výkonného serveru podporujícího virtualizaci a rozdělit proces konverze od distribuce na 2 virtuální servery s tím, že data mezi nimi by se nezasílala přes ethernet, ale pomocí sběrnice. Vhodné zařízení by mohlo být např. server IBM z řady x3850 s vhodnou virtualizační platformou (např. VMWare vSphere nebo CentOS). Zde by šlo ovšem o investici v řádech desítek až stovek tisíc a to je v současné době zcela nereálná představa. 23
CDN = Content Delivery Network. Koncepce kdy jsou data kopírována na více serverů geograficky od sebe oddělených (globálně rozmístěných) s cílem zajištění rychlejší dostupnosti dat, kdy jsou klientovi dodávána data z nejvýhodnějšího místa tak, aby došlo k optimalizaci datového toku a doby přenosu dat.
80
6.7.2. Inovace obchodního modelu Základní obchodní model je postaven tak, že zisk z tohoto projektu přináší prodej modulů do redakčních systémů. Jedná se tedy o jednorázový příjem. V případě, že by určitý klient tento modul chtěl využívat více, či by došlo k modifikaci modulu do podoby, ve které by nahrávání videí nebylo součástí redakčního systému, ale veřejné části (mohlo by jít o různé soutěže o nejlepší uživatelské video atd.). Pro takového klienta (či klienty) by bylo vhodnější postavit obchodní model na jednorázové částce za implementaci (ta by mohla být nižší) a následně stanovit částku za nahrání jednoho videa či jedno jeho zhlédnutí – nebo oboje (cena by tak reflektovala fakticky datový tok, kterým klientův web zatíží celý systém). Následně by klientovi chodilo měsíční či roční vyúčtování. Současný návrh databáze tuto formu vyúčtování podporuje – je možné zjistit počet videí klienta, jejich velikost a počet zobrazení, což jsou informace dostačující. Tento obchodní model by přinášel příjem odpovídající návštěvnosti a úspěchu webu klienta, což je model oboustranně spravedlivý. Další možností, jak komerčně využít tuto službu videa, je ji přímo nabídnout externím subjektům. V práci se počítá pouze s interním využitím služby, její nabídnutí pro externí využití by nemuselo být nezajímavé, ale již by to s sebou jistě neslo nutnost výrazných investic do hardware a v podstatě by se jednalo o lokální variantu služeb popisovaných v kapitole 4.2. Obchodní model by pak mohl být postaven podobně jako u těchto služeb. Tedy zpoplatnění datového toku, zpoplatnění úložného prostoru či zpoplatnění dle počtu přehrání videa. Otázkou je, zda by při zajištění dostatečné kvality služby a cenové dostupnosti v kontrastu s reálnou poptávkou byl provoz rentabilní.
7. Závěr V úvodní části práce byl mimo jiné shrnut historický vývoj propojení videa s internetem až do současnosti. Popularita videa na internetu skutečně nezpochybnitelně roste. Zajímavou reakcí na tento trend je třeba přístup elektronických novin, které tradiční formát článků rozšiřují o krátké doplňující videošoty. Tuto popularitu vnímají samozřejmě i komerční subjekty, které věnují stále více prostředků do využití videa jak pro svou mediální prezentaci, tak pro zvýšení atraktivnosti svých webových sídel. Pokud jde o mediální prezentaci, stále častěji se objevuje pojem virální či virální marketing. Pro tyto účely se výborně hodí platformy spojující technické prostředky pro nahrávání videí (a jejich sledování) s efektem sociálních sítí – prim hraje v současné době s obrovskou převahou Youtube. Krásným příkladem z poslední doby je rádoby ilegálně zveřejněné (prý náhodně 81
uniklé)
video
s Jiřím
Macháčkem
a
Janem
Budařem
s v televizi
nevysílanou
(a nevysílatelnou – minimálně před 22 hodinou) verzí reklamy na udílení filmových cen Český lev. Toto video mělo v době vysílání přímého přenosu z udílení cen (5. března 2011) přes 800 tisíc zhlédnutí. Když si uvědomíme, že se video mezi statisíci diváky šíří zdarma a náklady na jeho uveřejnění jsou zanedbatelné, jedná se o jev z marketingového hlediska pokud ne přímo vzrušující, tak minimálně velmi zajímavý. Další variantou je, že video slouží jako doplněk k jinak statickému obsahu stránek kvůli zatraktivnění obsahu či jeho rychlejšímu sdělení návštěvníkovi stránek. Do tohoto segmentu cílí řešení realizované v praktické části této diplomové práce. Jeho výsledek by měl umožňovat nabídnout klientovi způsob jak rozšířit obsah stránek o video a to formou maximálně jednoduchou. Aby byla zajištěna nezávislost na cílové platformě a možnost výsledný klientský modul maximálně customizovat, byla zvolena webová služba jako technologický přístup k řešení tohoto problému. Díky tomu není řešení vázané na konkrétní platformu, programovací jazyk či dokonce konkrétní redakční systém. Je tedy možné danou službu využít i v open source redakčních systémech (či systémech pro správu obsahu) jako je WorldPress, Drupal či Joomla. Na závěr je potřeba uvést, že toto řešení nemusí nutně přinést zisk samo o sobě, ale může sloužit pro zajištění konkurenční výhody, kdy je firma schopná standardně nabídnout v rámci svého redakčního systému funkcionalitu, kterou jiné konkurenční firmy nabídnout nemohou – a to s relativně velmi nízkými náklady. To platí i pro alternativy, kdy bude využita jen samotná webová služba v rámci specifického řešení pro konkrétního klienta. Další devizou tohoto řešení minimálně u některých klientů je skutečnost, že videa zůstávají u poskytovatele webové aplikaci (či webových stránek) a nejsou tedy uloženy u třetích stran. Případně může být pro klienta nainstalován dedikovaný server pro zajištění konverze, uložení a distribuce videa. Tento server pak může být přímo majetkem klienta a může být i fyzicky umístěn tam, kde bude klient požadovat – to je řešení vhodné třeba tam, kde by byla videa poskytována jen v rámci firemního intranetu a neměla by být dostupná mimo něj. Zároveň tak klient dostává i stoprocentní kontrolu nad fyzickým úložištěm videí a může si sám stanovit bezpečnostní politiku atp. Jestli se popisovaná služba v praxi skutečně ujme a hypotetická poptávka se stane poptávkou reálnou přinášející firmě zisk, či alespoň nárůst obratu, ukáže až čas. Jisté předpoklady zde jsou. Pokud by tato situace nenastala, může služba posloužit minimálně jako odrazový můstek a zdroj zkušeností pro další projekty. Přínosem práce by pak byla minimálně dobrá praktická zkušenost použitelná při realizaci podobných projektů.
82
8. Přehled literatury a použitých zdrojů [1]
CROTTY Cameron. Revolution will be netcast. Macworld. 1996. 13, 153-155
[2]
DUNN Jason R. Digitální video. [s.l.] : [s.n.], 2003. 288 s. ISBN 80-251-0038-3
[3]
ČT HD: Česká televize ve vysokém rozlišení [online]. [cit. 2011-02-18]. Dostupný z WWW:
[4]
Zákon č. 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). §30. Sbírka zákonů 2000.
[5]
I v Česku může být stahování filmů a hudby nelegální [online]. [cit. 2011-02-21]. Dostupný z WWW:
[6]
Zákon č. 200/1990 Sb., o přestupcích. §32 - §87. Sbírka zákonů 1990.
[7]
KUBÍN Zbyněk. Nejstahovanějším filmem roku je Avatar [online]. [cit. 2011-0221]. Dostupný z WWW:
[8]
Last mile [online]. [cit. 2011-02-21]. Dostupný z WWW:
[9]
The History of Video Conferencing – Moving Ahead at the Speed of Video [online]. Dostupný z WWW:
[10] About HotelView [online]. [cit. 2011-02-21]. Dostupný z WWW: [11] NORMAN Jeremy. The Beginning of Video Webcasting over the Internet (June 1993) [online]. [cit. 2011-02-21]. Dostupný z WWW: [12] REDFORD J. E. RUTTLE K. S. DOBSON T. M. ICIP '95 Proceedings of the 1995 International Conference on Image Processing (Vol. 1)-Volume 1. IEEE Computer Society Washington, DC, USA. 1995. SBN: 0-8186-7310-9 [13] Community Guidelines [online]. [cit. 2011-02-21]. Dostupný z WWW: [14] KOSEK Jiří. Quo vadis HTML? [online]. [cit. 2011-02-21]. Dostupný z WWW: [15] BOOTH David. Haas Hugo. MCCABE Francis. NEWCOMER Eric. CHAMPION Michael. FERRIS Chris. ORCHARD David. Web Services Architecture [online]. [cit. 2011-02-22]. Dostupný z WWW:
83
[16] KOSEK Jiří. Inteligentní podpora navigace na WWW s využitím XML. Diplomová práce [online]. [cit. 2011-02-22]. Dostupný z WWW: [17] KUBA M. Web Services. Zpravodaj ÚVT MU, 2003, roč. XIII, č. 3, s. 9-14. ISSN 1212-0901 [18] KÖPPL Manuell. Televize jako koncert splněných přání [online]. Chip 09/2010. [cit. 2011-02-22]. Dostupný z WWW: [19] VEČEŘA Zdeněk. Česká televize chystá velký průnik na internet [online]. [cit. 2011-02-23]. Dostupný z WWW: [20] KOPTA Martin. Budoucnost patří sémantickému webu [online]. [cit. 2011-02-23]. Dostupný z WWW: [21] VEČEŘA Zdeněk. Personalizace „Moje ČT“, HbbTV, teletext a poplatky [online]. [cit. 2011-02-23]. Dostupný z WWW: [22] VEČEŘA Zdeněk. Nové weby České televize, oblíbené pořady a sociální sítě [online]. [cit. 2011-02-23]. Dostupný z WWW: [23] Informační společnost v číslech 2010 [online]. [cit. 2011-02-23]. Dostupný z WWW: [24] Využívání informačních a komunikačních technologií v domácnostech a mezi jednotlivci v roce 2010 [online]. [cit. 2011-02-23]. Dostupný z WWW:
[25] KUČERA Rudolf. DVB-T2 - minulost, přítomnost i budoucnost (2) [online]. [cit. 2011-02-25]. Dostupný z WWW:
[26] HOLČÍK Tomáš. TRČÁLEK Antonín. HD video všude kolem nás [online]. [cit. 2011-02-25]. Dostupný z WWW: [27] LOOMIS Jay. WASSON Mike. VC-1 Technical Overview [online]. [cit. 2011-02-25]. Dostupný z WWW:
84
[28] Youtube Fact Sheet [online]. [cit. 2011-02-25]. Dostupný z WWW: [29] Dailymotion Fact Sheet [online]. [cit. 2011-02-25]. Dostupný z WWW: [30] YouTube Facts & Figures (history & statistics). [cit. 2011-02-25]. Dostupný z WWW: [31] POLÁŠEK Roman. Stereoskopie - jak funguje 3D kino [online]. [cit. 2011-02-25]. Dostupný z WWW: [32] Virtuální realita a vizualizace [online].[cit. 2011-02-26]. Dostupný z WWW: [33] RICHARDSON Iain E. G. H.264 and MPEG-4 Video Compression. [s.l.] : [s.n.], 2003. 279 s. ISBN 0-470-84837-5. [34] SCHUMACHER-RASMUSSEN Eric. The Envelope Please: The 2009 Streaming Media Readers' Choice Award Winners [online].[cit. 2011-02-26]. Dostupný z WWW: [35] SCHUMACHER-RASMUSSEN Eric. The 2010 Streaming Media Readers' Choice Award Winners [online].[cit. 2011-02-26]. Dostupný z WWW: [36] Wowza Media Server® 2 – Overview [online]. 2009 [cit. 2011-02-26]. Dostupný z WWW: [37] About 3GPP [online]. [cit. 2011-02-27]. Dostupný z WWW: [38] Introducing Adobe® Flash® Media Server 4. Adobe® Flash® Media Server 4 White Paper [online]. [cit. 2011-02-27]. Dostupný z WWW: [39] Adobe® Flash® Media Enterprise Server 4. Adobe Flash Media Enterprise Server 4 Datasheet [online]. [cit. 2011-02-27]. Dostupný z WWW: [40] Adobe® Flash® Media Server on Amazon Web Services™. Adobe Flash Media Server on Amazon Web Services Datasheet [online]. [cit. 2011-02-27]. Dostupný z WWW:
85
[41] Core server architecture. Flash Media Server 4.0 Technical Overview [online]. [cit. 2011-02-27]. Dostupný z WWW: < http://help.adobe.com/en_US/flashmediaserver/ techoverview/WS5b3ccc516d4fbf351e63e3d119ed944a1a-7ffa.html> [42] Windows Media Services 9 Series Product Information [online]. [cit. 2011-03-01]. Dostupný z WWW: [43] Microsoft Silverlight si v průběhu ZOH nainstalovalo půl milionu českých uživatelů [online]. [cit. 2011-03-01]. Dostupný z WWW: [44] Windows Media Services 2008 Overview [online]. [cit. 2011-03-01]. Dostupný z WWW: [45] IIS Media Services: sdílení multimédií podle Microsoftu [online]. [cit. 2011-03-02]. Dostupný z WWW: [46] CÍLEK Václav. Krajiny vnitřní a vnější. Druhé, doplněné vydání. [s.l.] : [s.n.], 2005. 272 s. ISBN 80-7363-042-7. [47] Welcome to Darwin Streaming Server [online]. [cit. 2011-03-02]. Dostupný z WWW: [48] The Helix DNA™ Server [online]. [cit. 2011-03-04]. Dostupný z WWW: [49] Vzaar API [online]. [cit. 2011-02-28]. Dostupný z WWW: [50] MALÝ Martin. REST: architektura pro webové API [online]. [cit. 2011-03-04]. Dostupný z WWW: [51] Základy služby YouTube [online]. [cit. 2011-03-07]. Dostupný z WWW: [52] Wistia heatmap tracking on your videos [online]. [cit. 2011-03-14]. Dostupný z WWW: [53] O systému FreeBSD [online]. [cit. 2011-03-07]. Dostupný z WWW: [54] ŠTRAUCH Adam. Lighttpd: lehký webserver [online]. [cit. 2011-03-28]. Dostupný z WWW: 86
[55] April 2011 Web Server Survey [online]. [cit. 2011-03-30]. Dostupný z WWW: [56] WOLF Karel. Českému Internetu suverénně vládne Apache [online]. [cit. 2011-0330]. Dostupný z WWW: [57] Mystik’s blog. Jaký jazyk používáte pro tvorbu webových aplikací? [online]. [cit. 2011-04-01]. Dostupný z WWW: [58] Web Programming Language Popularity Contest [online]. [cit. 2011-04-01]. Dostupný z WWW: [59] CASTAGNETTO Jesus. RAWAT Harrris. SCHUMANN Sascha. SCOLLO Chris. VELIATH Deepak. Programujeme PHP profesionálně. [s.l.] : [s.n.], 2002. 216 s. ISBN 80-7226-310-2. [60] KOUBEL M. Vyšlo PHP 5.3.3 a 5.2.14. Končí podpora větve 5.2. [online]. [cit. 2011-04-04]. Dostupný z WWW: [61] Migrating from PHP 5.2.x to PHP 5.3.x - New features [online]. [cit. 2011-04-04]. Dostupný z WWW: [62] Video Delivery: HTTP Pseudo-Streaming [online]. [cit. 2011-04-04]. Dostupný z WWW:< http://www.longtailvideo.com/support/jw-player/jw-player-for-flashv5/12534/video-delivery-http-pseudo-streaming> [63] Configure any webserver to support video streaming [online]. [cit. 2011-04-04]. Dostupný z WWW: [64] Video Delivery: RTMP Streaming [online]. [cit. 2011-04-04]. Dostupný z WWW: [65] RICHTER Stefan. 'Streaming' flv video via PHP, take two. [online]. [cit. 2011-0409]. Dostupný z WWW: [66] VRÁNA Jakub. Webové služby v PHP: XML-RPC a SOAP. [online]. [cit. 2011-0409]. Dostupný z WWW: [67] FFmpeg Documentation [online]. [cit. 2011-03-04]. Dostupný z WWW: [68] VOŘÍŠEK Jiří a kolektiv. Principy a modely řízení podnikové informatiky. [s.l.] : [s.n.], 2008. 446 s. ISBN 978-80-245-1440-6. 87
9. Přehled obrázků, grafů a tabulek Obrázek 1: architektura webových služeb [16].................................................................... 11 Obrázek 2: Google TV: televize budocnosti [18] ................................................................ 16 Obrázek 3: Vizualizace zařízení typu CAVE sestaveném na půdě ČVUT v Praze [32] ..... 17 Obrázek 4: Wowza podporuje řadu protokolů a klientů [36] .............................................. 19 Obrázek 5: Wistia - náhled agregovaného výstupu teplotní mapy [52] ............................... 30 Obrázek 6: Vzaar - schéma použití API [49] ....................................................................... 32 Obrázek 7: Náhled uživatelského rozhraní red. Sys. používaného firmou [zdroj: autor] .... 41 Obrázek 8: Schéma zapojení serverů firmy do internetu [zdroj: autor] ............................... 43 Obrázek 9: Schéma kom. mezi prvky projektu při využití nákupu služby [zdroj: autor] .... 47 Obrázek 10: Schéma architektury projektu [zdroj: autor].................................................... 55 Obrázek 11: Schéma DB [zdroj: autor]................................................................................ 57 Graf 1: Vysokorychlostní přípojky k internetu (v tisících) v ČR [23] ................................. 12 Graf 2: Denní stat. vytížení sítě u serverů v Master internet [zdroj: master internet] .......... 44 Graf 3: Roční stat. vytížení sítě u serverů v Master internet [zdroj: master internet] .......... 44 Graf 4: Roční stat. vytížení sítě u serverů v Master internet [zdroj: master internet] .......... 44 Graf 5: Statistika rozšíření webových serverů [55] ............................................................. 49 Graf 6: Statistika rozšíření webových serverů v ČR [56] .................................................... 50 Graf 7: Jaký jazyk používáte pro tvorbu webových aplikací? [57] ..................................... 51 Tabulka 1: přehled video kodeků [autor] podle [25,26,27,33] .............................................. 8 Tabulka 2: Použití internetu k vybraným činnostem v ČR [25] .......................................... 15 Tabulka 3: Technické vlastnosti Wowza Media Server [zdroj: autor]................................. 20 Tabulka 4: Technické vlastnosti Adobe Flash Media Server [zdroj: autor] ........................ 22 Tabulka 5: Technické vlastnosti Microsoft WMS (IIS Media Services) [zdroj: autor] ....... 24 Tabulka 6: Technické vlastnosti Darwin Streaming Server [zdroj: autor]........................... 25 Tabulka 7: Technické vlastnosti Helix DNA Serveru [zdroj: autor] ................................... 25 Tabulka 8: vlastnosti služby Viddler [zdroj: autor] ............................................................. 29 Tabulka 9: vlastnosti služby Wistia [zdroj: autor] ............................................................... 31 Tabulka 10: vlastnosti služby Vzaar [zdroj: autor] .............................................................. 32 Tabulka 11: vlastnosti služby Panda [zdroj: autor] .............................................................. 34 Tabulka 12: vlastnosti Buto.tv [zdroj: autor] ....................................................................... 35 Tabulka 13: test online video konvertorů [zdroj: autor] ...................................................... 39 Tabulka 14: Konfigurace serveru HP ProLiant [zdroj: autor] ............................................. 45
88
10. Terminologický slovník Termín
Zkratka
Význam
Application Programming Interface
API
Rozhraní pro programování aplikací. Jedná se o souhrn funkcí a tříd určité knihovny či jiného programu, které může programátor využít ve svém programu [autor].
Content Delivery Network
CDN
Koncepce kdy jsou data kopírována na více serverů geograficky od sebe oddělených (globálně rozmístěných) s cílem zajištění rychlejší dostupnosti dat, kdy jsou klientovi dodávána data z nejvýhodnějšího místa tak, aby došlo k optimalizaci datového toku a doby přenosu dat [autor].
Content Management System
CMS
Systém pro správu obsahu. Nejčastěji se jedná o správu webového obsahu. Jde v podstatě o redakční systém k veřejné části webu [autor].
Document Object Model
DOM
Objektový model dokumentu. Objektová interpretace HTML, která umožňuje přistupovat k jednotlivým prvkům HTML formou API [autor].
Flash Video
FLV
Multimediální kontejner podporovaný Adobe Flash Player původně vyvinutý společností Macromedia [autor].
GET
Metoda odesílání dat z webových formulářů, kdy se veškerá data z formuláře předávají v URL (Uniform Resource Locator) [autor].
HTTP Pseudo Streaming
Mechanismus, který umožňuje v rámci protokolu HTTP vytvořit plnohodnotnou alternativu k řešení stream videa pomocí pro něj určených protokolů. Umožňuje ve speciálně připravených souborech stream videa hledat i v částech souboru, které ještě nejsou staženy [autor].
Internet Protocol
IP
Základní pilíř architektury internetu. Protokol definovaný v RFC 791, který určuje způsob zasílání datových paketů v rámci internetu [autor].
JavaScript Object Notation
JSON
Odlehčená alternativa k XML. Platformě nezávislý způsob výměny strukturovaných dat [autor].
Keyframe
MPEG-4 Part 14
V komprimovaném videu se rozlišují klíčové a neklíčové rámečky či obrázky. Neklíčové jsou složené z rozdílu oproti předchozím a klíčové jsou samostatné obsahující plnou informaci o obrazu [autor]. MP4
Multimediální kontejner, který je definován 89
Termín
Zkratka
Význam standardem ISO/IEC 14496-14:2003 [autor].
Net Present Value
NPV
Čistá současná hodnota. Jedná se o rozdíl mezi diskontovanými příjmy z podnikové informatiky (či její konkrétní akce) v porovnání s výdaji na danou činnost [68].
Representational State Transfer
REST
REST je architektura rozhraní navržená pro distribuované prostředí. Na rozdíl od XML-RPC nebo SOAP není REST orientován procedurálně ale datově. REST tedy určuje jak přistupovat k datům [50].
Return On Investment
ROI
Finanční ukazatel rentability investice. Z ROI je možné rovněž zjistit dobu, po kterou se bude investice splácet, než začne generovat kladný výsledek účetnictví [68]. Seekpoint je proměnná určená časem nebo bajty, která nese informaci o pozici, kde se v souboru s videem nachází keyframe [autor].
Seekpoint
Simple Object Access Protocol
SOAP
Stream
Protokol postavený na jazyce XML určený pro výměnu dat prostřednictvím protokolu HTTP [autor]. Proud dat, většinou binárních. V současné době se používá často ve spojení s videem. V tom případě se jedná o proud videa, který umožňuje video přehrávat během jeho současného stahování [autor].
Universal Description Discovery and Integration
UDDI
Platformě nezávislý registr webových služeb postavený na jazyku XML. Využívá se jako jeden z pilířů SOAP [autor].
Uniform Resource Identifier
URI
Jednotný identifikátor zdroje. Popisuje zdroj samotný či způsob jak ho nalézt nebo oboje dohromady [autor].
Video On Demand
VOD
Způsob, kdy je uživateli na jeho požadavek poskytnuto konkrétní video pro stažení/přehrání prostřednictvím sítě internet [autor].
Web Services Description Language
WSDL
Jazyk sloužící k popisu funkcí webové služby. Obsahuje i definice vstupních parametrů a návratových hodnot. K zápisu využívá jazyk XML a je jedním z pilířů SOAP [autor].
