R. SEDLMEYER Multimedia Home Platform — Standard 1.0 · Komposit Standardbildschirm. 3. Services und Applikationen Kernstück der Innovation beim Entwurf einer MHP war stets die

R. SEDLMEYER

Multimedia Home Platform— Standard 1.0.1

1. Einleitung

In einer Welt der konvergierenden Me-dien kann es nicht genügen nur die Über-tragung von Audio- und Videosignalen indigitaler Form zu spezifizieren, um damitdie Zukunft des digitalen Fernsehens zusichern. Auf Grund der Erfahrungen ausdem Internet erwarten die Nutzer auch imFernsehen Informationen und Services ininteraktiver und multimedialer Form. DieRealisierung interaktiver Services basiertdabei immer auf dem so genannten „Ap-plication Programming Interface“ (API).Das stellt ein Set von Funktionen zur Ver-fügung, wie zum Beispiel Elementen zurDarstellung von Schriften und Graphikenauf dem Bildschirm, auf denen der Pro-grammierer von interaktiven Services beider Erstellung so genannter „Applikatio-nen“ (Anwendungen) aufbauen kann. Die-se Applikationen sind Programme, die aufeinem Rechner ablaufen, der inzwischenunbemerkt neben den bekannten Struk-turelementen wie Empfangsteil, digitalemVideo- und Audiodecoder „in die Emp-fangsgeräte gewandert“ ist.

Da innerhalb der internationalen Nor-mungsgremien lange Zeit keine Standar-disierung für ein solches API erfolgte, ent-standen zunächst mehrere proprietäreAPI-Systeme. Ausgelöst durch die zuein-ander nicht kompatiblen Systeme, wieOpenTV, Media Highway oder Betanovaentstand eine Fragmentierung der Märkte.Fernsehzuschauer, die an den neuen Ser-

vices verschiedener Anbieter interessiertwaren, mussten sich mehrere Set-Top-Boxen neben ihr Fernsehgerät stellen, umdie Services unterschiedlicher Anbieterangesichts dieser babylonischen Sprach-verwirrung nutzen zu können.

Um diesen Zersplitterungseffekt zu ver-meiden und die Entwicklung eines „hori-zontalen Marktes“ zu fördern, der es Her-stellern erlaubt, mit konkurrierenden aberkompatiblen Produkten nebeneinanderam Markt aufzutreten, beschloss manschließlich bei DVB, einen europäischenStandard für eine „Multimedia Home Plat-form“ (MHP) zu erstellen. Deren Kern-stück ist das API. Die Spezifikation sollteden ganzen Bereich möglicher Geräteim-plementationen abdecken, von der Set-Top-Box über das integrierte Fernsehge-rät, das keine externe Set-Top-Box mehrbenötigt, bis hin zum Multimediacomputer,der über ein „Local Home Network“ mitverschiedenen anderen Geräten verbun-den ist.

Zum Erhalt einer marktgerechtenMHP-Spezifikation erarbeitete man vorder technischen Spezifikation einen Kata-log kommerzieller Anforderungen, der beider Ausgestaltung der technischen Spezi-fikation zugrunde gelegt wurde.

Schlüsselelemente dieser Anforderun-gen waren

— offener und frei zugänglicher Stan-dard,

— Trennung von API und „ConditionalAccess“-System (CA) bei gleichzeiti-ger Unterstützung verschiedener CA-Systeme, sowie eines „Common In-terfaces“,

— Interoperabilität von Plattformen un-terschiedlicher Hersteller,

— Darstellbarkeit von Services (Dien-sten) verschiedenster Inhalte- (Con-tent-) und Netzwerkanbieter,

— Skalierbarkeit von Low-End- bis zuHigh-End-Lösungen,

— Modularität bis hin zur Vernetzung,— optionale Fähigkeit zur Darstellung

von HTML,— Sicherheit,

— Schutz der MHP-Platform gegenKorruption und Viren,

— Schutz von Inhalten gegen Verän-derung und Angriffe,

— Schutz von Urheberrechten,— Schutz des (mitunter kostenpflich-

tigen) Rückkanals gegen uner-laubte Benutzung durch Services,

— Schutz der persönlichen Datendes Konsumenten,

— kontrollierter Weg für Erweiterungendes Standards entsprechend neuertechnischer Entwicklungen,

— „Upgrade“-Fähigkeit auch über Rund-funk- und Datennetze,

— einfache, benutzerfreundliche Bedie-nung und

— geringe Kosten.

2. Technische Spezifikation

Zur Spezifikation wurden auf einen„Request for Detailed Specifications“ hinsehr unterschiedliche Vorschläge einge-reicht: angefangen von einem HTML-ba-sierten System, über das bereits von DA-

VIC spezifizierte MHEG bis hin zu einemSystem mit JAVA als Ausgangspunkt. DerAuswahlprozess führte schließlich zu ei-ner Entscheidung für die Programmier-sprache JAVA als Basis für das API, mitzusätzlichen fernsehspezifischen Erweite-rungen. Um auch Services auf der Basisvon HTML anbieten zu können, wurdeeine Option zur Darstellung von HTML-In-halten vorgesehen. Sie wurde aber in derMHP 1.0.1 noch nicht spezifiziert.

Sonderdruck aus FERNSEH- UND KINO-TECHNIK – 55. Jahrgang – 2001 1

MHPMHPMultimedia Home Platform

Seitdem der „MHP-Standard 1.0“ verabschiedet wurde, gibt es schon wiederErweiterungen zu 1.0.1 und 1.1, die auf 1.0 aufbauen, sowie Überlegungen

für einen neuen „MHP 2.0“-Standard. Der Beitrag liefert aus erster Hand neu-este Erkenntnisse, Implementierungsvorschläge und erläutert den Standard

unter verschiedenen Gesichtspunkten.

Dipl.-Ing. Robert Sedlmeyer ist verantwortlichfür die Gebiete „Audio und Video Processing“im IRT und aktiv in den MHP-Gremien zurDefinierung des Standards tätig

1E:\FKT\Beitraege\Heft08_9\Sonderdruck\Sedlmeyer.vpSamstag, 11. August 2001 08:13:07

Farbprofil: DeaktiviertKomposit Standardbildschirm

3. Services und Applikationen

Kernstück der Innovation beim Entwurfeiner MHP war stets die Nutzung von In-teraktivität — sowohl lokaler Interaktivitätals auch Interaktivität mit einem Informa-tionsfeedback zum Inhalteanbieter. FürLetzteres ist ein Rückkanal erforderlich.

Interaktivität stellt das ausschlaggeben-de Element beim Aufbau neuer Servicesdar, die dem Fernsehzuschauer eine Men-ge neuer Benutzungsmöglichkeiten eröff-nen. Interaktive Spielshows, an denen ersich aktiv beteiligen kann, erlauben eineweit intensivere Einbindung des Zuschau-ers in das Geschehen als Sendungen, beidenen er nur zuschauen kann. Darüber hin-aus können innerhalb von Fernsehsendun-gen Hinweise und zusätzliche Inhalte undServices am Bildschirm erscheinen, auf dieer per Tastendruck zugreifen kann. Damitlassen sich Informationen „On Demand“aufrufen — wie aus Inhalten im Internet be-kannt. Durch die Möglichkeit, Hinweise zuweiterführenden Inhalten nicht nur anzeigenzu können, sondern auf Wunsch des Zu-

schauers hin auch direkt aufrufen zu kön-nen, sind weitere Inhalte für den Kundenviel leichter erreichbar. Er muss nicht mehrdie angezeigte Internetadresse mühsamauf Papier aufschreiben, gegebenenfalls inein anderes Zimmer gehen, um dort den PCzu booten und ähnliches. Das alles dauertmitunter mehrere Minuten, und der Zu-schauer muss von der Sendung „wegge-hen“, um an die Informationen zu gelangen.Das erreicht er in einer MHP auf Tasten-druck auf der Fernbedienung — entwederwährend oder nach der Sendung. Die MHPbietet aber darüber hinaus noch eine Men-ge weiterer Neuerungen.

Mit der Digitalisierung von Audio undVideo ist eine Übertragung von immermehr Fernsehprogrammen möglich ge-worden. Innerhalb dieser Vielzahl kannder Zuschauer inzwischen nur noch mitHilfe geeigneter Instrumente die ihn inter-essierenden Inhalte effektiv aussuchen.Ein Navigator, der vom Hersteller in derMHP resident mitgeliefert wird, soll alleverfügbaren Fernsehprogramme und In-halte in einer Übersicht anzeigen. Darüber

hinaus bringt ein „Electronic ProgrammeGuide“ (EPG), der von einem „Broadcas-ter“ übertragen wird, und auch Bilder ausFilmen und andere Informationen über dieInhalte darstellen kann, wesentliche Ver-besserungen (Bild 1). Bereits zu Beginnder Arbeiten an der MHP dachte manaber auch an interaktive Applikationen,wie zum Beispiel:— Home Shopping,— Home Banking,— Interaktive Fernsehsendungen (Ge-

winnspiele, Ratespiele, usw.),— „Pay-per-View“,— VoD (Video on Demand),— AoD (Audio on Demand),— E-Mail,— Internetzugang,— VoIP (Voice over IP) und— Computerspiele.

