Streaming videa - 3. HTTP Live Streaming - MujMAC.cz - Apple, Mac OS X, Apple iPod

Streaming

Streaming

13. září 2010, 00.00 | Protokol HTTP Live podrobněji, popis jeho principu i odpovídající konfigurace na straně serveru a použití na straně klienta - to vše v posledním dílu miniseriálu o streamingu.

Z minula víme, že v operačních systémech Mac OS X a iOS, firma Apple v poslední době prosazuje místo protokolů RTSP/RTP tzv. "HTTP Live Streaming" – jeho specifikaci předložila IETF jako návrh standardu a na základě zkušeností s firmou Apple vcelku můžeme předpokládat, že se tento protokol standardem skutečně stane a bude běžně užívaný. Naopak protokoly RTSP/RTP firma Apple v iOS nepodporuje vůbec.

Dnes se proto podíváme na protokol HTTP Live podrobněji; popíšeme si jeho princip i odpovídající konfiguraci na straně serveru a použití na straně klienta.

Základní princip

Streamingový protokol HTTP Live je navržen tak, aby

• mohl pracovat nad zcela standardním protokolem HTTP bez jakýchkoli speciálních rozšíření či doplňků;
• přitom ale podporoval zhruba srovnatelnou úroveň služeb na straně klienta i serveru, jako protokoly RTSP/RTP.

Je zřejmé, že úplně doslova to možné není z důvodů, které jsme rozebírali v úvodní části minulého článku; firma Apple nicméně vymyslela několik velmi jednoduchých a přitom efektivních "fint", které umožní značné přiblížení možnostem skutečného streamingu (a jak uvidíme níže, v některých případech dokonce i jejich překonání).

Základní princip protokolu HTTP Live je velmi jednoduchý. Vlastní audiovizuální data jsou "rozsekána" na úseky – typicky cca desetisekundové, ačkoli protokol umožňuje práci s úseky libovolné délky –, jež jsou uloženy v samostatných souborech. Stream pak je reprezentován tzv. indexovým souborem; to je soubor smluveného (v zásadě textového) formátu M3U8, který pomocí standardizovaných tagů popisuje vlastní video a obsahuje také odkazy na jeho jednotlivé úseky.

To je vlastně vše: server jak úseky, tak i index zpřístupní prostřednictvím zcela standardního serveru HTTP.

Klient načte index, a podle něj (a podle požadavků uživatele) načítá vhodné úseky a ty přehrává.

Vidíme, že podobně jako tomu bylo u "progressive downloadu", opět nejde o streaming v pravém slova smyslu (jak ostatně při použití standardního serveru HTTP ani dost dobře není možné); jde ale o určitý kompromis, který přináší řadu výhod. Připomeňme si body (i)-(iii) z minulého článku, v nichž jsme si ukázali specifické vlastnosti streamingu oproti "progressive downloadu" a podívejme se podobně na protokol HTTP Live:

i. pro předávání dat se v HTTP Live využívá maximální dostupné rychlosti linky stejně jako při "progressive download"; tato rychlost ale slouží jen pro přenos poměrně malých datových úseků. Tyto úseky si nicméně klient vyžádá teprve ve chvíli, kdy je skutečně potřebuje; v dlouhodobém průměru tedy jsou data přenášena podobně jako při streamingu rychlostí, odpovídající rychlosti přehrávání;

ii. řídicí příkazy (např. pozastavení videa apod.) se v HTTP Live stejně jako při "progressive downloadu" interpretují na straně klienta – z pohledu serveru jde o zcela běžný download souborů;

iii. klient HTTP Live musí data cacheovat, ale jen v omezeném rozsahu: typicky klient udržuje indexový soubor a tři datové úseky.

