Streaming videa - 2. Protokoly RTSP a RTP - MujMAC.cz - Apple, Mac OS X, Apple iPod

Streaming

Streaming

6. září 2010, 00.00 | Na řadě je plnohodnotný streaming a jeho podpora v Mac OS X a iOS.

Úvodní článek našeho miniseriálu o streamingu videa, pojednával o nejzákladnějších pojmech. Ukázali jsme si také fintu, kterou QuickTime nabízí pro nejjednodušší "streaming" prostřednictvím zcela běžného webového rozhraní a protokolu HTTP, tzv. "Fast Start" (či "Progressive Download"). Dnes se podíváme na skutečný streaming a ukážeme si, jaká je jeho podpora v Mac OS X a iOS.

Streaming vs "progressive download"

Použijme právě výše popsanou fintu, při níž QuickTime spustí video při downloadu souboru hned ve chvíli, kdy je k dispozici dostatek technických informací a začátek vloženého videa i audia a pak plynule přehrává dále, pro zdůraznění rozdílů oproti "opravdovému" streamingu:

1. i. při streamingu se pomocí vhodného protokolu – k tomu se za chvilku vrátíme – předává audio a video (plus potřebné technické informace a řídicí příkazy) v reálném čase, rychlostí odpovídající přehrávání. "Progressive download" naproti tomu využívá maximální dostupné rychlosti linky;
2. ii. řídicí příkazy (např. pozastavení videa, jeho opětovné spuštění, přechod na požadovaný čas videa, zrychlené/zpomalené přehrávání apod.) při streamingu interpretuje server, který na jejich základě změní obsah poskytovaného streamu. "Progressive download" naproti tomu vše interpretuje na straně klienta; serverem je zcela standardní server HTTP, který o tom, že klient přehrává video, "nic neví" – z jeho pohledu jde o běžný download souboru;
3. iii. při streamingu klient vůbec neukládá přijatá data (nanejvýš jejich část cacheuje pro plynulejší přehrávání videa při nespolehlivém připojení; čistě teoreticky by nemělo být zapotřebí ani to). "Progressive download" naproti tomu z principu nutně vždy ukládá celý přijatý soubor na disk a dynamicky přitom přehrává jeho obsah.

Tyto rozdíly mají poměrně zásadní důsledky; podle konkrétní situace a specifické potřeby se mohou ukázat jako výhody nebo jako nevýhody.

Díky bodu (i) např. při streamingu není problém sdílení dostatečně rychlé linky mezi přehráváním videa a dalšími úkoly – streaming nespotřebuje více přenosového pásma než skutečně potřebuje, a zbytek zůstane volný. Dále pak má streaming na dostatečně rychlé lince tu výhodu, že přehrávání může začít okamžitě; "progressive download" musí nejprve načíst část souboru, takže zde nutně je určitý časový posun. Naopak ale zase pokud je připojení příliš pomalé, streaming má zásadní problém, kdežto "progressive download" může vždy pozastavit přehrávání na dobu, než se do souboru načte dostatek dat, a ta pak plynule přehrát.

Z bodu (ii) vyplývají zásadní rozdíly pro klienta – asi nejvýznamnější z nich je možnost přeskakovat dopředu, třeba až na konec videa, aniž by bylo kvůli tomu zapotřebí nejprve načíst celý obsah. Podobně také tato vlastnost streamingu (spolu s bodem (iii)) umožňuje bezproblémové předávání "živého vysílání", tj. např. dat přímo získaných z kamery; při "progressive downloadu" to samozřejmě není možné.

Bod (iii) také do jisté míry problematizuje ukládání a šíření kopií streamovaného videa, což může být významné pro dodavatele zdrojového materiálu (samozřejmě existují a vždy budou existovat způsoby, kterak toto omezení obejít; to ale platí pro jakoukoli ochranu dat).

Je tedy zřejmé, že "progressive download", jakkoli pro některé aplikace velmi šikovný, sám o sobě nestačí, a je zapotřebí podpora skutečného streamingu, přinejmenším pro aplikace typu "živé vysílání". Určité výhody streaming přináší i jinde; u aplikací typu "video on demand" např. umožní klientovi volně "přeskakovat" uvnitř filmu a sníží nároky jeho zařízení na diskový prostor (to je velmi podstatné u klientů typu iPhone).

Protokoly RTSP/RTP

Z výše uvedeného je celkem zřejmé, že "klasické" internetové protokoly – především tedy nejběžnější a nejrozšířenější protokol HTTP – se pro skutečný streaming příliš nehodí (naopak "progressive download" nad ním funguje výtečně, stejně jako třeba nad protokolem FTP).