Die zuletzt genannten Applikationenbefinden sich aber bereits relativ weit wegvon digitalem Fernsehen und wurden des-halb zwar für weitere Entwicklungen vor-gesehen, lagen aber für eine erste Spezi-fikation noch nicht im Zentrum der Auf-merksamkeit.

Die „Multimedia Home Platform“ war zu-nächst vorwiegend für Services im Umfelddes digitalen Fernsehens gedacht. Umdem Fernsehzuschauer jedoch die neuenServices anbieten zu können, benötigt eineMHP eine ganze Reihe von Schnittstellen(Interfaces) zur Außenwelt (Bild 2). Ihre In-halte kann sie über Satellit, Kabel oder ter-restrisch genauso empfangen wie überISDN, xDSL oder ein Modem. Das Feed-back zum Inhalteanbieter in interaktivenApplikationen kann ebenfalls über einendieser Kommunikationswege erfolgen, so-fern er rückkanalfähig ist. Die Interaktionzwischen der „Multimedia Home Platform“und dem Zuschauer geschieht normaler-weise über eine Fernbedienung oder ge-gebenenfalls eine Tastatur. Die Präsentati-on von Video und Applikationen erfolgt

2 Sonderdruck aus FERNSEH- UND KINO-TECHNIK – 55. Jahrgang – 2001


Video onDemand

Bild-telefonie Voice

over IP

Pay perView

E-Mail

Games

Internetinteraktive

SendungenHome-

Shopping

Home-Banking

EPG

Navigator

Audio onDemand

TV

Bild 1. Anvisierte Services auf MHP

Sat-Antenne

DVB-T-Antenne

Kabel

ISDN/xDSL DVD-Recorder Tastatur Fernbedienung

PC

MHP

LautsprecherDisplay

Bild 2. MHP und ihre Verbindungen nach außen

Internet Access 2

Internet Access 1

InteractiveBroadcast 2Enhanced

Broadcast 2

EnhancedBroadcast 1

InteractiveBroadcast 1

Internetzugang

Internet-Erweiterungenals Plug-in

Navigator

Applikationen z.B. EPG

lokale Interaktivität

Interaktivität mitRückkanal

„HTM subset *)Plug-in

„HTML subset *)Plug-in

*) optional

Bild 3. Profile für MHP-Implementationen



über das Fernsehgerät oder ein Display,von Audio über Lautsprecher. Inhalte sol-len natürlich nicht nur aus den genanntenÜbertragungsmedien abgerufen werdenkönnen, sondern auch von Speicherme-dien wie beispielsweise DVD-Playern. Alszukünftiges Szenario ist an eine Vernet-zung mit PCs und anderen Geräten zur au-diovisuellen Verarbeitung gedacht.

Zur Abbildung der geplanten Serviceswurden drei „Profiles“ vorgesehen:

• „Enhanced Broadcast Profile“,

• „Interactive Broadcast Profile“ und

• „Internet Access Profile“.

Von diesen wurden die ersten beiden inder „MHP-Spezifikation 1.0“ im Februar2000 umgesetzt und im Mai 2000 bei demeuropäischen StandardisierungsgremiumETSI eingereicht (Bild 3). Die Version 1.0wurde in der Zwischenzeit mit großemAufwand und durch Einfügen einer Men-ge Korrekturen in die „MHP-Spezifikati-on 1.0.1“ übergeführt, die als Grundlageder im Beitrag durchgeführten Beschrei-bung dient. Eine detaillierte Auflistungwichtiger obligatorischer und optionalerFunktionalitäten und unterstützter For-mate der einzelnen Profiles ist in Tabel-

le I dargestellt.

4. Architektur

Um für die MHP-Implementierungen ei-nen horizontalen Markt zu schaffen, wur-de die Möglichkeit der Informationsverar-beitung in einem Mehrschichtenmodellvorgesehen. Festgelegt wurde in der tech-nischen Spezifikation in erster Linie dieGrenzschicht zwischen Systemsoftwareund Applikation. Es wird explizit daraufhingewiesen, dass die Spezifikation nurdie Schnittstellen (Interfaces) zu denNetzwerken beschreibt, sowie zwischenApplikations- und Systemsoftware derMHP — nicht aber die Implementationdieser Elemente.

Bild 4 zeigt eine mögliche Implementa-tion der MHP. In der obersten Schicht be-finden sich eine oder mehrere, auch paral-lel ablaufende MHP-Applikationen. DieSystemsoftware ist hier wieder in mehrereSchichten aufgeteilt, die „JAVA VM“ (VirtualMachine), das Betriebssystem sowie dieTreiber, die den Zugriff auf die Hardwareermöglichen. MHP-Hersteller können so-mit einzelne Schichten der Systemsoftwa-re wie zum Beispiel die „JAVA-VM“ von ver-schiedenen Softwareprovidern verwenden.Sie können sich aber auch für ein hochin-tegriertes „embedded“ System entschei-den. In der mittleren Schicht arbeitet nebenden Elementen der Systemsoftware auch

der „Application Manager“. Er startet undstoppt Applikationen und wacht über derenAktivitäten. Außerdem findet man hier ei-nen je nach Implementation einen unter-schiedlich ausgestalteten Navigator.

Ein „Loader“ zum Nachladen von „Up-dates“ für die Systemsoftware wird typi-scherweise vorgesehen, um die Zukunfts-sicherheit der Implementation zu gewähr-leisten. Er ist aber nicht Bestandteil derMHP-Spezifikation, sondern kann von je-dem Hersteller anders implementiert wer-den. In der untersten Schicht befindensich schließlich die Ressourcen der MHPmit Elementen wie dem Tuner, MPEG-De-coder usw.

Wie im Bild 4 gezeigt, sind alle Elemen-te unterhalb der Applikationen auf derMHP resident und müssen zum Ablaufnicht erst übertragen werden. Das spartÜbertragungskapazität auf dem Übertra-gungsweg, da nur die darüberliegendenApplikationen übertragen werden müs-sen. Es erfordert aber einen größerenSpeicher in der MHP für das API bzw. dereinzelnen APIs. Im Bild 5 wird noch de-taillierter das Zusammenwirken der ein-zelnen Elemente der MHP gezeigt, diedurch die Applikationen über die APIs an-gesprochen werden.

Um die Migration von existierenden,nicht offenen API-Systemen wie „Open-



Tabelle I. Detaillierte Auflistung von Funktionalitäten und Formaten der einzelnen Profile

Bereich Spezifikationen

En

ha

nc

ed

Bro

ad

ca

st

Pro

file

1

Inte

rac

tiv

eB

roa

dc

as

tP

rofi

le1

Inte

rne

tA

cc

es

sp

rofi

le1

Statische Formate

Bitmap-Bilder

PNG with PNG restrictions M MPNG without restrictions — —GIF — —MPEG-2 I-Frames M MJPEG with JPEG restrictions — —JPEG without restrictions — M

Audio clips Monomedia format for audio clips M MVideo „drips“ MPEG-2 Video „drips“ M MText Monomedia format for text M M„Broadcast Streaming“-Formate

Video Video M MAudio Audio M MSubtitles Subtitles M M„Broadcast channel“-Protokolle

MPEG-2 sections M MDSM-CC User-to-User Object Carousel M MIP Multicast stack based on:DVB Multiprotocol EncapsulationInternet Protocol (IP)User Datagram Protocol (UDP)

O Ro M

„Interaction channel“-Protokolle

TCP/IPTransmission Control Protocoil (TCP)Internet Protocol (IP)

— M M

UDP/IPUser Datagram Protocol (UDP)Internet Protocol (IP)

— M M

DSM-CC U-URPG

DSM-CC User-to-User Object CarouselUNO-RPCUNO-CDR

— O

HTTP HTTP 1.1 — O MM = mandatory, O = optional, Ro = recommended optional

Applikation 1z.B. EPG

Applikation 2z.B. Home-shopping

Applikationen

System-Software

Ressourcen

CANavigator

ApplikationManager

Applikation n

Loader

Hardware

Treiber

Operating System

MHP APIs

Virtual Machine VM

Bild 4. AllgemeineMHP-Architektur



TV“ oder „Media-Highway“ zu MHP zu er-leichtern, aber auch um weitere Content-Formate (zum Beispiel Flash) darstellenzu können (werden von MHP-Spezifika-tion nicht abgedeckt), beschreibt die„MHP-Spezifikation 1.0“ im Kapitel „Archi-tektur“ bereits Strukturen zur Einbindungso genannter Plug-Ins in die Implementa-tion einer MHP. Es erfolgt dann aber keinedetailliertere Spezifikation der Schnitt-stellen zu Plug-Ins — das geschieht erstin „MHP 1.1“.

5. Transportprotokolle

Da die MHP von der digitalen Rund-funkwelt ausgehend konzipiert wurde,stellen Rundfunkübertragungsprotokolle,wie bei DVB spezifiziert, einen wesentli-chen Baustein für die Kommunikationnach außen dar.