Výsledkem jsou vlastnosti zhruba srovnatelné se streamingem: sdílení datové linky není zásadní problém, protože HTTP Live ji vytěžuje jen velmi krátkodobě; živé vysílání stejně jako "přeskakování dopředu" je snadné zajistit. Ukládání neautorizované kopie dat je zhruba stejně obtížné, jako u klasického streamingu. Za jediné výraznější nevýhody HTTP Live lze považovat to, že je méně efektivní (tedy typicky vyžaduje přenos většího množství dat pro dosažení stejného efektu jako streaming), a také neumožňuje okamžitě spustit přehrávání – nejprve se musí načíst minimálně index a jeden celý úsek (v praxi vzhledem k implementaci spíše více úseků).

A jak naživo

Podpora "živého vysílání" v HTTP Live funguje stejně jednoduše, jak jednoduchý je princip celého protokolu: dodavatel materiálu se rozhodne, jak velké "časové okno" je ochoten klientům poskytnout. Pak prostě po přijetí nových dat v délce úseku (typicky – ale ne nutně – tedy 10 sekund)

• přidá na disk nový soubor, obsahující aktuální úsek;
• smaže nejstarší z úseků, jež byly na disku odminula;
• upraví odpovídajícím způsobem indexový soubor.

Klient na základě tagů, jež načetl při prvém otevření indexu, ví, zda vůbec a jak často je třeba obsah indexu obnovit – vždy po uplynutí časového úseku, odpovídajícího segmentu, tedy index načte znovu z původní adresy, a může uživateli prezentovat aktuální data.

Vidíme, že výhodou HTTP Live zde je to, že klient má k dispozici nejen zcela aktuální vysílání, ale také záznam jeho historie v rozsahu předem zvoleného časového okna; může se tedy snadno třeba vrátit a znovu si přehrát zajímavý moment (a pak aktuální vysílání dohnat rychloposuvem), nebo může sledovat celý přenos v režimu "time slip", kdy reálný čas dožene teprve ve chvíli, kdy vysílání skončí. U streamingu nic z toho nebylo možné (pokud se o to nepostaral klient sám cachováním dat v lokální paměti). Za zmínku stojí také to, že struktura indexového souboru umožňuje velmi snadno streaming pořadů, jež mají nadále zůstat v archivu: v takovém případě se při "živém vysílání" sice průběžně přidávají nové úseky "na konec", ale staré se ponechávají beze změny; po ukončení pořadu se pak jen do indexu doplní značka, identifikující ukončený ("neživý") záznam – a je hotovo.

Naopak zřejmou nevýhodou HTTP Live je to, že aktuální přenos ve skutečnosti není zcela aktuální; přinejmenším o délku jednoho úseku je oproti reálnému času pozadu. V praxi to obvykle není problém, ale pro některé konkrétní aplikace to může být omezující – představme si např. televizní soutěž, v níž diváci reagují na položenou otázku telefonicky a vyhrává první.

Kodeky a kontejnery

Ačkoli výše popsaný princip by v zásadě mohl fungovat nad libovolným kontejnerem a kodekem, firma Apple v současnosti podporuje jen velmi omezený výběr:

• přenosovým "kontejnerem" je transportní formát MPEG-2 (který se jinak v praxi využívá vyjma DVD a digitálního televizního vysílání jen minimálně, proto jsme se jím dosud nezabývali). Důvod této volby je zřejmý: MPEG-2 lze triviálně dělit na úseky a tyto opět spojovat;
• video musí používat kodek H.264, a to konkrétně profil "Baseline Level 3" (starší systémy podporují pouze 3.0, pro novější klienty lze použít 3.1);
• audio kodek je buď AAC (varianty HE-AAC nebo AAC-LC, stereo, max. 48 kHz) nebo MP3.

Další možnosti

Protokol HTTP Live podporuje řadu dalších služeb, z nichž některé přinášejí podstatné výhody i oproti streamingu RTSP/RTP; vyjmenujeme si jen ty nejpodstatnější bez detailního popisu konkrétního mechanismu:

