Chaos Sanctuary

Už dávno tomu, co jsem napsala článek o vkládání videa do stránek. Občas tam ještě někdo zabloudí, naposledy Sysel. A nabídl se, že mi o tom poví něco víc a nakonec napsal moc zajímavý komentář, vlastně spíš článek, který by tam bohužel zapadl, takže ho dám raději sem, abyste ho všichni, koho by to mohlo zajímat, našli.

Sweet lamo SuE,

vzhledem k tomu, že nejsem GuRu, ale jen sysel, vím jen něco. Patrně mé vyprávění rovněž popudlivé odborníky popudí, ale ti ať si radši čtou své oblíbené manuály a RFCčka a prudí jinde.

Takže proč je vlastně "streamované" video něco zvláštního? Digitální video je uloženo v souboru, soubory si můžeme z Netu stáhnout celkem jednoduše, proč tedy ne video?

Pomiňme skutečnost, že někteří nepřející (nebo snad hamižní) hledají způsoby jak nám video přehrát (po zaplacení), ale nedovolí nám si je schovat, abychom jim příště museli zase zaplatit.

Začnu tedy malým srovnáním: knížka může představovat cca 100KB a já ji budu číst tak alespoň tejden. I na hodně pomalé lince se mi text podaří stáhnout mnohem rychleji, než čtu. :-) Film se stejným obsahem lze shlédnout za hodinku, ale jeho digitální podoba bude podle kvality tak kolem 500MB. Trochu počtů: 500MB/1h to je cca 1000 kilobit za sec. Na Internet po telefonu to už rozhodně není, ale i když nějaké to ADSL nebo Internet po kabelovce to jakoby zvládá, ve skutečnosti se při náhlé tlačenici může snadno stát, že dočasně může rychlost propojení dost podstatně klesnout nebo dokonce na pár chvilek "vypadnout". A to může do sledování videa dosti rušivě zasáhnout. Běžné způsoby přenosu souborů jsou zaměřené na to, aby zaručily bezchybný přenos celého požadovaného souboru - proto obsahují různě vychytralé kontroly chyb a úplnosti a schopnosti opakovaně si vyžádat od serveru části, které byly přijaty s chybami, neúplné nebo vůbec nedošly. Čas (až na nezbytné timeouty) zde vlastně nehraje roli. Ale při sledování filmu, poslouchání písničky je časová závislost mnohem silnější než úplnost a bezchybnost.

A to je vlastně to hlavní, co streaming řeší: přenos časově synchronisovaných dat. Jeho cílem je zajistit přednostně správnou časovou souslednost, (datově orientované protokoly mohou klidně jednotlivé části posílat ve zcela chaotickém pořadí), a nějak se přenést přes dočasné výpadky v propustnosti přenosového kanálu.

Video si vlasně nejspolehlivěji přehrajeme tak, že si jej nejprve stáhneme na svůj počítač (pevný disk) a pak si jej přehrajeme, ale jednak se tím prodlouží doba čekání na film a nad to nemusíme mít zrovna na disku volné místo. Streamované video zajistí "plynulý" přísun potřebných dat, která se vlastně zobrazením "spotřebují".

Ve své domácí síti si mohu dovolit pouštět videa z připojených sdílených disků jiných počítačů nebo lépe serveru. Pokud si však totéž video chci spustit z nabídky na domácím webserveru, prohlížeč, který nemá tušení o rychlosti spojení se serverem, rovnou začne videosoubor stahovat na místní disk a podle typu souboru vybere vhodný plugin nebo externí program pro jeho zobrazení.

Některé programy se dokážou pustit i do zobrazování neúplně stažených videodat a v případě, že přehrávání je rychlejší než stahování, se na chvilku zastaví a po příchodu další porce se samy zas rozběhnou. Ale takové přerušované sledování není moc příjemné a tak je tady Sreaming. K tomu si ještě si připomeneme další slovíčko z oboru: Broadcasting. To je doslova přeloženo (digitální) "vysílání". I když stream znamená v překladu "proud", do překladu slova streaming bych se radši nepouštěl.