Sie unterteilen sich in Protokolle für„Streamed Video und Audio“ und in Proto-kolle für Daten und Applikationen. Um bei

Datenservices und Applikationen das Vor-handensein aller notwendigen Informatio-nen sicher zu stellen, die für die Funktionnotwendig sind, müssen sie zyklisch wie-derholt werden, da nicht bekannt ist, wannder Benutzer die MHP einschaltet. DiesesPrinzip wird heute schon beim Teletextverwendet.

Bei der üblichen Rundfunkübertragungin Form von „Streamed Video“ und„Streamed Audio“ wird eine sehr gute Nut-zung der Übertragungskapazität erreicht,da eine einzige Übertragung von vielenTeilnehmern genutzt wird (Multicast-Prin-zip). Bei Datenservices und Applikationengilt das natürlich auch, wenn ein Interessevon vielen Zuschauern vorhanden ist. DieEffektivität wird zwar durch die notwendi-gen Wiederholungen eingeschränkt, manerzielt aber bei einer Übertragung von ei-ner Quelle an sehr viele Senken immernoch ein weit effektiveres Ergebnis alsbeim Einsatz von „Point-to-Point“-Verbin-dungen wie im Internet.

Für Applikationen mit geringen Zu-schauerzahlen, die über den Rundfunk-weg nicht effektiv bedient werden können,ist die Verwendung von „Point-to-Point“-Verbindungen aber sehr gut geeignet.Dem Zuschauer muss dann die Möglich-keit gegeben werden, Informationen aufAnforderung zu bekommen. Die Anforde-rung geschieht entweder über einen vonHause aus bidirektionalen Informationska-nal, in dem auch die Information zum Teil-nehmer übertragen wird, oder über einenRückkanal, der zusammen mit dem unidi-rektionalen Rundfunkweg einen bidirek-tionalen Informationskanal bildet. Das er-gänzt somit ideal den Rundfunkübertra-gungsweg, der seine Vorteile in der Mas-senkommunikation ausspielt. Als Über-tragungsprotokolle verwendet man „Inter-action Channel“-Protokolle, wie zum Bei-spiel das „Internet Protocol“ (IP) (Bilder 6

und 7).

6. Formate von Inhalten (Content)

Natürlich können MPEG-2-codierte Au-dio- und Videostreams, wie sie zur Über-tragung von Fernsehprogrammen in digi-taler Form seit längerer Zeit verwendetwerden, von einer MHP dargestellt wer-den. Um interaktive Services interessantgestalten zu können, benötigt man aberdarüber hinaus die Möglichkeit zur Dar-stellung von Graphiken, Bildern und Vi-deosequenzen, die nicht als kontinuierli-che Streams angeliefert werden, sondernals Datenpakete mit endlicher Länge.Elektronische Programmführer (EPGs)beispielsweise werden erst wirklich attrak-tiv, wenn sie bebildert sind, oder noch bes-ser, die Ansicht kurzer Filmausschnitte er-lauben.

Für die Übertragung und Darstellung vonstatischen Bitmap-Bildern hat man in „MHP1.0“ das JPEG- und PNG-Format vorgese-hen, auf Grund der Lizenzpflicht aber keineGIF-Bilder. Auch „Flash“-Animationen sind



Audiooutput

Videooutput

+ Graphics

Remote control/keybord/mouse input

Storage MediaControl

APIRemoteProgram

TCP/IP

other(s)over

UDP/IP

InteractionChannel

DSM-CC

ServiceInformation

MPEG-2Section

Filter

TunerControl

CAControl

MediaControl

MediaDecoder

Demux

CA

Tuner

Network

User Interaction

Application

Bild 5. Applikationen und ihr Zusammenwirken mit den einzelnen Elementen der MHP

Application

Application Programming Interface

DVB ObjectCarousel

MPEG-2 Sections (DSM-CC Sections)

MPEG-2 Transport Stream

UDP

IP

DVBMultiprotocol

DVB SI

Broadcast Channel

DSM-CC DataCarousel

DSM-CC User-to-User Object

Carousel

Application

Application Programming Interface

IP

Network Dependent Protocols

HTTP

UCP

TCP

ServiceSpecific

DSM-CC User-to-User Object

Carousel

UNO-RPCUNO-CDR

Bild 7. Interaction-Channel-Protokolle

Bild 6 (links). Rundfunk-Übertragungs-Protokolle



nicht Bestandteil des „MHP 1.0“-Standards.Für die Darstellung von Audio könnenMPEG-codierte Audioclips verwendet wer-den. Für Animationen und Videosequen-zen, die als Datensatz zum Beispiel inner-halb von MPEG-2-Sektionen verpackt über-tragen werden können, hat man I-Framesund Video-„drips“ in MPEG-2 vorgesehen.MPEG-2-I-Frames sind zeitlich aufeinanderfolgende intra-codierte Bilder, währendMPEG-2-Video-„drips“ aus I-Frames und P-Frames bestehen. Zwar kann man damitEinzelbilder nacheinander auf dem Displayanzeigen, es lassen sich aber keine Se-quenzen in Form von fortlaufenden Videoszeigen. Das würde eine Bildwechselfre-quenz von 40 ms erfordern. In der Spezifi-kation wird aber eine minimale Bildwechsel-frequenz von bis zu 500 ms erlaubt.

Die Einbeziehung von Video-„drips“ hatfolgenden Hintergrund: Es ist für die Ver-wendbarkeit von Animationen in der Pra-xis von großer Bedeutung, dass die Da-tenrate so weit wie möglich verringert wer-den kann, ohne den Aufwand bei der De-codierung allzusehr zu steigern. Das wirdschnell ersichtlich, wenn man sich vor Au-gen führt, dass ein EPG, wie er zum Bei-spiel von der ARD ausgestrahlt wird, eineÜbertragungsrate von etwa 4,5 Mbit/s be-nötigt. Das ist mehr als 10% der Bandbrei-tenkapazität eines einzelnen Satelliten-transponders und mehr als üblicherweisefür eine Video- und Audiokomponentevorgesehen ist. Die Relevanz der gewähl-ten Bildübertragungsformate wird nochgrößer, wenn man bedenkt, dass etwa90% der Übertragungsrate für das Bild-material innerhalb eines derartigen EPGverbraucht wird, und nur 10% für den Pro-grammcode der Applikation.

Neben der reichlichen Garnierung vonApplikationen mit statischem Bildmaterialwäre eine Darstellung von Filmausschnit-ten in EPGs wünschenswert. Will man fürdie Übertragung das MPEG-Format ver-wenden, so könnte man daran denken,den ohnehin vorhandenen MPEG-2-Decoder nicht nur für die Decodierung vondigitalen Fernsehprogrammen, sondernauch für MPEG-2-Datenfiles einzusetzen.Der Decoder müßte dann allerdings auchMPEG-2-Datenfiles verarbeiten können.Das kann je nach Hardwareimplementie-rung bei einigen zurzeit auf dem Marktverfügbaren Decoderchips aber zu Pro-blemen führen. Alternativ ließe sich einentsprechender Softwaredecoder einset-zen, der aber eine sehr große Rechenka-pazität innerhalb der CPU erfordern wür-de. Um die Videos nicht permanent onlineübertagen zu müssen — sondern in klei-nen Portionen mit geringerer Datenrate

—, ist darüber hinaus in der MHP ein rela-tiv großer Datenspeicher notwendig.

Aus diesen Gründen hat die Darstel-lung von Videosequenzen aus Datenfilesbis jetzt keinen Eingang in die Spezifika-tion gefunden. Da sie aber einen großenNutzwert, sowohl für den Zuschauer alsauch für den „Broadcaster“ bieten würde,weil man damit zum Beispiel Film-ausschnitte innerhalb eines EPGs zeigenkönnte, wäre es erfreulich, wenn sie viel-leicht in einer späteren Version der MHP-Spezifikation doch noch Platz findenwürde.

Neben der Darstellung von Bildern undGraphiken ist auch die Anzeige von Tex-ten in Applikationen notwendig. Die aus-schließliche Darstellung von Text (wiebeim Teletext) ist aber für den Zuschauernicht mehr attraktiv genug. So unterstütztMHP zwar DVB-„Subtitles“, und es ist denGeräteherstellern freigestellt Teletext zumBeispiel mittels eines Teletextdecodersdarzustellen, MHP liefert aber keine APIs,die einen Zugriff auf Teletextdaten ermög-lichen/erlauben.

Texte und ihre Erscheinungsformensind aber bei der Präsentation von Inhal-ten ein wichtiges Gestaltungsmittel. Inhal-tehersteller wollen sogar auf eine mög-lichst große Auswahl von Textschrifttypenzurückgreifen, um den Inhalten eine be-sondere Note bzw. ein „Branding“ zu ver-leihen. Um Ressourcen zu sparen, wurdein „MHP 1.0“ aber nur eine Schrifttype,nämlich der „Tiresias“-Font ausgewählt,der in jeder MHP in vier verschiedenenGrößen immer resident vorhanden ist. Erwird per „Default“ zur Darstellung von Tex-ten verwendet. Sollen andere Schrifttypenzur Anzeige gebracht werden, so müssensie in „MHP 1.0“ mit der jeweiligen Appli-kation übertragen werden. Das gilt genau-so für „Buttons“ und andere graphischeDarstellungselemente. Damit ist sicherge-stellt, dass der Inhalte-Designer immer inder Lage ist, das „Look-and-Feel“ selbstzu bestimmen.

