MHP-Integration in Linux-TV

Die Entwicklung des interaktiven Fernsehens wurde durch die Digitalisierung des Fernsehens vorangetrieben. Die Möglichkeiten, über reine Bild- und Toninformationen hinaus beliebige Daten einzubetten, eröffneten die Integration neuer Mehrwertdienste und erhöhten die Attraktivität des Mediums. Da der ursprüngliche Standard des digitalen Fernsehens keine solchen Dienste berücksichtigte, mussten zunächst eigene Plattformen entwickelt werden. Die anfänglichen, proprietären Lösungen verschiedener Unternehmen waren jedoch untereinander inkompatibel. Dies unterstrich die Notwendigkeit eines einheitlichen Standards für interaktive Fernsehdienste.

Als Reaktion auf die Probleme inkompatibler proprietärer Lösungen entstand die Multimedia Home Platform (MHP). Im Jahr 2000 vorgestellt, vereinte dieser europäische Standard die Wünsche verschiedener Interessengruppen und bot umfassendere Möglichkeiten als alle vorherigen Plattformen für interaktive Mehrwertdienste. MHP sollte nicht nur in Europa, sondern auch weltweit die anderen Lösungen ersetzen. Die Entwicklung von MHP zielte auf eine horizontale Marktstruktur ab, im Gegensatz zu den vertikalen Strukturen der proprietären Systeme. Die Einbindung der MHP in Systeme wie das Digitale Video Projekt stellte jedoch eine Herausforderung dar, da zu diesem Zeitpunkt noch keine nahtlose Integration existierte.

Das Dokument vergleicht MHP mit anderen Plattformen für interaktives Fernsehen, insbesondere mit OpenTV. OpenTV, entwickelt von Thomson und Sun, ist weltweit auf über 10 Millionen Set-Top-Boxen installiert und wird von ARD digital genutzt. Der Hersteller bezeichnet OpenTV als weltweit führend in der Entwicklung interaktiver Medienlösungen. Im Gegensatz zu solchen proprietären Lösungen wie OpenTV, die oft nur eine Art der Interaktivität unterstützen, bietet MHP sowohl lokale als auch echte Interaktivität (mit Rückkanal) in einem Standard. Die horizontale Marktstruktur von MHP, die Konsens zwischen allen Beteiligten (Programm- und Diensteanbieter, Netzwerkbetreiber, Endgerätehersteller) ermöglicht, wird als Vorteil gegenüber den vertikalen Strukturen der proprietären Systeme hervorgehoben.

MHP bietet ein breites Spektrum an interaktiven Anwendungen. Zu den zentralen Funktionen gehören elektronische Programmführer mit zusätzlichen Bildern und Videosequenzen, interaktive Spielshows und der Zugriff auf Zusatzinformationen aus dem Internet. Weitere angedachte Anwendungen sind Home-Shopping, Home-Banking, Pay-per-View, Video on Demand, E-Mail und Computerspiele. Die Interaktivität umfasst sowohl die lokale Interaktion auf dem Empfangsgerät als auch die echte Interaktion mit dem Inhaltsanbieter, wofür ein Rückkanal erforderlich ist. Die Entwicklung von MHP umfasste verschiedene Profile, von denen die ersten beiden in der MHP-Spezifikation 1.0 implementiert wurden und im Mai 2000 dem ETSI vorgelegt wurden. Spätere Versionen enthielten Fehlerkorrekturen und detailliertere Spezifikationen, beispielsweise für den Internetzugang.

Zum Zeitpunkt der Erstellung des Dokuments existierte keine MHP-Implementierung, die sich ohne Modifikationen in das System des Digitalen Video Projekts (DVP) integrieren ließ. Eine nahtlose Integration würde Änderungen auf Quelltextebene an bestehenden Lösungen erfordern, was mit hohen Kosten verbunden wäre, da diese Implementierungen nicht frei verfügbar sind. Diese Tatsache stellte eine zentrale Herausforderung dar, da das DVP ein offenes System anstrebte und kostengünstige, offene Lösungen bevorzugte. Die Notwendigkeit, eine Lösung zu finden, die ohne solche Modifikationen auskommt, wurde als vorrangig angesehen.