• šifrování obsahu: úseky, obsahující data, mohou být zašifrovány, takže k nim má přístup jen autorizovaný uživatel, ačkoli jsou k dispozici prostřednictvím otevřeného protokolu HTTP (úseky lze v principu zpřístupnit i prostřednictvím vrstvy SSL, ale je to obvykle neakceptovatelné, protože takové soubory dost dobře nelze cacheovat na úrovni proxy serveru). Protokol sám opět podporuje zcela obecné šifrování; Apple v současnosti nabízí šifrování AES s klíčem délky 128 bitů;
• dynamická volba kvality: indexový soubor může obsahovat odkazy na několik alternativních souborů pro jeden a týž úsek videa; tyto soubory se mohou lišit v kvalitě (a tedy velikosti souboru a tedy v náročnosti na rychlost linky). Klient si pak může dynamicky vybrat vhodný úsek podle momentální kvality připojení; dokonce i v průběhu přehrávání tak může podle aktuálních podmínek dynamicky kvalita růst i klesat podle potřeby. Protokol HTTP Live dokonce jako zadní vrátka pro nejhorší případy podporuje i stream audio-only se statickým obrázkem;
• výše uvedená redundance může sloužit také jako automatická ochrana před výpadkem serveru – pokud klient nemůže ze serveru načíst požadovaný úsek (nebo obnovit obsah indexu při "živém vysílání"), může na základě dat uložených v indexovém souboru automaticky přejít na alternativní URL.

Serverové služby

Je zřejmé, že pro prezentaci videa prostřednictvím protokolu HTTP Live nepotřebujeme žádný speciální server: stačí zcela libovolný server HTTP (v systému Mac OS X tedy nejspíše standardní Apache). Obvykle není zapotřebí ani žádné specifické nastavení; jen u indexů M3U8 pro "živé vysílání" je samozřejmě nutno specifikovat, že nesmějí být cacheovány na proxy serverech po delší dobu, než je délka úseku.

Potřebujeme ovšem software, který sestaví samotný indexový soubor a připraví datové úseky.

Apple v současnosti pro tento účel nabízí skupinu řádkových příkazů – to je v tomto případě mnohem praktičtější než aplikace s grafickým uživatelským rozhraním, neboť jich lze snadno využívat ve skriptech. V novějších instalacích Mac OS X by měly být již předinstalovány; v každém případě je lze získat zdarma (ale po registraci) na stránkách podpory Apple v oddílu "Downloads" ve skupině "QuickTime". Po instalaci je nalezneme ve složce /usr/bin. Ponecháme-li stranou pomocné a verifikační prostředky, jde především o dvojici příkazů

• příkaz mediastreamsegmenter dokáže číst živé video ze streamu, a generovat úseky i indexový soubor pro "živé vysílání" podle požadovaných atributů;

• podobně příkaz mediafilesegmenter (v současné dokumentaci Apple chybně nazývaný "filestreamsegmenter") načte video a audio ze zadaného souboru, podle potřeby je automaticky převede do transportního kontejneru MPEG-2, a sestaví pro celý film odpovídající úsekové soubory i index.

Klient

Podporu na straně klienta nalezneme v Mac OS X tam, kde je k dispozici QuickTime X; iOS podporuje plně HTTP Live streaming ve versích od 3.0 nahoru. Stačí v přehrávači videa – v iOS i přímo v Mobile Safari – otevřít indexový soubor (zde je příklad Apple), a klient spustí přehrávání.

Samozřejmě, pro spolehlivé přehrávání v různých browserech (včetně Safari v Mac OS X) je vhodné indexový soubor neotevírat přímo (např. tedy nepoužít tag <A HREF>), nýbrž prostřednictvím tagu <video> – zde je opět příklad Apple, jeho obsah je triviální, v podstatě jde pouze o

<video src="bipbopall.m3u8" controls autoplay>

kde odkaz "src" vede na výše uvedený index. Problematiku vkládání videa do webových stránek – vzhledem k dost nejednotné podpoře různých možností v různých prohlížečích dost netriviální – ale, jak jsme si řekli hned na začátku, v tomto miniseriálku řešit nebudeme.