7. Starten und Stoppen vonApplikationen

Multimediale Services werden in einerMHP durch Applikationen“ dargestellt.Ausgehend von Rundfunk als zentralemMedium wurde das Starten und Stoppenvon Applikationen zunächst mit der Aus-wahl von Rundfunkservices verknüpft, wiedas bereits vom Teletext her bekannt ist.Ein Service besteht jedoch aus verschie-denen Teilen (Audio, Video, Daten undApplikationen), die eine gewisse Zusam-mengehörigkeit haben und dem Benutzer

vielleicht auch zusammen präsentiert wer-den sollen.

Bisher werden Rundfunkservices amFernsehgerät durch „Zapping“ ausge-wählt, mittels Up- und Downkeys oderdurch die Nummerntasten der Fernbedie-nung. Springt der Zuschauer so von ei-nem Fernsehprogramm zum nächsten, sowählt er dadurch implizit auch einen neu-en „Service“ an.

Bei einer MHP soll „Zapping“ auchmöglich sein. Darüber hinaus gibt es dieAuswahlmöglichkeit durch einen Naviga-tor oder durch EPG-artige Applikationen.Wie die Auswahl mit einem Navigator imEinzelnen auszusehen hat, darüber sagtdie MHP-Spezifikation nichts. Die Ausge-staltung des Navigators ist vollständig im-plementations-abhängig.

Damit ist die Forderung der „MHPCommercial Requirements“, alle Servicesim Navigator anzuzeigen und zur Auswahlanzubieten, genau genommen nicht Be-standteil der technischen MHP-Spezifika-tion. Die Anzeige und Auswahl in einemNavigator kann zum Beispiel „Programmfür Programm“ erfolgen oder durch Aus-wahl eines Bouquets. Bouquets sind inder Regel Ansammlungen von mehrerenTV-/Hörfunkprogrammen, MHP-Applika-tionen und Datenservices eines odermehrerer Anbieter (wobei die Sache da-durch kompliziert wird, dass unterschiedli-che Bouquets auch gemeinsame Servicesenthalten können).

Wird ein Service angewählt, so ge-schieht die Präsentation der unterschiedli-chen Serviceelemente (Audio, Video, Da-ten und Applikationen) in einem so ge-nannten Servicecontext. Ein Servicecon-text stellt das Umfeld dar, in dem eine Ap-plikation agiert. Kontrolliert wird diesesAgieren von einem „Application Manager“,der darüber wacht, dass verschiedeneRegeln eingehalten werden. Innerhalb ei-nes „Servicecontexts“ kann zwar nur je-weils ein Service zu einer Zeit dargestelltwerden, es können aber mehrere Applika-tionen, die sich innerhalb desselben Servi-ces befinden, gleichzeitig ausgeführt unddargestellt werden. Der „Broadcaster“muss jedoch dafür Sorge tragen, dasssich die einzelnen Applikationen nicht ge-genseitig stören und dass das gesamteSystem für den Zuschauer benutzbarbleibt.

Es gibt auch die Möglichkeit eine Appli-kation nach einem Servicewechsel auto-matisch zu starten, ohne dass es der Be-nutzer gesondert veranlassen müsste.Das geschieht dadurch, dass der „Appli-cation Control Code“ innerhalb der AIT(Application Information Table) als „Auto-start“-Applikation deklariert wird.







Applik. BApplik. B Applik. BApplik. BApplik. B

Video AVideo A Video BVideo AVideo B

Applik. A Applik. AApplik. A Applik. A

Audio AAudio A Audio BAudio AAudio B

Video B

Video A Applik. A

Applik. B

Service A

Service B

Audio A AIT A

AIT BAudio B

t=4 t=5 t=6 t=7 t=8

Bouquetüber-greifender EPG





(EPG) (EPG) (EPG) (EPG)

Video B ist sichtbar

Audio B ist hörbar

Applikation B ist sichtbar

Wechsel zu Service A

Video A anzeigen

Audio A anbieten

Applikation B weiterhin laufenlassen, weil in AIT erlaubt

Applikation A starten

Wechsel zu Service B

Video B anzeigen

Audio B anbieten

Applik. A stoppen, weil ‚service bound‘

Applik. B weiterhin laufen lassen, aberunsichtbar machen

Applikation A (EPG)und Applikation Bgleichzeitig anzeigen

Applikation Banzeigen

Applikation A (EPG)pausieren lassen

Video A ist sichtbar

Audio A ist hörbar

Applikation B läuft weiter undist sichtbar

Applikation A läuft, weil in demBeispiel als ‚autostart‘ dekla-riert, aber noch nicht sichtbar


Audio A ist hörbar

Applikation A teilt sich mitApplikation B den Bildschirm

-> beide Applikationen sindsichtbar


Audio B ist hörbar

Applikation B ist nicht sichtbar


Audio A ist hörbar

Applikation B läuft wieder undist sichtbar

Applikation A pausiert und istsichtbar

Servicewechselaus Applikation B

(bouquetübergreifen-dem EPG) heraus

Benutzer-Aktion

Aktionen derMHP alsFolge derBenutzer-Aktionen

Aufruf der Applikation Aaus Applikation B herausz.B. durch Tastendruck

auf Fernbedienung

Rückkehr zu Applikation Baus Applikation A (EPG) heraus

z.B. durch Tastendruck aufFernbedienung

Servicewechselaus Applikation B(bouquetübergrei-

fendem EPG) heraus undAbschalten der Sichtbarkeit

der Applikation

Eintrag von Applikation B mittelsexternal authorization descriptor‘

in AIT von Service A‚

Bild 9. Beispiel zu Start und Stopp eines bouquetübergreifenden EPG, sowie organisiertes Zusammenwirken mit einem ‚co-operierenden‘Service-gebundenen EPG

Applik. AApplik. A Applik. BApplik. A

Video BVideo A Video BVideo AVideo x

Applik. B

Audio BAudio A Audio BAudio AAudio x

Video B

Video A Applikation A

Applikation B

Service A

Service B

Audio A AIT A

AIT BAudio B

Ausgangssituation t=0 t=1 t=2 t=3 t=4

(EPG)(EPG) (EPG)Bouquetüber-greifender EPG


Wechsel zu Service A

Video A anzeigen

Audio A anbieten

Applikation A starten

Wechsel zu Service B

Video B anzeigen

Audio B anbieten

Applikation A stoppen

Applikation B starten

Applikation A (EPG) anzeigen Applikation B anzeigen

Video x ist sichtbar

Audio x ist hörbar


Audio A ist hörbar

Applikation A ist in dem Bei-spiel als ‚autostart‘ deklariert,aber noch nicht sichtbar, weilso programmiert, dass sieerst auf Tastendruck erscheint


Audio A ist hörbar

Applikation A ist sichtbar


Audio B ist hörbar

Applikation B ist sichtbar


Audio B ist hörbar

Applikation B ist in dem Bei-spiel als ‚autostart‘ deklariert,aber noch nicht sichtbar, weilso programmiert, dass sieerst auf Tastendruck erscheint

Servicewechseldurch Zapping

Benutzer-Aktion

Aktionen der MHPals Folge derBenutzer-Aktionen

Aufruf der Applikationz.B. durch Tastendruck

auf Fernbedienung

Servicewechseldurch Applikation

(EPG)

Aufruf der Applikationz.B. durch Tastendruck

auf Fernbedienung

Bild 8. Beispiel zu Start und Stopp von Applikation



Angenommen, es wird ein neuer Servi-ce durch „Zapping“ angewählt (wie imBild 8 gezeigt) und es gibt einen EPG, dersich neben dem TV-Programm innerhalbdieses Services befindet. Ist der EPG als„Autostart“-Applikation in der „ApplicationInformation Table“ (AIT) der „Service Infor-mationen“ eingetragen, so startet dieEPG-Applikation. Der Sender kann ent-scheiden, ob die Applikation sofort sicht-bar werden soll oder zum Beispiel erstdurch Drücken einer vorher festgelegtenTaste auf der Fernbedienung. Aus derEPG-Applikation heraus kann nun agiertwerden; es können Texte, Bilder und Vi-deo-„drips“ dargestellt werden. Es kann zuanderen „Services“, wie zum Beispiel ei-nem anderen TV-Programm gewechseltwerden. Es kann aber auch eine andereApplikation aufgerufen werden, die sichentweder innerhalb desselben „Services“befindet oder aber in einem anderen „Ser-vice“.