Das Digitale Video Projekt (DVP) basiert auf dem Open-Source-Prinzip. Ein Großteil des Systems besteht aus im Quelltext verfügbaren Komponenten. Dieses Prinzip war für die Integration von MHP-Anwendungen von entscheidender Bedeutung. Eine proprietäre, geschlossene MHP-Lösung widerspräche dem Grundprinzip des DVP. Daher war die Suche nach einer offenen und kostengünstigen Lösung für die Integration von MHP-Anwendungen unerlässlich, um die Prinzipien des Projekts zu wahren und die spätere Anpassung und Weiterentwicklung zu gewährleisten.

Die im Markt verfügbaren MHP-Lösungen waren zum Zeitpunkt des Berichts größtenteils proprietär. Dies führte zu hohen Kosten, insbesondere wenn Quelltextänderungen für die Integration notwendig waren. Die Unverfügbarkeit des Quellcodes erschwerte die Anpassung an die spezifischen Anforderungen des DVP. Die proprietären Lösungen standen im Gegensatz zum Open-Source-Ansatz des DVP, der auf offenen Standards und freiem Quellcode basierte. Die Kosten und die mangelnde Flexibilität der proprietären MHP-Lösungen stellten somit erhebliche Hürden für die Integration in das DVP dar.

Die Architektur der MHP-DVP-Integration ist modular aufgebaut, um eine flexible Anpassung an verschiedene Anforderungen zu ermöglichen. Die meisten Pakete und Module werden innerhalb des Video Disc Recorders (VDR) als Plugin realisiert, wobei die Plugin-Schnittstelle von VDR genutzt wird. Dieser modulare Ansatz erlaubt die unabhängige Entwicklung und Integration einzelner Komponenten. Die Kommunikation zwischen den Modulen erfolgt über definierte Schnittstellen. Die Integration in VDR nutzt die von VDR bereitgestellten Klassen und Schnittstellen, um auf Hardwarekomponenten zuzugreifen und Daten auszutauschen. Der Austausch mit der MHP-Java-Umgebung erfolgt über den XletManager, während die Kommunikation mit dem X-Windows-System direkt über dessen API läuft.

Die grafische Ausgabe der MHP-Anwendungen kann auf verschiedene Weisen erfolgen. Eine Möglichkeit ist die Verwendung einer Grafikkarte mit TV-Ausgang, die zwar unbegrenzte grafische Möglichkeiten bietet, aber von VDR nicht direkt unterstützt wird. Die bevorzugte Lösung ist die Darstellung über den Videoausgang einer DVB-Karte (Premium-Ausführung). Diese Methode unterliegt jedoch Einschränkungen hinsichtlich Farbtiefe und Auflösung (z.B. maximal 256 Farben im OSD). Alternative Methoden sind die MPEG-Kodierung von Einzelbildern und die Java-interne Ausgabeerfassung. Die Wahl der Methode beeinflusst die Performance und die benötigte Rechenleistung. Der Zugriff auf den Framebuffer der Grafikkarte ist über VDR nicht direkt möglich, was eine weitere Einschränkung darstellt.

Die Softwarekomponenten umfassen die Java Runtime Environment (JRE), mindestens Version 1.1.8, das Java Media Framework (JMF) und das JavaTV API. Die JRE-Variante von Sun wird verwendet, obwohl andere Implementierungen (z.B. von IBM) in Bezug auf Geschwindigkeit und Speicherbedarf Vorteile bieten könnten. Für die MHP-APIs wurde aufgrund fehlender freier Implementierungen SNAP2 GEAR verwendet. Diese Entwicklungsumgebung enthält zwar die notwendigen Pakete für die grafische Ausgabe, jedoch fehlen wichtige Komponenten für die Steuerung der DVB-Karte und die Ausführung aktueller MHP-Anwendungen. Zur Demonstration wurde eine eigene MHP-Applikation entwickelt. Die Steuerung des Systems kann über Tastatur oder Infrarotfernbedienung (LIRC) erfolgen. Das Betriebssystem des Prototyps war SuSE Linux 8.0.