Proto vznikla dvojice protokolů RTSP ("Real Time Streaming Protocol") a RTP ("Real-time Transport Protocol"), specializovaných právě pro přenos videa (nebo obecně libovolných multimediálních dat) prostřednictvím streamingu.

Protokol RTSP je velmi podobný "webovému" protokolu HTTP; rozšiřuje ale jeho služby především o standardní udržování informace o aktuálním stavu (jak známo, protokol HTTP je bezstavový – každý jeho request je zcela nezávislý na ostatních, a je-li třeba stavové informace, musí se dohánět pomocí triků jako cookies apod.), a také o řadu nových požadavků – např. PLAY/PAUSE. Standardním portem, na němž probíhá komunikace podle protokolu RTSP, je port 554.

Vlastní předávání streamovaných dat ale protokol RTSP neřeší; jeho úkolem je zajistit "domluvu" mezi klientem a serverem o tom, jaká data a jak se mají předat; pro tuto akci samotnou ale slouží protokol jiný. Obecně RTSP umožňuje spolupráci s libovolným protokolem pro předávání datového streamu; typicky se ale používá protokol RTP.

RTP je ve skutečnosti specifikací dvojice úzce spolupracujících spojení: vlastní RTP, jehož prostřednictvím se předávají datové pakety, a pomocný protokol RTCP ("Real Time Control Protocol"), který slouží k řízení kvality přenosu a ke vzájemné synchronizaci. Typicky obě spojení běží na sousedních portech, datový přenos na sudém a RTCP na vyšším lichém; obvykle se využívá protokol UDP (ačkoli podpora TCP je také možná) a porty se obvykle přidělují dynamicky z celého rozsahu 1024-65535. Vlastní obsah datového streamu je samozřejmě ve formátu vhodného kodeku – v současnosti se pro video typicky užívá H.264.

Podpora Apple

Apple samozřejmě podporuje protokoly RTSP/RTP z obou stran, jak na serveru, tak i na klientské straně (ačkoli, jak za chvilku uvidíme, jen v Mac OS X). Standardní součástí instalace Mac OS X Server je QTSS – QuickTime Streaming Server (pro ostatní systémy včetně klientské verse Mac OS X je k dispozici open-source varianta, Darwin Streaming Server).

QTSS funguje na zhruba podobném principu jako server HTTP: při jeho konfiguraci – pro niž je v Mac OS X Serveru samozřejmě k dispozici i pohodlné GUI – zvolíme kořenovou složku, obsahující filmy; server pak automaticky reaguje na requesty typu "rtsp://adresa-serveru/vnořená-složka/soubor-s-videem" poskytnutím odpovídajícího obsahu. K dispozici je samozřejmě i odpovídající podpora pro "živé vysílání".

Volba formátu datových souborů pro streaming závisí samozřejmě do jisté míry na tom, jaký software pro přehrávání předpokládáme na klientské straně; obecně asi nejvhodnější je využití kodeku H.264 pro video a AAC (nebo MP3) pro audio.

Kromě toho je zapotřebí každý soubor s videem, který má být streamován, opatřit doplňkovou stopou, obsahující tzv. "hints" – informace o tom, jakým způsobem je třeba multimediální obsah rozkládat do datových paketů. Tuto stopu je zapotřebí vygenerovat prostřednictvím QuickTime; umožňuje to kupříkladu aplikace QuickTime Player v režimu "Pro".

Video obsahující "hints" lze docela normálně přehrávat, jak lokálně, tak i prostřednictvím "progressive downloadu"; zde ovšem "hints" zbytečně zabírají část přenosového pásma. Pokud není limitující disková kapacita, je proto obecně vhodnější mít na serveru pro streaming samostatné zdroje.

Podpora na straně klienta v Mac OS X je jednoduchá: všechny verze QuickTime Playeru dokáží přímo otevřít a přehrát URL "rtsp://...".

Naopak podpora na straně klienta v iOS není žádná. Firma Apple v poslední době prosazuje namísto RTSP tzv. "HTTP Live Streaming"; RTSP proto v iOS nepodporuje vůbec. Na Webu sice lze najít nějaká řešení třetích stran založená na otevřených knihovnách ffmpeg, ale – přinejmenším v době psaní tohoto článku – se mi nepodařilo najít žádné obecně použitelné a spolehlivé. Chceme-li tedy podporovat také přístroje s iOS, je spíše třeba se řešení založených na protokolech RTSP/RTP vzdát, a využít buď "progressive download" tam, kde to je akceptovatelné, nebo "HTTP Live Streaming".

Právě tomuto protokolu se budeme podrobně věnovat v příštím článku.