Der EPG wird im Beispiel (s. Bild 8) ge-stoppt und die neue Applikation gestartet.Sie könnte aber auch weiter laufen(Bild 9), wie anhand zweier „befreunde-ter“ EPG-Applikationen gezeigt ist. Wirdein neuer Service selektiert und dadurchder aktuelle ersetzt, so sollen Applikatio-nen des aktuellen „Services“ nur dannweiter ausgeführt werden können, wennsie auch in dem neuen Service durch den„External Application Authorisation Des-criptor“ signalisiert werden.

Diese Regelung hat den Hintergrund,dass eine Applikation nur auf „Servicesund Applikationen“ verzweigen darf, wenndiese „befreundet“ sind und sie „weiter le-ben“ soll. Damit kann ein beliebiger Appli-kationsanbieter zum Beispiel nicht einenEPG anbieten, der auf alle möglichenexistierenden Services verzweigt, ohnesich mit den Anbietern dieser Services zuarrangieren. Doch damit nicht genug. EinServiceanbieter kann seine Applikationendurch ein „Service Bound Flag“ als „Servi-ce“-gebunden deklarieren. Dann wird beieinem Wechsel zu einem anderen Servicedie Applikation immer gestoppt.

Zum Schutz des Zuschauers vor Fehl-bedienung wurde darüber hinaus verein-bart, dass während der Zeit, in der eineApplikation die Nummerntasten oder Up-und Downtasten der Fernbedienung be-nutzt, die Funktion des Navigators zumProgrammwechsel nicht ausgeführt wird.

Um die Regeln für den Lebenszyklus(Lifecycle) einer „Applikation in JAVA“ be-schreiben zu können, hat man in Anleh-nung an „Applets“, die sich aufbauend aufder Programmiersprache JAVA im Internetzur Abbildung ablauffähiger Programmeetabliert haben, so genannte „Xlets“ defi-niert. Diese können einen Zyklus mit denZuständen „loaded“, „paused“, „active“und „destroyed“ durchlaufen (Bild 10).

8. HTML

APIs zur Darstellung von DVB-HTMLwerden erst in der „MHP-Spezifikation1.1“ definiert. Das Gleiche gilt für einestandardisierte Schnittstelle zu einemWebbrowser oder einem E-mail-Client.

9. Graphikreferenzmodell

Die MHP stellt dem Applikationspro-grammierer viele Werkzeuge zur Verfü-gung, um Videobilder, Graphiken, „But-tons“, Texte und Listen auf dem Bild-schirm darzustellen. Er kann sie so posi-tionieren, wie er es will. Das Bild, das derBenutzer auf dem Display zu sehen be-kommt, ist dabei immer aus mehreren hin-tereinanderliegenden virtuellen Schichtenaufgebaut, die sich zu einem gemeinsa-men Bild ergänzen. Als unterste Schichtdient die Hintergrundebene, gefolgt von

der Videoebene und — dem Zuschauer-auge am nächsten liegend — der Gra-phikebene. Schematisch ist das imBild 11 dargestellt.

Wie die einzelnen Schichten zu einemgemeinsamen Bild zusammengefügt wer-den zeigt Bild 12. Gut zu erkennen sindhier auch die Möglichkeiten, die sich durchdie Transparenz einzelner Schichten er-geben. Graphische Elemente und Video-komponenten, die nur Teile des Bild-schirms ausfüllen, lassen ein dahinter lie-gendes Videobild an den transparentenStellen sichtbar bleiben. Neben vollständi-ger Transparenz (wie hier gezeigt) erlaubt„MHP 1.0“ auch die Definition semi-trans-parenter Bereiche, die in Applikationen eindahinterliegendes Videobild zwar nochsichtbar belassen, es aber entsprechendabtönen. Den davor liegenden Schriftenkann auf diese Weise beispielsweise einebessere Lesbarkeit verliehen werden.

Nachdem die MHP auf der Program-miersprache JAVA aufbaut, liegt es nahe,zur Realisierung der Darstellung von Gra-phiken, Texten und „Buttons“ auf die inJAVA existierenden Sprachelemente alsWerkzeuge zur Darstellung zurückzugrei-fen. Das ist im Wesentlichen die „JAVA-AWT“, die ihrerseits aus so genannten„Lightweight Components“ und „Heavy-weight Components“ besteht. Die „JAVA-AWT“ bietet dem Programmierer bereitseine Menge Werkzeuge, um zum BeispielLinien, Flächen, Texte und „Buttons“ dar-zustellen.

Sie hat aber auch Nachteile. Der Ge-brauch von „Heavyweight Components“greift auf Funktionen des unterhalb der„Virtual Machine“ liegenden Betriebssy-stems für das Zeichnen von Graphiken zu.Das verursacht, dass das Aussehen vongraphischen Elementen auf unterschiedli-chen Plattformen voneinander abweichenkann, wenn diese ein unterschiedlichesBetriebssystem benutzen.

Darüber hinaus fehlen innerhalb der„JAVA.awt“ geeignete Möglichkeiten zurDarstellung der im Fernsehbereich amhäufigsten vorkommenden Inhalte — denVideos. Dafür wird das „JAVA Media Fra-



Loaded Paused ActivestartXlet

initXlet

pauseXlet

destroyXlet

destroyXlet

destroyXlet

Destroyed

Bild 10. Lebenszyklen von Xlets

JMF Video ComponentHGraphics Device

HVideo DeviceHBackground Device

Combins withSRC,SRC_OVER orCLEAR rule

Always combinswith SRC rule

Bild 11 (links). Sche-matische Darstellungder unterschiedli-chen Schichten, diefür ein Bild nach demMHP-Graphik-Refe-renz-Modell verant-wortlich sindBild 12 (rechts).Kombination derverschiedenenSchichten zu einemeinzigen Bild

Background planesVideo planes

Graphic planes

Betrachter



mework“ (JMF) eingesetzt. Neben der„JAVA-AWT“ und „JMF“ wurde zusätzlichdas durch das HAVI-Consortium standar-disierte „User Interface“ (Havi.ui) in „MHP1.0“ aufgenommen. Es enthält in „H-Look“Methoden zur Skalierung, Positionierungund Darstellung von graphischen Inhalten,die nur auf „Lightweight Components“ der„JAVA.awt“ zurückgreifen. Der Program-mierer von Applikationen hat durch dieÜbertragung seiner „H-Look“-Informati-onen die Möglichkeit, das „Look-and-Feel“seiner Applikationen eindeutig festzule-gen, da keine Betriebssystem-abhängi-gen „Heavyweight Components“ aus„JAVA-AWT“ verwendet werden müssen.

Zur besseren Anpassung an das Be-nutzungsumfeld einer MHP-Plattform, diedurch den Zuschauer in der Regel nichtüber eine Computermaus gesteuert wird,sondern über eine Fernbedienung kom-muniziert, wurde HAVI anstelle des „UserInterfaces“ von „JAVA-AWT“ verwendet.

10. Sicherheitsaspekte

Der Fernsehzuschauer ist beim Kon-sum von Fernsehprogrammen und Inhal-ten einen sehr hohen Grad an Sicherheitgewöhnt, auch wenn ihm das normaler-weise nicht bewusst wird. In die Aufmerk-samkeit rückt die Bedeutung von Sicher-heit (der englische Begriff Security ist et-was weiter gefasst als der deutsche)meist erst dann, wenn sie nicht vorhandenist. Gute Beispiele sind Virenattacken undHackerangriffe, wie sie im Bereich des In-ternets zur täglichen Praxis gehören.Schaltet der Fernsehzuschauer sein Fern-sehgerät ein, so läuft er bisher wenig Ge-fahr, dass die von ihm betrachteten Inhal-te und Nachrichten von Dritten manipuliertsind. Die Rundfunkanstalten achten beider Wahl der Übertragungswege sehr ge-nau darauf, dass etwaige Manipulationennach Kräften verhindert werden. Und eskommt in der Regel auch nicht vor, dassdas Fernsehgerät einen schwarzen Bild-schirm zeigt, weil die Systemsoftwaredurch einen Virus außer Kraft gesetzt wur-de.

Mit der Nutzung von ablauffähigen Pro-grammen als Serviceinhalte sowie mit derIntegration eines Rechners in eine „Multi-media Home Platform“, stiegen natürlichdie Gefahren für derartige Szenariendrastisch an, wenn man keine Gegen-maßnahmen ergreifen würde. Durch denAblauf von Programmen auf einer MHP,die vorher übertragen wurden, entstehtein Gefahrenpotenzial, wie es von derComputerwelt bekannt ist. Für das klassi-sche Fernsehen werden relativ sichere

Übertragungswege wie Satellit, Kabeloder terrestrischer Ausstrahlung genutzt,die eigentlich geschlossene Übertra-gungssysteme darstellen. Sollen nun aberauch noch Inhalte oder Applikationen ausdem Internet abgerufen werden, so wirdein effektiver Schutz von Inhalten und Be-nutzerplattform umso dringlicher.

Deshalb hat man in der MHP-Spezifi-kation mehrere Vorkehrungen getroffen,um die Sicherheit zu gewährleisten:

Alle Applikationen laufen in einer sogenannten „Sandbox“ ab.