Broadcasting i Sreaming používají stejné fígle a jediným podstatným rozdílem je původ šířených dat. Vysílání svá data bere přímo ze snímací kamery, upraví je pro požadovaný datový tok a formát, zatím co Streaming vychází z dat již uložených nebo může šířit data přijatá z digitálního vysílání. Pro úplnost ještě dodejme, že existují streamovací proxy servery, které přebírají video stream a šíří jej do dalšího úseku sítě.

Základním fíglem streamovaného videa je obrácení rolí mezi klentem a serverem. K tomu následující vysvětlivka: server - služebník - poskytuje nějakou službu, kterou odebírá klient. Základním stavem v chování serveru je "naslouchání" a čekání na žádost. Aktivita je tedy primárně na straně klienta, který pošle žádost a server na ni odpoví. Z toho vlastně vyplývá nevhodnost takto rozdělených úloh pro časově synchronisovaný přeos videa: Bez žádosti nejsou data, ale žádost se může zatoulat, opozdit nebo umřít po cestě. A pak by nebyla data a ani kino. Proto se, po domluvě klienta se streamovacím serverem, o který film je zájem, role prohodí a z původního serveru začnou nepřetržitě proudit "klientské" požadavky o zobrazení zrovna té části filmu, kterou právě v tu chvíli film pokračuje ve formě datového proudu. "Serverem", který slouží ke zobrazení je až do konce filmu můj počítač.

Je v tom, jak jinak, několik zádrhelů, které pramení z čím dál komplikovanější struktury celosvětové sítě. Dnes již mnoho klientských (rozuměj domácích či firemních) počítačů, neprodlévá na veřejné síti, ale je umístěno v sítích privátních, oddělených od té veřejné různě komplikovanými firewally. A těm se tyto tanečky moc nelíbí. Pokud je tedy moudrý správce nevybaví nějakou tou "streaming proxy" mají uživatelé uvnitř chráněné sítě smůlu. Další zádrhele způsobuje neochota M$ akceptovat veřejné standardy a s typicky bolševickou filozofií - nas mnógo - se stará o chaos ve formátech i protokolech, často i metodou zdánlivé akceptace standardu, ve kterém však provedou "drobné" změny, takže to naoko vypadá, jak úžasně vycházejí vstříc standardům, ve skutečnosti své zákazníky jen utvrzují v hluboké závislosti na svých chybách.

Pokud se chce někdo vydat cestou mezinárodních standardů, může najít podporu nejen u OpenSource, ale kupodivu i u komerčního prodejce počítačů - fy Apple. Ta nabízí zdarma (jen za registraci) podstatné komponenty pro videostraming na svých stránkách:
http://developer.apple.com/opensource/server/streaming/index.html
kde je možné najít kompletní instalace streaming serveru pro všechny hlavní platformy a dokonce i streaming proxy (mimo M$Windows). Pro lamu mocnou angličtiny není příliš těžké zvládnout instalaci ani kofiguraci. Sám jsem si to zkusil a, světe dif se, ono to fuguje. Smutná zpráva pro skalní uživatele M$Win - Bill jim tuto snadnou cestu ke streamingu tají a tak jim nezbývá než se samostatně (zdarma) zaopatřit vším potřebným: programem QuickTime od Apple (který však není dostupný pro Linux) nebo programem VLC, který je k mání na stránkách:
http://www.videolan.org
Jistě se dá nalézt ještě mnoho dalších přehrávačů videa, které zvládnou spolupráci s Darwin_streaming_serverem a nad to běhá pod Linuxem mnoho dalších streamingových projektů, takže jde jen o to, si vybrat.

Bolavým místem zůstává způsob, jak převést video do potřebného formátu pro streaming. Nerad bych se pokoušel vysvělovat subtilní podrobnosti o komresi videa, byť vnímavé lamě, neboť je to nad rámec povrchního výkladu, ale pokusím se alespoň nasměrovat myšlenky:

