Vývoj aplikací pro platformu MHP Ing. Kamil Bodeček, Ing. Vojtěch Stejskal, Bc. Vít Švanda, Doc. Ing. Vít Novotný PhD. Ústav telekomunikací, FEKT VUT Brno kamil.bodecek@phd.feec.vutbr.cz, v.stejskal@phd.feec.vutbr.cz, novotnyv@feec.vutbr.cz V článku jsou představeny základy interaktivních multimediálních aplikací dle standardu MHP (Multimedia Home Platform) pro digitální pozemní televizní vysílání DVB-T (Digital Video Broadcasting - Terrestrial). Hlavní částí článku je rozbor problematiky vývoje těchto aplikací, který je dokumentován na příkladu emailového klienta využívajícího zpětný kanál k přijímání i odesílání elektronické pošty. Obsah 1. Úvod do multimediálních aplikací v sítích DVB-T 2. Vývoj MHP aplikací 3. Závěr Literatura 1. Úvod do multimediálních aplikací v sítích DVB-T Jednou z největších výhod přechodu z analogového na digitální pozemní televizní vysílání je možnost využívání interaktivních služeb. Aby bylo možné tyto služby provozovat na straně uživatele bylo nutné definovat standard, který by řídil jejich spouštění a celkovou správu. V minulosti vzniklo několik takových na sobě nezávislých platforem, které nebyly vzájemně zcela kompatibilní. To bránilo jejich většímu rozvoji a docházelo tak i k tříštění trhu. Sjednocení trhu bylo hlavní myšlenkou, která vedla k zahájení vývoje standardu MHP. MHP vyvíjela stejná skupina, která stála za vývojem standardu DVB-T, proto je MHP kompatibilní pouze se standardy DVB-T. To se ovšem neslučuje s myšlenkou globálního využití MHP, protože v dalších zemích (jako Japonsko, či USA) je využíván jiný standard než DVB-T. Tento problém byl vyřešen vytvořením standardu GEM (Globally Executable MHP), který vychází přímo z MHP, ale jsou z něj odstraněny specifikace standardu DVB, čímž je zajištěna kompatibilita i s jinými standardy. Proto je často uváděno, že určitá aplikace je určena jak pro platformu MHP, tak i pro GEM. Jak již bylo uvedeno je hlavním úkolem platformy MHP spouštění a správa interaktivních aplikací. Tyto aplikace mohou být napsány buď v jazyce Java nebo HTML. Protože platforma MHP definuje řadu rozšíření a omezení ve schopnostech obou jazyků, nejsou takto napsané aplikace slučitelné se standardní Javou či HTML. Pro rozlišení se tedy MHP verze Java aplikací označuje DVB-J a HTML verze DVB-HTML. Volbou těchto knihoven je zajištěna nezávislost vývoje MHP aplikací na jediné hardwarové platformě či operačním systému [1], [2] a [3]. 1.1. Přenosový řetězec v sítích DVB-T V DVB-T jsou data vysílána v tzv. multiplexu, což je datový tok vysílaný v pásmu jednoho běžného analogového kanálu (8 či 7 MHz). Kapacita tohoto pásma je při modulaci 64-QAM přibližně 22 Mbit/s. Na vysílací straně jsou analogové signály videa komprimovány metodou MPEG-2 a to s výstupním datovým tokem od 3 do 6 Mbit/s. Audio signály jsou komprimovány s výstupním tokem od 96 až do 384 kbit/s. Do jediného multiplexu se tedy 61-1
vejde 4 až 5 televizních kanálů, které jsou multiplexovány spolu s řídicími daty a objektovým karuselem. Výsledný datový tok je ve formátu MPEG-2, který je tvořen elementárním datovými toky. Každý elementární tok obsahuje buď komprimované MPEG-2 video, či MPEG-2 audio, nebo data zapouzdřená v MPEG-2. 1.2. Objektový karusel Digital Storage Media - Command and Control (DSM-CC), neboli objektový karusel je transportní protokol (souborový systém), prostřednictvím kterého je možné přenášet aplikace mezi distributorem a přijímačem. Datový tok je složen ze dvou základních částí. První část tvoří samotná data aplikací (jednotlivé soubory). Druhá část přenáší informační tabulku aplikací AIT (Application Information Table), která obsahuje informace přiřazující dané soubory konkrétní aplikaci. AIT může dále obsahovat řídící kódy: AUTOSTART, PRESENT, DESTROY, KILL, PREFETCH, REMOTE. Aplikace, která obsahuje kód AUTOSTART, bude spuštěna automaticky po načtení do přijímače. To umožňuje spustit aplikaci, která přímo souvisí s právě vysílaným programem. Pokud přijímač přijme aplikaci s řídicím kódem PRESENT, uloží ji do seznamu dostupných aplikací a uživatel si ji může případně spustit. Aplikace s řídicím kódem KILL či DESTROY jsou přijímačem vypnuty. Toho je možno využít například při skončení určitého programu, se kterým byla aplikace svázána. Rozdíl mezi kódem KILL a DESTROY je, že při KILL má uživatel možnost v dané aplikaci pokračovat. Při kódu DESTROY je aplikace vždy uzavřena. Kód REMOTE přikazuje přijímači přejít na určitou službu za účelem spuštění aplikace poskytované danou službou. AIT poskytuje i informaci udávající pro jakou verzi MHP je aplikace určena. To dává přehrávači možnost rozhodnout zda danou aplikaci zahrne do seznanému dostupných služeb či ne. 1.3. Rozdělení interaktivních služeb S neúplnou interaktivitou (bez zpětného kanálu) Typickým představitelem interaktivní služby bez zpětného kanálu je Teletext, tedy služba známá již z analogového televizního vysílání. Divák má možnost listovat pouze v informacích, které jsou předem nahrány do paměti televize. U analogového vysílání se tyto informace přenášejí v prvních čtyřech řádcích půlsnímkového zatemňovacího impulsu. V prostředí digitální televize jsou potřebné informace (aplikace) přenášeny do SetTopBoxu prostřednictvím již zmíněného objektového karuselu (DSM-CC). Aplikace bez zpětného kanálu, tedy bez možnosti komunikace ve směru od uživatele, nemohou být považovány za plně interaktivní. Všechny takovéto aplikace se tak dají v prostředí digitální televize považovat za Teletext, který je ovšem výrazně audiovizuálně vylepšen. S úplnou interaktivitou (se zpětným kanálem) Aby byla služba skutečně plně interaktivní je nutné zajistit komunikaci i ve směru od uživatele (SetTopBoxu). V oblasti digitální televize existovalo několik řešení jak tohoto obousměrného přenosu dosáhnout. Nadějně vypadala technologie DVB-RCT (DVB-Return Channel Terrestrial), která předpokládala umístění malého vysokofrekvenčního vysílače ke každému uživateli. Tento vysílač by realizoval zpětné spojení s poskytovateli digitálního vysílání. Technologie předpokládala nesymetrickou vzájemnou komunikaci mezi uživatelem a poskytovatelem. Pro zpětný kanál by tak byla dostačující i relativně nízká přenosová rychlost malých vysílačů. Ve směru od poskytovatele mělo být (v okruhu do 3,5 km od 61-2
vysílače) dosahováno přenosové rychlosti, až několika Mbit/s. Důvod, proč nedošlo k uvedení této technologie do praxe, je nízká kapacita multiplexů (kmitočtového pásma). U nás by tato kapacita mohla být dostačující po úplném ukončení analogového vysílání (2009-2010), ovšem v této době budou zpětné kanály zcela jistě realizované jinými technologiemi. U dnešních SetTopBoxů je pro tvorbu zpětného kanálu využíváno především technologie Ethernet a integrovaného telefonního modemu. Ethernet umožňuje začlenění SetTopBoxů do lokální sítě a následného využití kterékoli dalšího připojení k internetu (ADSL, ISDN, 802.11). Uživatel mající SetTopBox se zpětným kanálem, bude moci například přijímat a odesílat emailové zprávy, prohlížet internetové stránky, provádět internetové nákupy, stahovat filmy, hrát počítačové hry atd. Všechny tyto příklady záměrně nevyužívají pro "cestu" k SetTopBoxu objektového karuselu, oba směry komunikace jsou realizovány výhradně prostřednictvím zpětného kanálu. Pojem "zpětný kanál", tak ztrácí svůj pravý význam, který vyjadřoval výhradně simplexní přenos. Obr.1: Přenosový řetězec DVB-T a DSM-CC. 2. Vývoj MHP aplikací Pro ověření možností, které poskytuje platforma MHP byla zvolena aplikace poštovní klient. Ta představuje službu s úplnou interaktivitou, která využívá "zpětný kanál" pro obousměrnou komunikaci. Využití objektového karuselu bylo zamýšleno pouze jako prostředku sloužícího pro přenos samotné aplikace do paměti SetTopBoxů. Pro vývoj aplikace bylo využito prostředí IRT MHP RI 1.0.2.r3final, což není vývojové prostředí v pravém slova smyslu, neobsahuje totiž žádnou aplikaci umožňující vytváření a případnou kompilaci zdrojového kódu. Obsahuje pouze JavaTV knihovny a Java aplikaci simulující běžný SetTopBox (viz. Obr. 2 ) ve verzích MHP 1.02, MHP 1.03, MHP 1.1 [4], [5]. 61-3
Obr.2: Simulátor SetTopBoxu od IRT. Pro tvorbu a kompilaci samotného zdrojového kódu byl zvolen programovací nástroj JBuilder 2005, který byl doplněn o knihovny JDK1.1.8M (MHP 1.0.2 Appl-Compile). Tímto doplněním jsme získali nástroj pro vytváření MHP-J aplikací prostřednictvím souboru knihoven JavaTV. Takto vytvořená kompilovaná aplikace byla nahrána do virtuálního objektového karuselu simulátoru IRT, kde mohla být testována její funkčnost. Následuje výpis nejdůležitějších vlastností aplikace MHP Email 2.0: Zpětný kanál v simulovaném prostředí byl vytvořen pomocí běžného ethernetového rozhraní. Stejným způsobem byl zpětný kanál realizován i ve skutečném SetTopBoxu, kde je možné dále využít připojení prostřednictvím telefonního modemu. Příjem emailových zpráv je realizován protokolem POP3, pro odeslání nových zpráv je využito protokolu SMTP. Pro správné zobrazení diakritiky bylo nutné vytvořit dekodér převádějící přijaté sedmi bitové zprávy zpět do osmibitového tvaru. Pokud přijatá zpráva obsahuje přílohu je název této přílohy zobrazen spolu s příslušnou ikonou souboru. Samotná data přílohy jsou z důvodu mále paměti SetTopBoxu vymazána. V SetTopBoxu je možné uložit a následně využít rozepsanou zprávu. 61-4
Ovládání aplikace je přizpůsobeno podmínkám SetTopBoxu, což znamená ovládání výhradně dálkovým ovladačem, proto jsou nejdůležitější funkce aplikace řízeny přes čtyři barevná tlačítka na dálkovém ovládání. Jsou to stejná tlačítka běžně využívaná pro ovládání teletextu. Obr.3: Vzhled aplikace MHP-Email 2.0: režim přihlášení a režim hlaviček zpráv. 61-5
Obr.4: Vývojový diagram aplikace MHP-Email 2.0. 2.1. Kompatibilita vývojových prostředí Osmosys a IRT Po odladění aplikace v simulovaném prostředí bylo možné přistoupit k testování na skutečném SetTopBoxu. K přenosu aplikace do přijímače bylo využito vývojového prostředí Osmosys, ten umožňuje nejen přenos aplikace (přes sériové rozhraní), ale i její vývoj a 61-6
simulaci. Systém Osmosys je tak přímou konkurencí simulátoru IRT. Protože prostředí IRT disponuje certifikátem o slučitelnosti se standardem MHP ve verzi 1.02 bylo předpokládáno, že se aplikace na SetTopBoxu (a zároveň i v simulaci Osmosys) bude chovat zcela stejným způsobem. Ve skutečnosti ovšem docházelo k mnoha závažným problémům, a to v celém průběhu programu. Například se nezobrazovaly některé grafické komponenty, či byly změněny jejich rozměry a umístění. V některých případech nebyly funkce dané komponenty vůbec vykonány, pro představu jeden konkrétní příklad: "Shortcuts" je funkce, která byla vytvořena speciálně pro MHP-J aplikace a její činností je spouštění dalších funkcí programu v závislosti na stisknutí určitého tlačítka na dálkovém ovladači. V simulátoru IRT pracovala tato funkce zcela korektně, ale ve skutečném SetTopBoxu (stejně jako v simulaci Osmosys) nepracovala vůbec. Důležitým poznatkem je, že aplikace se v simulaci Osmosys chovala vždy zcela stejně jako v SetTopBoxu a to včetně všech výše uvedených problémů. Mohlo by se tedy zdát, že je výhodnější vyvíjet MHP-J aplikace v prostředí Osmosys, který evidentně lépe simuluje podmínky skutečných SetTopBoxů. Zde je ovšem důležité podotknout, že programové vybavení SetTopBoxu, na kterém proběhlo testování, pochází ze systému Osmosys, stejně tak existují typy SetTopBoxů s programovým vybavením od systému IRT. Pro širokou kompatibilitu vytvářených aplikací je tedy nutné jejich testování jak na simulátoru Osmosys, tak i na simulátoru IRT. 3. Závěr V tomto článku byla nastíněna funkčnost a popis vývoje interaktivních aplikací v sítích pozemního digitálního televizního vysílání DVB-T. Jako příklad takovéto MHP-J aplikace jsme využily poštovního klienta MHP Email 2.0. Ten využívá běžných poštovních protokolů SMTP a POP3. Umožňuje tak příjem a odesílání elektronické pošty prostřednictvím MHP SetTopBoxu vybaveného zpětným kanálem. Při vývoji této aplikace byl kladen důraz na prostředí SetTopBoxů, které je specifické, nejen ovládáním které probíhá prostřednictvím dálkového ovladače, ale i zobrazením (rozlišením PAL). Vzhledem k pomalému postupu digitalizace pozemního vysílání u nás, jsou i interaktivní služby ve svých počátcích. Jejich další rozvoj bude záležet na jejich propagaci a cenové dostupnosti, jak aplikací, tak SetTopBoxů podporujících technologii MHP. Limitujícím faktorem interaktivních aplikací využívajících zpětný kanál bude také cena a způsob připojení k Internetu. Samotný vývoj aplikací pro platformu MHP je více komplikovaný a méně pohodlný, než vývoj například appletů. Problémem je špatná kompatibilita mezi různými výrobci SetTopBoxů. V článku byl rozebrán příklad nekompatibility implementací u prostředí IRT a Osmosys. Nepohodlnost je zaviněna absencí designérů pro MHP ve vývojových prostředích. Vzhledem k teprve začínajícímu rozvoji MHP-J aplikací, můžeme předpokládat, že tyto nedostatky budou do budoucna odstraněny. Prohlášení: Tento článek vznikl za podpory výzkumného projektu MSM0021630513 "Elektronické komunikační systémy a technologie nových generací" a projektu AVČR 1ET301710510. Literatura [1] MORRIS, S. The MHP Tutorial. Dostupné z WWW:http://www.interactivetvweb.org/tutorial/mhp/index.shtml [2] MORRIS, S. The JavaTV Tutorial. Dostupné z WWW:http://www.interactivetvweb.org/tutorial/javatv/index.shtml [3] MORRIS, S., CHAIGNEAU, A. S., Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Focal Press, 2005 61-7
[4] EVAIN, J.-P. MHP - the Multimedia Home Platform. Dostupné z WWW:http://www.dvb.org/documents/white-papers/WP02%20(MHP).pdf [5] DVB. Multimedia Home Platform (MHP) Specification 1.1.2. Dostupné z WWW: http://www.mhp.org/mhp_technology/mhp_1_1/mhp_a0068r1.zip 61-8