Die Aktionen von Applikationen undder Zugriff auf Ressourcen werden durcheinen „Security Manager“ überwacht. Erverhindert alle gefährlichen Zugriffe undAktionen. Ausgangspunkt war hier dasJAVA-„Sandbox“-Modell und die Überle-gung, dass eine Applikation, die nur in ei-ner „Sandbox“ läuft, keinen großen Scha-den anrichten kann. Es ist ihr dann nur er-laubt, Inhalte auf dem Display darzustel-len, nicht aber zum Beispiel auf Kostendes Benutzers Telefonnummern anzuru-fen, seine in der MHP gespeicherten Zu-schauereinstellungen und Präferenzenoder gar seine Kreditkartennummer nachaußen weiterzugeben. Diese Sicherheits-kriterien haben sich im Internet seit Jahrenbewährt, sind jedoch für viele Applikatio-nen im Fernsehbereich zu restriktiv. Umdie Rechte von Applikationen erweitern zukönnen, hat man die Möglichkeit des Sig-nierens von Applikationen geschaffen.Während unsignierte Applikationen in ei-ner maximal gesicherten „Sandbox“ lau-fen, werden bei signierten Applikationenüber ein „Permission File“ zusätzlich zu-gewiesene Rechte genau definiert. Daskann zum Beispiel das Recht zur Nutzungdes Modems, des nichtflüchtigen Spei-chers oder ähnlichem sein.

Unsignierte Applikationen können— keinen Zugang zu Inhalten des nicht-

flüchtigen Speicher erlangen,— nur die Benutzereinstellungen Spra-

che, Kinderschutzeinstellung, „De-fault“-Schriftgröße und Ländercodelesen. Sonst sind für unsignierte Ap-plikationen keine Präferenzen desBenutzers lesbar,

— den „Return Channel“ nicht benutzen,— nicht „tunen“ oder einen anderen Ser-

vice selektieren,— nicht mit signierten Applikationen

kommunizieren und— keine Video-„drips“ darstellen.

Signierte Applikationen können:— Zugang zu Inhalten des nichtflüchti-

gen Speichers und des Dateisystemserlangen, wenn das im „PermissionRequest File“ angefordert wurde.Eine Applikation enthält die Dateien,die sie erzeugt hat, und kann für die-se Lese- und Schreibrechte für ande-re Applikationen beliebig vergeben;

— für alle Benutzereinstellungen undPräferenzen Lesezugriff oderSchreib-/Lesezugriff erlangen,

— nur den „Return Channel“ benutzen,wenn die Telefonnummer — die an-gerufen wird — in einem „PermissionRequest File“ spezifiziert wurde,

— nur „tunen“ oder einen anderen Servi-ce selektieren, wenn es im „Permissi-on Request File“ angefordert wurde,

— mit signierten Applikationen im glei-chen Service kommunizieren und

— Video-„drips“ darstellen, wenn es an-gefordert wurde.Damit die „Multimedia Home Platform“

eine Entscheidung treffen kann, ob siediese Rechte einer signierten Applikationgewährt, muss sichergestellt sein, dass



Xlet1

root

dvb.certificate 1 dvb.certificate 2 Xlet2

Info.txt classes classesdvb.signature.1 dvb.signature.2dvb.hashfile dvb.hashfile

dvb.hashfile

dvb.hashfile

dvb.hashfilesublasses Xlet1.class Xlet2.classfool.class fool.class

sub1.class sub2.class

Bild 13. Authentifizierung von Applikationen



diese auf dem Übertragungsweg nichtverändert wurde. Das könnte durch einenVirus oder bewusste Manipulation ge-schehen sein. Dazu werden über alle Teiledie zu einer Applikation gehören, ein-schließlich der Daten, so genannte „HashFiles“ gebildet (Bild 13). Sie lassen schondie Veränderung eines einzigen Bits in ei-ner Applikation und an Daten erkennen.Damit auch das „Hash File“ selbst sicherist, wird es mit Hilfe des „Signature Files“gesichert. Über die mitgesendete „X.509“-Datei kann die MHP die Authentizität derSignatur feststellen. Das „X.509“-Zertifikatidentifiziert eindeutig den „Broadcaster“.Hierfür wird das bewähre „RSA PublicKey“-Verfahren verwendet, wobei der„Broadcaster“ einen geheimen privatenSchlüssel zur Erstellung der Signatur ver-wendet. Diese Signatur kann nur mit Hilfedes in der „X.509“-Datei mitgelieferten„Public Keys“ entschlüsselt werden.

Den im „X.509“-Zertifikat gespeicher-ten RSA-Schlüssel (Public Key) bekommtder „Broadcaster“ von einer nationalenOrganisation. Diese wiederum erhält ihnvon einer übergeordneten Organisation,wie zum Beispiel in Europa ETSI. Die Her-steller von MHP-Geräten bekommen an-dererseits so genannte „Root“-Zerifikatzugewiesen.

Eine Anzahl von „Root“-Zertifikaten,von denen alle gesendeten Zertifikate ab-geleitet werden müssen, wird bei der Her-stellung der MHP in ihren permanentenSpeicher eingetragen. Es könnte abernotwendig werden, den Satz von „Root“-Zertifikaten später einmal zu ersetzen,weil sie „gehackt“ wurden, weil eine grö-ßere Schlüssellänge benutzt werden solloder weil sie schon zu alt sind. Ein solcheAufrüstung (Update) geschieht durch dieBenutzung von „Root Certificate Manage-ment Messages“ (RCMM), die von derMHP nur ausgeführt werden, wenn siedurch mehrere Signaturen authentifiziertwurden.

Damit versucht man Sicherheitsproble-me, wie sie bei DVDs aufgetreten sind, zuvermeiden.

11. Ausblick

Die ursprünglich im Mai 2000 an dieStandardisierungsorganisation ETSI wei-tergereichte „MHP-Spezifikation 1.0“ wur-de in die „MHP-Spezifikation 1.0.1“ über-geführt. Grundlage hierfür bildeten die bis-her durchgeführten Arbeiten zur Imple-mentation des Standards. Praktisch allegroßen Firmen, die auf dem Feld der Un-terhaltungselektronik operieren, haben

sich der Umsetzung des über tausend-seitigen Standards gewidmet. Ebenso wiedie „Broadcaster“ und „Service“-Anbieter,die zwischenzeitlich eine Menge vonMHP-Applikationen erzeugt haben, dieauf dem Standard basieren.

Um aber nach vorne in Richtung „Inter-net Access“ und dem zugehörigen „Inter-net Access Profile“ zu schreiten, wurde inRekordgeschwindigkeit die „MHP-Spezifi-kation 1.1“ erarbeitet und bereits bei DVBverabschiedet.

Die Entwicklung im Medienbereichsteht jedoch nicht still. Es geht im Gegen-teil immer rascher voran. Schon sprichtman vom „MHP-Standard 2.0“, der ver-schiedene Erweiterungen gegenüber denbestehenden Spezifikationen erfahrensoll. Zu nennen ist hier das „Local HomeNetwork“, das eine Verbindung verschie-denster Geräte mit einer MHP zum Zielhat. Die Kommunikation soll hierbei auchdrahtlose Verbindungen im Haus mit ein-schließen. Darüber hinaus wird die Spei-cherung von Inhalten auf lokalen Festplat-tenspeichern in späteren Versionen vonMHP thematisiert. Letzteres hat bereitsunter dem Namen „TV-Anytime“ Aufmerk-samkeit erregt.





M. SIEBURG

Vergleich von MHP 1.0 mit MHP 1.11. Einleitung

Nur etwas über ein Jahr benötigte dieDVB-Gruppe zur Fertigstellung von MHP1.1 und präsentiert damit eine neue Versi-on, noch bevor die ersten Decoder fürMHP 1.0 auf dem Markt sind. Da die Er-weiterungen für das „Interaktive & Enhan-ced-Broadcasting-Profile“ jedoch sehrleicht zu implementieren sind und einfachüber ein „Firmware-Update“ auf die Emp-fangsgeräte übertragen werden können,ist die Hoffnung groß, dass MHP 1.1 baldauf allen MHP-Decodern zu finden seinwird. Neben der umfangreichen für dieHersteller optionalen Erweiterung DVB-HTML und dem nun spezifizierten „Inter-net-Access-Profile“ bietet es vor allemeine verbesserte Integration des „Interac-tion-Channels“ (interaktivität) sowie des„Persistent Storage“, also der Speiche-rung auf einem vorhandenen Datenträger.

2. Laden von Applikationen überden Rückkanal

Applikationen können in MHP 1.0 nurüber den Broadcast-Weg geladen wer-den, Daten für Applikationen, wie zumBeispiel Bilder, Texte- und Audiofiles, lie-ßen sich darüber hinaus noch zusätzlichüber den im „Enhanced Broadcasting Pro-file“ vorhandenen Rückkanal auf dasEmpfangsgerät laden. Diese Einschrän-kung für Applikationen ist in MHP 1.1 nungefallen. Damit wird es möglich, dem Zu-schauer wesentlich umfangreichere Appli-kationen zu präsentieren oder die Start-zeiten von Applikationen wesentlich zu re-duzieren. Die für eine Applikation zumStarten wesentlichen Daten und Klassenwerden wie bisher gesendet, „exotische-re“ bzw. seltener genutzte Teile der Appli-kation können dagegen über den Rückka-nal („interaction channel“ oder Interak-tionskanal) nachgeladen werden. Selbst-verständlich lassen sich auch ganze Ap-plikationen über diesen Kanal laden. Da-mit könnte ein über den Broadcast-Kanalgesendeter EPG wesentlich umfangrei-chere Dienste und Inhalte anbieten —auch solche für die ein Broadcasting zuaufwendig erscheint.