Komprimace jednoho obrázku je možná v principu buď ryze "matematicky", tak že po "rozbalení" (rozuměj dekompresi) získáme obrázek úplně shodný, anebo obrázek poněkud pokazíme, aby se nám více smrsknul. Celkem případně se tyto dvě cesty označují jako [beze-]ztrátová komprese. Pokud bychom chtěli odhadnout, s jakými objemy dat musíme počítat pak: surové video pixl po pixlu by pro formát PAL 720x576 - 25fm/s představovalo cca 111GB na hodinu. (cca 32MB/s). Digitální kamery za použití velmi nenáročných fint sníží tento tok na asi 12GB/hod (cca 3MB/s). Ale i to je velmi moc na protlačení po Síti. Paradoxně tu sama povaha filmu nabízí velmi elegantní řešení: Většinou se nemění celý obraz v záběru kamery, ale jen jeho část a komprimace rozdílů vyjde podstatně úsporněji. Problémy nám budou dělat jednak ostré střihy a jednak výpadky v přenosu (stále se věnujeme streamingu), které zhorší návaznost obrázků. I tady se našla pomoc. Při chytrém postupu komprimace lze využít snížených nároků na přenosovou rychlost v běžných scénách k tomu, aby se v předstihu naposílaly bajty, které teprve budou potřeba, až doje ke "střihu". Takovým políčkům filmu, které se přenesou kompletní, bez návaznosti na předcházející políčka se říká klíčová (key frames). Další data poskytují informace o změnách - a těch už nemusí být nutně tolik. Dnešní způsoby komprimace videa dokážou rozpoznat plynulou změnu pozadí scény (švenkování kamery) a posouvání i změny objektů na popředí scény (procházející osoby, mluvící ústa ...). Samozřejmě pro tak úspornou komprimaci a přitom vysokou kvalitu jsou zapotřebí jak speciální programy, tak i spousta času (i na velmi výkonných strojích). Pro lamy i sysly je tu ještě naštěstí cesta mírného pokroku v mezích možností: zatímco špičkové kompresní kodeky (byť již se také najdou fungující mezi OpenSourcem) pracují zdlouhavě a je kromobyčejně náročné je na požadovanou kvalitu nastavit, velmi podstatných úspor dosáhneme prostým snížením požadavků: zmenšením rozměrů na polovic (namísto 720x576 se spokojíme s 360x288 nebo jen 320x240) sníží se datový tok na čtvrtinu. Pokud ještě k tomu snížíme počet snímků z 25(24 - je běžná filmová frekvence) za sec na 15(až 12) za sekundu (amatérské filmy se běžně točily 16 obr/sec), klesne potřebný datový tok ještě skoro na polovinu. Oželíme-li trochu kvality lze se dostat ještě níž. Takto lze dvaceti minutový klip dostat při koukatelné kvalitě pod 50MB (300kbit/sec). Málo využívanou fintou je parametr, kterým se sdělí přehrávači videa, že má při přehrávání změnit velikosti pixelů, dokonce pro výšku i šířku zvlášť. To se běžně využívá na DVDčkách, kde je vnitřní formát stále stejný (720x576), ale pro širokoúholu projekci se jen změní poměr stran :-)

Sloučením takových fint lze předvést koukatelné video i s tokem pod 100kbit/s.

Nelze ovšem zapomínat na zvuk, který může pak mít paradoxně větší nároky než video - běžně požívaná komprimace (MPEG4-AAC) vyžaduje 128kbit/s pro stereo zvuk. Spokojíme-li se ovšem s kvalitou telefonního hovoru, mohou tato požadavky klesnout až na 4kbit/s. Ale to je už opravdu pod hranicí srozumitelnosti. Za rozumné lze považovat sloučení zvukové stopy do monofoního kanálu se vzorkováním kolem 22kHz a toku cca 32 kbit/s.