Ein Merkmalmodell beschreibt die Variabilitäten und Parameter des Systems. Durch die Festlegung dieser Parameter kann eine Vielzahl von Systemen für die MHP-DVP-Integration erzeugt werden. Allein die Kombination verschiedener Varianten bei Applikationsteuerung und Ausgabe ermöglicht 36 verschiedene Systeme mit unterschiedlichen Hardware- und Softwareanforderungen. Die modulare Architektur erlaubt die einfache Erweiterung des Systems durch Hinzufügen weiterer Varianten. Das entwickelte System ist flexibel und anpassungsfähig an die spezifischen Kundenanforderungen. Die Architektur ist nicht vollständig, da aufgrund des Umfangs des MHP-Standards Einschränkungen, beispielsweise beim Datenempfang und der Applikationsverwaltung, vorgenommen wurden.

Die Darstellung der MHP-Applikationen auf dem Fernseher erfolgt über verschiedene Methoden. Eine Möglichkeit ist die Nutzung des On-Screen-Displays (OSD) einer DVB-Karte. Diese Methode bietet pixelgenaue Ansteuerung, ist aber durch die begrenzte Farbpalette (maximal 256 Farben) und den knappen Speicherplatz (ca. 90 KB) auf der DVB-Karte eingeschränkt. Die maximale Größe des darstellbaren Bereichs ist somit begrenzt. Eine zweite Variante ist die Darstellung über den Videoausgang einer DVB-Karte in Premium-Ausführung, wobei die MHP-Applikationen als MPEG-kodierte Einzelbilder (I-Frames) übertragen werden. Diese Methode ist flexibler und erlaubt eine bildschirmfüllende Darstellung, erfordert aber zusätzliche Rechenleistung für die MPEG-Kodierung. Eine weitere Option ist die Java-interne Ausgabeerfassung, bei der der grafische Output innerhalb der MHP-Java-Umgebung ermittelt und an das VDR-Plugin übermittelt wird.

Die Performance der Applikationsdarstellung wird durch verschiedene Faktoren beeinflusst. Die Verwendung des OSD der DVB-Karte kann zu längeren Darstellungszeiten führen, insbesondere bei kleineren Bildern, die häufiger gesendet werden müssen. Bei einfarbigen Bildern können die Zeiten bis zu zwei Sekunden betragen. Eine Möglichkeit zur Verbesserung der Performance ist die Übertragung der Daten als zusammenhängender Videostream anstelle von Einzelbildern. Dadurch entfällt das wiederholte Senden und die Dekodierung kann effizienter erfolgen. Das Weglassen der Skalierung, falls die Ausgabe der Applikation bereits in der richtigen Größe vorliegt, kann ebenfalls zu Zeitersparnissen führen. Die Wahl des Kodierverfahrens (MPEG-1 oder MPEG-2) und die Kodierqualität beeinflussen ebenfalls die Performance bei der MPEG-basierten Darstellung.

Für die Implementierung eines Prototyps wurde ein Standard-PC des Digitalen Video Projekts verwendet (Pentium 4 1.5 GHz, 512 MB RAM, 40 GB Festplatte, zwei DVB-Karten, SuSE Linux 8.0, VDR 1.2.5). Für die MHP-Schnittstelle wurde SNAP2 GEAR eingesetzt, da zum Zeitpunkt der Entwicklung keine frei verfügbare Version der MHP-APIs existierte. SNAP2 GEAR bietet zwar die benötigten Java-Pakete für die grafische Ausgabe, es fehlen jedoch wichtige Pakete für die Steuerung der DVB-Karte. Daher wurde zur Demonstration eine eigene, einfache MHP-Applikation (ein Quiz) erstellt. Tests der Ausgabedarstellung im OSD zeigten einen erheblichen Zeitaufwand, der durch Optimierungen (z.B. zusammenhängender Videostream, Weglassen der Skalierung) reduziert werden könnte.