3. Speichern von Applikationen

Bereits MHP 1.0 sieht die Möglichkei-ten vor, Daten auf einem optional vorhan-denen „persistenten“ Speicher auf demEmpfangsgerät zu speichern. Für JAVA-Classfiles war dies bisher analog zum In-teraktionskanal — nicht möglich. MHP 1.1bietet nun Applikationen die Möglichkeit,ihre Klassen über die „org.dvb.applicati-on.storage-API“ auf dem MHP-Terminalzu speichern und zu einem späteren Zeit-punkt wieder von dort zu laden. Die Kon-trolle über diesen Vorgang behält derBroadcaster über einen in der AIT (Appli-cation Information Table) gesendeten „Ap-plication Storage Descriptor“. Er enthälteine Versionsnummer, ein Prioritätsfeld,sowie ein Flag mit dem das Empfangsge-rät dazu aufgefordert werden kann, auf je-den Fall die gespeicherte Version der Ap-plikation zu laden. Damit kann — entspre-chend kraftvoll ausgestattete Empfangs-geräte vorausgesetzt — das Starten voninteraktiven Diensten beim wiederholtenauswählen eines Services erheblich be-schleunigt werden.

4. „Stored Services“

Die Möglichkeit, Applikationen sowohlvom Rückkanal als auch vom persistentenSpeicher zu starten, ermöglicht eine fürdas Fernsehen ganz neue Klasse von in-teraktiven Diensten — den „StandaloneApplications“. Um dabei nicht das Service-Modell in MHP zu durchbrechen, werdensie in so genannten „Stored Services“ ge-kapselt und treten damit als eigenständigeServices, gleichberechtigt zu den „Broad-cast Services“ auf. Ein gespeicherter Ser-vice kann durch den Broadcaster angelegtwerden indem er das „Storage Property“in dem „Application Storage Descriptor“auf „stand alone“ setzt. Setzt er es dage-gen auf „broadcast related“ wird die zuspeichernde Applikation — analog zurMHP 1.0-Applikation — allein über denBroadcast-Service gesteuert. Wie dieklassischen Broadcast-Services könnenauch gespeicherte Services mehrere Ap-plikationen enthalten. Applikationen ausanderen Services erlauben innerhalb ih-res Services weiter aktiv zu bleiben bzw.



MHP1.1 definiert die nächste Genera-

tion von MHP-Empfangsgeräten. Ne-

ben einigen neuen Features wie

SmartCard-Unterstützung, Speichern

von Applikationen, Plugins und DVB-

HTML, verfeinert und verbessert es

vor allem bestehende APIs aus

MHP1.0. Es implementiert nun end-

lich auch das bereits in MHP 1.0 in

Ansätzen vorhandene Internet-Ac-

cess-Profile. MHP 1.1 baut dabei auf

der ersten Corrigenda-Version von

MHP1.0.1 auf. Die wichtigsten De-

sign-Ziele waren eine maximale

Rückwärtkompatibilität, eine einfache

Integration in bestehende MHP-1.0.1-

Systeme, die Eignung für „Embed-

ded“-Systeme sowie die Erweiterbar-

keit für zukünftige Technologien wie

beispielsweise TV-Anytime.

Dipl.-Ing. Marc Sieburg ist Geschäftsführerder ms² GmbH, SchlierseeEr arbeitet ferner für das IRT in den DVB-Gruppen zur Spezifikation von MHP: „DVB-TAM“, „DVB-Java“, „DVB-Application Lifecy-cle, Signalling & Security“, MHP-Corrigenda,zeitweise auch in der DVB-HTML und MHP-Gruppe

1E:\FKT\Beitraege\Heft08_9\Sonderdruck\Sieb.vpSamstag, 11. August 2001 08:19:22


können selbst in anderen Services aktivbleiben, falls es diese erlauben.

Möglich werden damit wesentlich kom-plexere Multi-Bouquet-EPGs und Applika-tionen, die in MHP 1.0 nur dem Navigatordes MHP-Terminal-Herstellers vorbehal-ten waren.

Nicht verwechselt werden dürfen „Sto-red Services“ mit dem Speichern von Au-dio- und Video-Diensten, wie es zum Bei-spiel TV-Anytime definiert. Das bleibt zu-künftigen Versionen von MHP vorbehal-ten.

5. Plugins

Plugins sollen es der MHP ermögli-chen, zusätzliche, nicht im Standard ent-haltene Datenformate zu decodieren. Ty-pische Kandidaten für Plugins wären zumBeispiel das aus dem Internet bekannteFlash, OpenTV, MHEG und Programmezum Ausführen beliebiger anderer pro-prietärer Inhaltsformate. Um jedoch dieDecodierungsprogramme für diese For-mate nicht jedesmal neu auf das Emp-fangsgerät laden zu müssen, benötigtman eine API, die es erlaubt, diese Pro-gramme fest auf der Box zu speichern undfür ein bestimmtes Datenformat zu regi-strieren (Bild 1).

Von gespeicherten Applikationen zuPlugins ist es also nur noch ein kleinerSchritt. Und so definiert MHP 1.1 nunauch die in MHP 1.0 bereits im Architek-tur-Kapitel angekündigten Plugins. Aller-dings beschränkte man sich dort auf dieDefinition der so genannten „interoperab-len“ Plugins. Das sind Plugins, die selbstwieder in DVB-J geschrieben wurden.MHP definiert zwei Wege Plugins zu sig-nalisieren, die auch miteinander kombi-niert werden können. Zum einen bestehtdie Möglichkeit, Plugins im „Plugin De-scriptor“ zu definieren und sie für be-stimmte Applikationstypen zu registrieren,und zwar so, wie sie im „Application Des-criptor“ in der AIT signalisiert werden. Al-lerdings müssen neue Applikationstypenzuvor bei DVB registriert werden. Dieswürde die Definition für Plugins in vielenFällen unnötig komplizieren. Daher be-steht zusätzlich die Möglichkeit für Appli-kationen, die innerhalb eines Plugins aus-geführt werden sollen („Plug-in Applica-tions“), mittels des „Delegated ApplicationDescriptors“ die „Applications ID“ desPlugins, in dem sie ausgeführt werdensollen, anzugeben. Damit kann eine MHP-Applikation leicht zu einem Plugin erwei-tert werden. Die vorherige zeitaufwendigeRegistrierung eines neuen Applikations-typs bei DVB kann entfallen.

Zusätzlich zur Möglichkeit Plugins zusignalisieren wurde eine API definiert, umApplikationen, die innerhalb eines Pluginsausgeführt werden, von anderen MHP-Applikationen aus zu adressieren und mitdiesen Nachrichten auszutauschen(org.dvb.application.inner-Package). Dieorg.dvb.application.plugin-API definiertdie notwendigen Schnittstellen vom Pluginzum MHP-System.

Die Plugin-API wurde dabei so offengehalten, dass selbst komplexeste For-mate, wie das in MHP 1.1 neu definierteDVB-HTML, als Plugin realisiert werdenkönnen.

6. DVB-HTML

Die bei weitem umfangreichste Erwei-terung in MHP 1.1 ist die Definition DVB-HTML. Es ist für alle drei MHP-Profiles(Enhanced-, Interactive- und Internet-Ac-cess-Profile) vorgesehen, ihre Implemen-tierung jedoch für die MHP-Hersteller op-tional. Damit bieten sich die Kapitel überDVB-HTML in MHP 1.1 auf den erstenBlick zum Überblättern an — was die Ein-arbeitungszeit in dieses Papier erheblichreduzieren würde. Da es jedoch möglichist, DVB-HTML als Plugin auf jede beliebi-ge MHP-1.1-Box herunterzuladen und —vorausgesetzt sie hat genug Speicher undCPU-Leistung — auch zu speichern undauszuführen, ist eine weite Verbreitungauf zukünftigen MHP-Systemen durchauswahrscheinlich. Zusätzlich erscheintdurch diese Lösung auch weniger kräftigausgestatteten MHP-Systemen, die miteiner Implementierung von DVB-HTMLnoch überfordert wären, die Migration zuMHP 1.1 wesentlich attraktiver. Für denInhalteanbieter ergibt sich durch DVB-HTML theoretisch die Möglichkeit, beste-hende HTML-Autorentools auch für DVBzu verwenden. War die Einführung vonDVB-J schon eine wesentliche Vereinfa-chung der Entwicklung von interaktivenInhalten, so wird es durch DVB-HTMLnoch einfacher und damit günstiger, inter-aktive Zusatzangebote zu erstellen. ImIdealfall können sie sogar für das Internetund DVB gleichzeitig erstellt werden.Durch Verwendung von Stylesheets kön-nen die gleichen Inhalte für das Internet