Jak na to?

Pro zanícené čtenáře manuálů je možné doporučit velmi chytrý a bohatě vybavený program MPlayer/MEncoder
http://www.mplayerhq.hu
který nabízí plno fíčur, ale naprosté uživaltelské nepohodlí. Nicméně v jeho prospěch lze uvést, že kdo by se chtěl pustit do nějakého rozsáhlejšího projektu, uvítal by jeho schopnost zpracovávat do omrzení hafo klipů se stejnými parametry v dávce.

Pokud máte vaše záznamy z dovolených zpracované do podoby domácích DVDček, pak vám bezpochyby dobře poslouží prográmek HandBrake
http://handbrake.fr
který nabízí propracované GUI pro platformu MacOSX i M$Win, ale zároveň i variantu pro ovládání z příkazové řádky (CLI = Comman Line Interpreter).

Některé přehrávače videa nabízejí i více či méně použitelný export do formátu MPEG4 vhodného pro streaming, ale ne vždy fungují spolehlivě. Již zmíněný přehrávač VLC dokonce sám nabízí otevření streamu, ale nevím, že by se tato jeho fíčura houfně používala.

Uživatelé QuickTime si mohou za cca $30 od Apple koupit seriové číslo pro odemčení schopností QuickTime Playeru exportovat video do různých formátů včetně MPEG4. Viděl jsem to v chodu, ale jsem nad tím trochu na rozpacích - MPEG4 standard je původní dítě Applu, ale ten dnes podporuje jen jednu jeho část - kodek H264, který je sice velmi kvalitní, existuje jeho veřejná definice a také úspěšný OpenSourcový projekt x264, který je čím dál lepší, ale ... úspory jsou sice velké, nicméně náročnost na výkon stroje který video přehrává jsou nesrovnatelně vyšší než u prostého MPEG4 kodeku. V menších rozměrech to možná není tak drastické, ale postupně jsem sám od H264 (x264) kódování odstoupil. Datový tok mi sice asi o 20-30 % narostl, ale mohu přehrávat i na starších strojích. A jsme u toho: aby se mohly leckteré vymoženosti videokompresních algoritmů uplatnit, musejí mít možnost prohlédnout si videoklip alespoň jednou předem. Říká se tomu dvou- nebo více- průchodová komprimace (multipass). A tu Apple i v odemčeném QuickTimu nabízí pouze s kodekem H264, ačkoli je principielně možná a užitečná i pro prostý formát MPEG4. Hm, škoda.

Co napsat závěrem? Pro krátké videoklípky je cesta lamy naprosto vyhovující, ať si remcalové klidně zapracují na svém infarktu. Nevyžaduje na straně serveru žádné komplikované instalace a překódování videa už pro lamu taky není problém. Podobně se dají využívat i MPEG1,2,4 formáty s vhodnými pluginy (QuickTime např.). 2-3 MB pro dočasné uložení mi na disku pořád zbývají. Pokud se chystám přehrávat dvouhodinový film, pak bude asi zapotřebí sofistikovanější cesty naznačené výše. Pro digitální televizní vysílání to znamená obrátit se na profesionální firmu. HDTV je zatím ještě hudba budoucnosti, ale už ne moc vzdálené.

Ale nakonec ještě hm poznámka. Mnoho počítačové a komunikační techniky bylo vyvinuto a vnuceno do užívání pod heslem: technika nás spojuje. Nostalgicky si vzpomínám, jak zahalen dekou a s deštníkem poruce jsem se tulil ke své dívce v Holešovském letním kině a usilovně jí žmoulal ruku, stejně jako nepočítaně dalších dvojic, které zrovna jako my to doma schytaly za časné ranní návraty domů. Nespojovalo nás to jako generaci víc než to dnešní individuální domácí brouzdání po Internetu, e-maily a eSeMeSky?

sysel

P.S. lamy, be happy ...

Lamy jsou happy a děkují syslům :-)