und das Fernsehen jeweils optimal forma-tiert werden. Praktisch gibt es jedoch eini-ge Einschränkungen. So ist das Internetauf die Bedienung mit der Computer-Maus ausgerichtet, DVB-HTML muss je-doch auch mit der konventionellen Fern-steuerung bedienbar bleiben. Wer diesnicht beim Design der HTML-Seite be-rücksichtigt, wird unter Umständen nurwenig Benutzer für seine interaktivenDienste finden.

Auch der verfügbare Platz zur Präsen-tation der Inhalte unterscheidet sich er-heblich zwischen Computer und Fernse-her. Sind auf dem Computer flimmerfreie1024×768 Pixel Auflösung Standard, sostehen auf dem Fernseher nur 720×576Pixel zur Verfügung. Von denen schnei-den allerdings viele Fernseher noch einenRand weg, und wegen der 50-Hz-Interla-ced-Darstellung der Fernsehers muss inder Regel ein größerer Zeichensatz ver-wendet werden, um ein die Augen starkermüdendes Flimmern zu vermeiden. Be-denkt man noch die beim Fernsehen er-heblich größere Distanz des Betrachterszum Bildschirm, bekommt man schon einGefühl für die unterschiedlichen Anforde-rungen, die Fernsehen und Computer anden Web-Designer stellen. Unter diesenGesichtspunkten erwiesen sich die beste-henden Inhalteformate des Internets alsnicht ausreichend für das Fernsehen. Da-rüber hinaus galt es, die im Internet vor-handenen Inkompatibilitäten verschiede-ner Browser und die dem Benutzer am PCabverlangte Zumutung, permanent neueSoftware zu installieren, zu vermeiden.

Als Basis für DVB-HTML wurdeXHTML1.0 gewählt. Das ist der derzeitneueste, auf XML basierende Standarddes W3C-Konsortiums und bietet die not-wendige technische Basis und Flexibilitätfür DVB. CSS (Cascading Stylesheets) er-laubt die dynamische Anpassung desLayouts an das jeweilige Medium. Sokann im Idealfall der gleiche Inhalt für dasInternet und das Fernsehen erstellt wer-den, das Layout bestimmen für das jewei-lige Medium definierte Stylesheets. Da dervom W3C-Konsortium für das Fernsehenvorgesehene Medientyp „Screen“ einigeFeatures von MHP nur unzureichend defi-niert, wurde er vor allem um die die gra-

Sonderdruck aus FERNSEH- UND KINO-TECHNIK – 55. Jahrgang – Nr. 2001 11


„MHP API”

InteroperableMHP Applications

Delegatedappl. type ‘A’

Delegatedappl. type ‘B’

Plug-in A

Plug-in BTransportProtocols

System Software

Resources

ApplicationManager

„Interoperable” plug-in

Implementationspecific plug-in

Bild 1. Architektur

der MHP mit Plugins



phischen Fähigkeiten betreffenden Para-meter zum Medientyp „dvb-tv“ erweitert.Ein detailliertes auf der Box bereits instal-liertes DVB-HTML-Stylesheet soll für eineinheitliches „Default“-Layout der Emp-fangsgeräte sorgen. Durch das Mitsendeneigener Stylesheets kann der Broadcasterdas Layout seines Services dann nochbeliebig an seine Bedürfnisse anpassen.

Als Scriptsprache wurde ECMA-Scriptverwendet. Das ist eine standardisierteund frei verfügbare Form der bekanntenScript-Dialekte (zum Beispiel JAVA-Script)des Internets. Mittels DOM (DocumentObject Model) können solche Scripte aufeinzelne Komponenten der DVB-HTML-Seite zugreifen und diese zum Beispieldynamisch verändern. ECMA-Scripte ha-ben Zugriff auf Cookies mit denen DVB-HTML-Seiten kleinere Informationen tem-porär auf dem Empfangsgerät speichernkönnen sowie auf die CSS und über einespezielle Schnittstelle auf alle in DVB-Jdefinierten APIs. Da in ein DVB-HTML-Dokument zusätzlich noch Xlets alsoMHP-JAVA-Applikationen eingebettet wer-den können und über die Schnittstelle zwi-schen ECMA-Script und DVB-J ausECMA-Script heraus angesprochen wer-den können, bietet das für den Inhaltean-bieter eine ungeahnte Flexibilität. Es wirdmöglich, Inhalte und Funktionalität bei derEntwicklung zu trennen. Web-Designerentwerfen mit XHTML-Autorentools, dieInhalte und das Layout und greifen auf ineingebetteten Xlets gekapselte komplexe-re Funktionen zu. Dies können zum Bei-spiel komplexe Berechnungen, Animatio-nen, oder Funktionen zur Kommunikationmit einem Server sein. JAVA-Entwicklerwerden auf diese Weise vom Web-Designentkoppelt. Sowohl JAVA-Entwickler alsauch Web-Designer können sich der Auf-gabe widmen, auf die sie spezialisiertsind. Viele einfachere Funktionen lassen

sich auch direkt in ECMA-Script entwi-ckeln. Eine zusätzliche Anbindung vonDVB-J (Xlets) könnte daher überflüssigerscheinen. Bei komplexeren Funktionenwird ECMA-Script jedoch schnell sehr un-handlich und die für JAVA verfügbaren Ent-wicklungsumgebungen erlauben in die-sem Fall eine wesentlich bessere und effi-zientere Applikationsentwicklung.

Gerade durch diese Integration vonDVB-J in DVB-HTML entsteht ein Werk-zeug, mit dem sich hochkomplexe interak-tive Inhalte auf extrem einfache und kom-pakte Weise in Module zerlegen lassenund damit besser beherrschbar werden.Die damit mögliche Trennung von Inhaltenund Funktionen vereinfacht den Produk-tionsprozess bei der Content-Erstellungund ist damit ein wichtiger Schritt für dieBereitstellung hoch aktueller interaktiverAngebote.

7. Internet-Access-Profile

Bereits in MHP 1.0 wird ein „Internet-Access-Profile“ definiert, eine detaillierteSpezifikation dieses Profils sucht man je-doch vergeblich. MHP 1.1 holt dies nunnach durch die Definition von Schnittstel-len von DVB-J zu „Internet-Client-Applica-tions“. Das org.dvb.internet-Package defi-niert ein flexibles und erweiterbares Fra-mework, um verschiedene Internet-Clients aus MHP-Applikationen herausanzusprechen. Die Schnittstellen zu ei-nem WWW-Browser, einem E-Mail-Clientsowie einem Usenet-Client wurden be-reits definiert. So können MHP-Applikatio-nen einen resident auf der Box installier-ten WWW-Browser mit einer bestimmtenURL starten, Bookmarks setzen, Informa-tionen über den WWW-Browser abfragen,einen E-Mail-Client mit vordefinierten Fel-dern starten, E-Mails senden sowie einenUsenet-Client an definierter Adresse star-

ten und Newsgruppen registrieren. DieDetails der Clients wurden dagegen be-wusst nicht definiert.

Kaum jemand wagt eine Prognoseüber das Internet in fünf oder zehn Jah-ren, und eine Entscheidung für einen kon-kreten Internet-Client (zum Beispiel Mozil-la) kann morgen schon veraltet sein. DerStandard hat daher nur eine API definiert,die es erlaubt, resident auf der Box instal-lierte Internet-Clients anzusprechen. Erlässt es jedoch bewusst der Wahl desHerstellers und des Marktes überlassen,um welchen konkreten Client es sich tat-sächlich handelt und wie der einzelneHersteller die permanenten neuen Versio-nen im Internet auf seinem Empfangsge-rät umsetzt (zum Beispiel durch regelmä-ßigen Download, CDs in Fernsehmagazi-nen, Wartung durch den Fachhändlerusw.).

8. Open Card Framework (OCF)

Schon MHP 1.0 erlaubt grundsätzlicheine Anbindung von Smartcards über dieCA-API (Conditional Access) über dasauch ein „Common Interface“ angesteuertwerden kann. Da diese API jedoch mit derZielrichtung „Conditional Access“ definiertwurde, ist sie für allgemeine Smartcardsnicht unbedingt geeignet. Hier entschiedsich die DVB-Gruppe für das in der JAVA-Welt etablierte „Open Card Framework“,allerdings in einer abgespeckten Version(Embedded Open Card Framework). Eserlaubt die Ansteuerung beliebiger Smart-cards. Möglich wird dadurch zum Beispieldie einfache Anbindung von Karten fürHomebanking, Geldkarten oder Speicher-karten. Die Implementierung der Smart-card-Leser-Hardware bleibt allerdings fürMHP-Hersteller optional und damit denKräften des freien Marktes überlassen.





Documents

R. SEDLMEYER Multimedia Home Platform — Standard 1.0 · Komposit Standardbildschirm. 3. Services und Applikationen Kernstück der Innovation beim Entwurf einer MHP war stets die