Einsatz von IPTV zur Übertragung und Darstellung von Echtzeitdaten

Transcrição

Einsatz von IPTV zur Übertragung und
Darstellung von Echtzeitdaten
Maria I. Hauer
DIPLOMARBEIT
eingereicht am
Fachhochschul-Masterstudiengang
Digitale Medien
in Hagenberg
im September 2009
© Copyright 2009 Maria I. Hauer
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Hagenberg, am 20. September 2009
Maria I. Hauer
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
I
ix
Einführung und Grundlagen
1 Einleitung
1.1 Motivation . . . . . . . .
1.2 IPTV . . . . . . . . . .
1.2.1 IPTV Definition
1.2.2 IPTV Technik . .
1.3 Gliederung der Arbeit .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
3
4
14
2 Stand der Technik
2.1 Personalisierung & Interaktivität . . . . . . . . . . . . . .
2.2 IPTV Anbieter . . . . . . . . . . . . . . . . . . . . . . . .
2.3 IP Set-Top Boxen . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Arten von IP Set Top Boxen . . . . . . . . . . . .
2.3.2 Funktionalität . . . . . . . . . . . . . . . . . . . . .
2.3.3 Physische Schnittstellen . . . . . . . . . . . . . . .
2.4 IPTV Systeme . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Dreambox DM 800 HD PVR als Broadcast System
2.4.2 Ocilion als Unicast System . . . . . . . . . . . . .
2.4.3 aonTV als Multicast System . . . . . . . . . . . . .
2.4.4 Vergleich der Systeme . . . . . . . . . . . . . . . .
2.4.5 Trend . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Andere Technologien . . . . . . . . . . . . . . . . . . . . .
2.5.1 Multimedia Computer . . . . . . . . . . . . . . . .
2.5.2 Multimediale Mobiltelefone . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
17
18
19
22
23
25
25
27
31
32
36
37
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
2.5.3
v
IP Fernsehgeräte . . . . . . . . . . . . . . . . . . . . .
3 Zukunft des IPTV
3.1 Die nahe Zukunft von IPTV . . . . . .
3.1.1 Internet am Fernsehbildschirm
3.1.2 Yahoo Widget Channel . . . .
3.1.3 Zukunft für Internet am TV . .
3.2 Zukunftsvisionen . . . . . . . . . . . .
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Praktische Arbeit: Sports Notification System
4 Entwurf und Konzept
4.1 Ziele der Anwendung . . . . .
4.2 Anforderungen an das Plug-In
4.3 Präzisierung der Idee . . . . .
4.3.1 Der Inhalt . . . . . . .
4.3.2 Die Funktionen . . . .
4.3.3 Benutzeroberfläche . .
4.3.4 Programmlogik . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
39
40
42
44
45
47
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
49
50
50
51
53
55
5 Technologien
57
5.1 Hardwaretechnologien . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Softwaretechnologien . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Netzwerkprogrammierung . . . . . . . . . . . . . . . . . . . . 63
6 Implementierung
6.1 Das Plug-In . . . . . . . . . . .
6.1.1 Läuferinfo Modus . . . .
6.1.2 Listen Modus . . . . . .
6.1.3 Standort Modus . . . .
6.1.4 Interaktion zwischen den
6.2 Server und Datenübertragung .
6.2.1 Klasse Database . . . .
6.2.2 Klasse RPC_Server . .
6.3 Benutzeroberfläche . . . . . . .
III
Zusammenfassung
. . . .
. . . .
. . . .
. . . .
Modi
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
68
68
75
76
82
86
86
89
90
93
7 Resümee und Ausblick
94
7.1 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Inhaltsverzeichnis
vi
A Inhalt der CD-ROM
97
A.1 Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.2 Zusätzliche Ressourcen . . . . . . . . . . . . . . . . . . . . . . 97
Literaturverzeichnis
98
Vorwort
Während der Entstehung dieser Arbeit, als auch im Laufe meines Studiums
habe ich Unterstützung von einer Vielzahl an Personen erhalten, bei denen
ich mich hiermit bedanken möchte.
Zuerst möchte ich meinen Dank meinem Betreuer Mag. Volker Christian
aussprechen, welcher mich während dieser Arbeit und bei der Erstellung des
in der Arbeit beschriebenen Projekts tatkräfig, als auch konstruktiv unterstützt hat. Weiters gilt mein Dank meinen Studienkollegen, welche mein Studium an der Fachhochschule zu einem einzigartigen, besonderen Abschnitt
in meinem Leben gemacht haben.
Ein außerordentlich wichtiges „Danke“ gilt meiner gesamten Familie, ohne die ich dieses Ziel nie erreichen hätte können. Vor allem meinen Eltern
Veronika und Rudolf gilt ein großer Dank, da sie mich immer in all meinen
Entscheidungen und Lebenslagen unterstützt und motiviert haben und ohne
die dieses Studium, sowie diese Erfahrung nie möglich gewesen wäre. Auch
meiner Schwester Marlene danke ich für ihre unterstützenden, motivierenden
und ehrlichen Ratschläge, welche mir immer eine Hilfe waren und sein werden. Zusätzlich möchte ich auch meiner Tante Irene danken, die mir immer
unverzüglich und zuverlässlich mit Rat und Tat zur Seite stand.
Ein weiterer Dank gilt auch meinen Freunden, die mir immer geholfen
haben meinen Kopf hin und wieder frei zu bekommen und auf deren Unterstützung ich jederzeit zählen konnte.
vii
Kurzfassung
Durch aktuelle Entwicklungen des aufstrebenden IPTV Sektors verschmelzen
Fernsehen und Internet immer mehr. Technische Verbesserungen hinsichtlich
Bandbreite und Kompressionsmethoden machen Internetprotokoll-Fernsehen
zu einer ernstzunehmenden Konkurrenz des Digitalen Video Broadcasting
(DVB). Vor allem durch die aufkeimenden Ideen und Innovationen hinsichtlich Personalisierung und Interaktivität entwickelt sich diese TV-Übertragungstechnik zum zukünftigen Fernseherlebnis.
Die gegenwärtige Technik ermöglicht endlich eine adäquate Darstellung
von Web- oder Echtzeitinhalten (welche über das Netzwerk bezogen werden)
auf dem Fernsehbildschirm. Durch Entwicklungen wie dem Yahoo Widget
Channel, welcher es dem Benutzer ermöglicht, Echtzeitinformationen (wie
das aktuelle Wetter oder die neuesten Nachrichten) neben einem Film auf
dem Bildschirm erscheinen zu lassen, wird schon ein Einblick in mögliche
Zukunftsszenarien der Fernsehlandschaft gegeben. Zusätzlich werden, durch
neuartige Set-Top Boxen, (wie zB die Dreambox von DreamMultimedia) dem
Benutzer vollständig angepasste Personalisierungsmöglichkeiten in Hinsicht
auf die Benutzeroberfläche oder die empfangenen Inhalte (welche sich nicht
auf Video und Audio beschränken) geboten. Jene Set-Top Boxen bieten
Funktionalitäten, die es dem Benutzer erlauben Plug-Ins zu entwickeln und
auszuführen.
Diese Arbeit versucht nun diese neuen Entwicklungen und Wendungen
in der Fernsehlandschaft festzuhalten und zu beschreiben. Weiters wird ein
Projekt – das sich mit der Entwicklung eines Plug-Ins für die Dreambox beschäftigt – vorgestellt, welches Echtzeitinhalte auf das Fernsehgerät bringt
und diese für den Benutzer so sanft wie möglich in sein bisheriges Fernsehvergnügen einbettet. Hierbei soll gezeigt werden, wie gegenwärtig und
zukünftig versucht werden wird die Verschmelzung von Internet und Fernsehen sanft voranzutreiben, ohne dabei weder die technischen Möglichkeiten
des Systems, noch die Bedürfnisse des Benutzers außer Acht zu lassen.
viii
Abstract
Current trends in the IPTV sector show that television and internet are constantly merging. Furthermore technical enhancements regarding bandwidth
as well as data compression enable IPTV to be a serious competition for
DVB. Burgeoning ideas and innovations concerning personalization and interactivity are the ingredients to place this TV technology at the forefront
of the future television experience.
Present techniques now allow an adequate presentation of web and real
time content (obtained via network) on the television screen. Current developments as for example the Yahoo Widget Channel demonstrate a possible
future scenario of what the TV scenery might look like. Yahoo Widget Channel offers a broad variety of miniature applications for television. These applications are able to deliver real time information such as the current weather
or the latest news to the television screen while for example watching a movie. In addition new set top boxes (i. e. the Dreambox by DreamMultimedia)
also provide techniques and functionalities to create and run personalized
applications. These enhancements support the concept of perfect user driven personalization regarding the Graphical User Interface (GUI) and/or the
shown content besides audio and video.
The recent developments and alterations of the television landscape regarding IPTV are what this thesis focuses on. Furthermore a project about
the development of a plug-in for the Dreambox is introduced and described,
which engages in bringing real time content via IP to the television screen.
Additionally this project attempts a smooth assimilation of the given information and developed interface into the users hitherto TV experience. The
goal is to depict existent and future efforts to gently push the fusion of internet and TV while considering the user’s needs as well as the technical
potentials of the system.
ix
Teil I
Einführung und Grundlagen
1
Kapitel 1
Einleitung
1.1
Motivation
“IPTV ist eine große Umwälzung der TV-Landschaft, größer als
seinerzeit die Einführung des Privatfernsehens...“ 1
Schon im Jahr 2006 war sich die Medienlandschaft der großen Veränderung,
die Internet Protokoll Television (IPTV) mit sich bringen würde, bewusst.
Doch was ist nun nach drei Jahren wirklich möglich? In welche Richtung hat
sich die Technologie entwickelt und welche Trends lassen sich davon ablesen?
Vergangene und aktuelle Studien belegen, dass der Trend hin zum IPTV
weiter anhält. Aus manchen Publikationen geht zwar hervor, dass es möglich
sein könnte, dass IPTV eine zusätzliche, gleichberechtigte Position neben Satellit, Kabel und Terrestrik einnehmen würde [15, Kap. 6]. Doch die aktuellen
Entwicklungen zeigen andere Trends auf.
IPTV bietet vielmehr zusätzliche Möglichkeiten als die bestehenden im
Bereich der Fernsehmedien. Außerdem fördert die Übertragungstechnik via
Internet Protokoll (IP) neue Interaktionen sowie Innovationen in diesem Gebiet und erlaubt die Umsetzung interessanter sowie ungewöhnlicher Ideen.
Genau dort liegt die Motivation dieser Arbeit. Welche Vorteile bietet IPTV
dem Benutzer gegenüber zB Satellitenfernsehen und wie funktioniert es eigentlich? Wodurch wird IPTV zu dem besonderen „Ding“, welches viele neue
Chancen auf dem Fernsehsektor bietet und welches das Sehvergnügen sowie
-verhalten des Sehers nachhaltig beeinflussen und verändern soll? Weiters
stellt sich hier auch die Frage: Ist der Fernsehzuseher im Grunde an mehr
Interaktion seinerseits interessiert? Doch sei hier soweit vorgegriffen, dass
schon Marshall McLuhan das Fernsehen als
„...ein Medium, das eine mitgestaltende Reaktion verlangt.“ [10]2
1
http://www.heise.de/newsticker/IPTV-Schrumpfende-Riesen-wachsende-Zwerge-/meldung/78585
2
http://www.heise.de/tp/r4/artikel/2/2050/3.html
2
1. Einleitung
3
bezeichnet und somit wäre die Frage bezüglich Interaktivität schon am Rande
beantwortet und bietet folglich ein weiteres Argument des Trends zu IPTV
und der Motivation zu dieser Arbeit.
1.2
IPTV
Zu Beginn sollte der Begriff IPTV, wie er in dieser Arbeit verwendet wird,
näher erläutert und die technischen Besonderheiten des Internet Protocol
Fernsehens erklärt werden.
1.2.1
IPTV Definition
Es gibt eine Vielzahl an Definitionen, bei denen zum Einem die Rede von
IPTV
„IPTV bezeichnet die digitale Übertragung von Fernsehprogrammen über ein digitales, breitbandiges Datennetz mit Hilfe des
IP3 .“ [3, S. 13]
und zum Anderen von Internet-Fernsehen ist.
„Beim Internet-Fernsehen werden Fernsehprogramme und Videoinhalte über das IP übertragen...“ [18]
Zusätzlich wird aber auch der Begriff Internet-Fernsehen oft für die Bezeichnung von WebTV oder „Internet video streaming“ verwendet [15, S.15], hier
ist das Empfangen und Sehen von Videoinhalten direkt via Internet gemeint.
Aufgrund dieser Tatsache wird in dieser Arbeit stets der Begriff IPTV verwendet, um jegliche Verwechslungen auszuschließen. Der zusätzlichen Unterscheidung der beiden Technologien dient eine kurze Gegenüberstellung (siehe
Tabelle 1.1).
Diese Unterschiede sind zwar nur wenige, zumal es hier nicht zielführend
ist weitere aufzuzeigen, da auch die Grenzen zwischen WebTV und IPTV
immer mehr verschwimmen. So gibt es jetzt Set-Top Boxen (STB), welche
direkt Inhalte aus dem Internet empfangen und darstellen können, diese ermöglichen es dem Benutzer – ohne sich vorher bei einem Provider registriert
zu haben – zB Youtube4 -Videos auf den Fernseher zu bringen5 . Aufgrund
dieser Tatsache stimmen nun schon einige der in Tabelle 1.1 genannten Unterschiede nicht mehr. Zur zusätzlichen Erläuterung dieser Verschmelzung
bezieht sich der praktische Teil (siehe Teil II) dieser Arbeit auf eine STB,
welche diese Eigenschaften vertritt.
3
Internet Protokoll
www.youtube.com
5
aus http://www.teltarif.de/intern/action/print/arch/2009/kw19/s34126.html
4
1. Einleitung
4
Tabelle 1.1: Hauptunterschiede zwischen IPTV & WebTV (Modifiziert aus
[15, S. 15/16]).
Benutzer
Empfangsgerät
Bandbreite
Video Format
Copyright
1.2.2
IPTV
IP Adressen sind bekannt
Set-Top Box u. Ä.
zwischen 1 und 4 Megabit/s
U. a.
MPEG2,
MPEG4
geschützte Inhalte
WebTV
jeder (unbekannte Benutzer)
meist PC
meist unter 1Mbit/s
Windows Media, RealNetworks, Quicktime,
Flash, ...
oft ungeschützt
IPTV Technik
Zum besseren Verständnis der Funktionalität von IPTV seien dessen technische Grundzüge hier kurz erläutert.
Um IPTV zu ermöglichen, bedarf es nicht nur einer passenden STB,
welche über eine geeignete Schnittstelle verfügt. Ein funktionierendes IPTV
System erfordert mehr als nur eine Komponente [2]:
Video Encoder
Dieser wandelt Audio- und Videoinformationen in ein komprimiertes Format um. Im Falle von IPTV gibt es laut [14, S.64] drei primäre Kompressionstechnologien: Moving Pictures Expert Group (MPEG)-26 , H.264 (auch
genannt MPEG-4 part 107 ) und VC-18 . H.264 bietet für ein IPTV System
die meisten Vorzüge, im direkten Vergleich mit der vorangegangenen Kompressionstechnologie von MPEG-2 [14]. Vorteile wie die Unterstützung von
hochauflösendem Fernsehen (High Definition Television bzw. HDTV), bessere Kompressionsleistung als MPEG-2 sowie die Tatsache, dass H.264 weniger
Bandbreite als MPEG-2 benötigt, um ein qualitativ gleichwertiges Signal zu
übertragen, lässt MPEG-4 im Allgemeinen und H.264 im Speziellen zur Vorzugskompressionstechnologie von IPTV werden [14]. Ferner den technischen
Vorteilen, wird die Kompressionstechnologie H.264 – welche ein freier internationaler Standard ist – von einer Reihe unterschiedlicher Organisationen
verwendet und ihr Gebrauch in deren Spezifikationen empfohlen [14]. Beispie6
http://www.chiariglione.org/mpeg/standards/mpeg-2/mpeg-2.htm
http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm
8
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.
aspx
7
1. Einleitung
5
le dafür sind das DVD Forum 9 , die Blue-ray Disk Association 10 oder auch
das Advanced Television Systems Committee (ATSC) 11 [14]. Auch können
Inhalte, welche mittels H.264 komprimiert wurden, von vielen unterschiedlichen Transportprotokollen (zB User Datagram Protocol (UDP) 12 , Transmission Control Protocol (TCP) 13 , Real-Time Transport Protocol (RTP) 14 ,
usw.) übertragen werden [14].
Video Server
Diese Art von Server besitzen Verbindungen zu Mediaarchivsystemen und
schicken die Mediainformationen per Multi- oder Unicast an die passenden
Clients bzw. STBs. In IPTV-System werden Video Server hauptsächlich für
interaktive Dienste, wie Video on Demand (VoD), oder zum Speichern von
aufgenommenem Material via persönlichem Videorekorder (PVR) [2] verwendet. Grundsätzlich sind Video Server dazu da, Videodaten (zB H.264
komprimierte Videostreams) zu speichern und zu verwalten [14]. Essentielle
Faktoren zum Design eines solchen Servers bzw. zur Erstellung einer derartigen Serverarchitektur sind die Skalierbarkeit der Speichergröße und der
Anzahl der zu verwaltenden Datenströme (Streams), die Wahl der passenden
Managment Software, als auch die Vielfalt der verfügbaren Schnittstellen [2].
Eingehend auf diese Faktoren verfügen Video Server über enorme Speicherund Prozessorkapazitäten, sowie rationelle In- und Ouput Funktionen, um
die entsprechenden IPTV Services bereitstellen zu können [2].
Middleware
Als Middleware wird in [2] die Soft- und Hardware bezeichnet, welche sich
bei IPTV für die Verbindung der Server- und Client-seitigen Komponenten
verantwortlich zeichnet. Respektive sind es Softwarepakete, welche sowohl
auf den Servern des IPTV-Anbieters, als auch auf dem Endgerät (Set-Top
Box) des Benutzers laufen [2]. Die Middleware am Client ist vergleichbar
mit der Sitzungs- und Darstellungsschicht des OSI-Schichtenmodells (Open
System Interconnect) [23] [14]. Sie fungiert als kommunizierende Verbindung
zwischen dem Betriebssystem der STB und den interaktiven IPTV Applikationen [14]. Diese Tatsache erlaubt es den Programmierern von Applikationen, diese zu erstellen ohne genauer über die systemspezifischen Protokolle
Bescheid zu wissen, es vereinfacht den gesamten Entwicklungsprozess [14].
9
http://www.dvdforum.org
http://www.blu-raydisc.com
11
http://www.atsc.org
12
http://tools.ietf.org/html/rfc768
13
14
10
1. Einleitung
6
Zugangsberechtigungssystem und Digitales Rechtemanagement
Generell besteht die Funktion dieses Systems darin, Inhalte zu schützen, zu
sendende Echtzeit Inhalte zu kontrollieren und die Übersicht über bereits
gesendete Inhalte zu behalten [2]. Bei IPTV arbeiten das Zugangsberechtigungssystem und das digitale Rechtsmanagement (DRM) mit einer Kombination aus Scrambling15 und Verschlüsselung [2]. Die technische Umsetzung
wird auf verschiedene Weisen realisiert zB mit Hilfe einer SmartCard, wie
sie zum Empfang der österreichischen öffentlich rechtlichen Sender (ORF)
obligat ist16 [2].
Benutzer-Endgerät
Als häufigstes Benutzer-Endgerät gilt die Set-Top Box (STB), deren technische Fähigkeiten aufgrund der ständigen Weiterentwicklungen und Variationen von IPTV je nach Anwendungsgebiet oder Service Anbieter unterschiedlich ausfallen [2]. Weiters unterstützen die meisten Set-Top Boxen eine Vielzahl unterschiedlicher Audio-, Video- und Bildformate [2]. Dies ist
notwendig, um die empfangenen, digitalen Media-Signale in vom Fernseher
darstellbare Signale umzuwandeln. Eine STB ist also eine Art Computer,
dessen grundsätzliche Aufgabe darin besteht, die Media-Daten via IP zu
empfangen, diese zu dekodieren und anschließend auf dem Fernsehgerät zu
präsentieren [14]. Die unterschiedlichen Arten von Set-Top Boxen, sowie deren genaue Funktionsweise werden unter Punkte 2.3 genauer erläutert.
Wird so ein System aus einem anderen Blickwinkel betrachtet, so sind
dafür teilweise differierende Komponenten wichtig, um via IP Medieninhalte
empfangen zu können. Abbildung 1.1 veranschaulicht die unterschiedlichen
Bestandteile einer einfachen Variante eines IPTV Systems und lässt die einzelnen Elemente in Client-seitig und Server-seitig unterteilen.
Einen essentiellen Teil Server-seitig stellt der IPTV Service Provider dar,
welcher dafür zuständig ist, dem Kunden bzw. Benutzer eines IPTV Systems
Dienste zum Empfang von Fernsehprogrammen und/oder zur Nutzung von
interaktiven Diensten (wie zB Video on Demand (VoD)) zur Verfügung zu
stellen [6]. D. h. er verwaltet das Angebot an möglichen Fernsehkanälen und
interaktiven Applikationen. Die zur Verfügung gestellten Medieninhalte werden dem Service Provider von etwaigen, unterschiedlichen Content Providern
geliefert [6]. In Abbildung 1.1 werden als Beispiel für mögliche Content Provider ein Broadcast Anbieter – welcher Fernsehkanäle liefert –, ein VoD Anbieter – der zB ein Angebot an Filmen und Serien bietet, die der Endkunde
selektieren und ansehen kann – und ein Web Content Provider – der dafür
zuständig ist, Webinhalte zu liefern – illustriert. Je nach vom Content Pro15
Damit ist eine spezielle Art der Signalverschlüsselung gemeint, welche Datenströme
innerhalb eines Transportstromes aufgrund von Kontrollwörtern verwürfelt [22]
16
digital.orf.at/show\_content.php?sid=83, hier bezeichnet als ORF Digital-Sat-Karte
1. Einleitung
7
Abbildung 1.1: Aufbaumodell einer einfachen Variante eines IPTV Systems
in Anlehnung an [6, Kap. 1], einerseits bestehend aus den Server-seitigen
Komponenten IPTV Service Provider sowie verschiedenen Arten von Content
Providern, andererseits bestehend aus den Client-seitigen Komponenten wie
zB der Set-Top Box und dem Fernsehgerät.
vider gelieferten Inhalt, unterscheidet sich die Übertragungsart. So können
Inhalte eines Broadcast Anbieters zB entweder per Digitalem Videorundfunk
via Satellit (DVB-S) oder via Kabel (DVB-C) an den Service Provider übertragen werden, wohingegen die Inhalte eines Web Content Providers auch
via IP übermittelt werden.
Zusätzlich zur indirekten Übertragung medialer Inhalte über den Service
Provider (wie in Abbildung 1.1) gibt es auch die Möglichkeit, dass Medieninhalte direkt an den Kunden übertragen werden. Somit wird dem IPTV
Benutzer die Option gegeben, zB Fernsehkanäle aus aller Welt zu empfangen, da theorethisch sämtliche Content Provider weltweit erreicht werden
können. Dabei ist kein zusätzlicher Service Provider zwischengeschaltet, welcher – wie in den meisten praktischen Anwendungen – eine Vorauswahl der
angeboteten Inhalte trifft [6].
Das IPTV Empfangsgerät stellt Client-seitig den wichtigsten Teil dar,
welches in Abbildung 1.1 als Set-Top Box illustriert und mit dem Fernseh-
1. Einleitung
8
Abbildung 1.2: Das adaptierte Referenzmodell zur Übertragung von IPTV.
Neben den IPTV relevanten Schichten (Video Encodierung, Video Paketierung und MPEG Transport Stream Konstruktion), sind die restlichen Schichten vor allem für den Datentransport zuständig. RTP bezeichnet das RealTime Transfer Protokoll, UDP das User Datagram Protokoll, TCP das Transmission Control Protokoll und IP das Internet Protokoll. Modifizierte Grafik
aus [14, Fig.3.4].
gerät digital (High Definition Multimedia Interface (HDMI)17 ) oder analog
(zB Syndicat des Constructeurs d’Appareils Radiorécepteurs et Téléviseurs
(SCART)18 ) verbunden wird. Diese wird neben dem Fernsehgerät auch mit
einem Breitbandanschluss verbunden, um somit via IP die oben genannten
Inhalte empfangen und verarbeiten zu können. Abgesehen von der Anschlussweise an den Fernseher beeinflusst auch die Art des Breitbandanschlusses –
zB via Digital Subscriber Line (DSL) oder Asymmetric Digital Subscriber
Line (ADSL) – die Empfangsqualität des IP Fernsehens [6]. Weiters gibt
es neben der Set-Top Box als eigenständiges Empfangsgerät auch sogenannte IP TV-Geräte, welche die Funktionalitäten einer STB bereits integriert
haben (mehr dazu in Abschnitt 2.5).
Abbildung 1.2 zeigt ein adaptiertes Referenzmodell hinsichtlich der Kommunikation in einem IPTV System und geht detailierter auf die Übertragung
von Medieninhalten ein. Um nun Daten vom Service Provider zum Kunden
zu übertragen, müssen diese zuvor alle Schichten des Referenzmodells von
oben nach unten passieren, um dann per zB DSL den Benutzer erreichen zu
17
18
http://www.hdmi.org/consumer/hd_experience.aspx
siehe [6, S. 293]
1. Einleitung
9
können [14]. Beim Benutzer müssen die Daten wiederum all jene Schichten
von unten nach oben durchlaufen. Jede Schicht zeichnet sich für eine andere Aufgabe verantwortlich und fügt den zu sendenden Daten zusätzliche
Informationen an oder verändert diese [14].
Weiters können die verschiedenen Schichten laut [14] in zwei grobe Kategorien eingeteilt werden:
Obere Schichten: Diese sind Video Encodierung und Paketierung sowie
die MPEG Transport Stream Konstruktion. Sie kümmern sich um spezielle IPTV Anforderungen und die Datenformate.
Untere Schichten: Im Gegensatz zu den Oberen Schichten befassen sich
diese vor allem mit dem tatsächlichen Datentransport.
Die Aufgaben der einzelnen Schichten teilt [14] folgendermaßen ein und
werden nachfolgend kurz zusammengefasst:
Video Encodierungs Schicht: Der Kommunikationsprozess startet damit,
ein unkomprimiertes, analoges oder digitales Signal zu komprimieren,
um einen sogenannten MPEG Elementary Stream 19 zu erhalten.
Video Paketierungs Schicht: In dieser Schicht wird der MPEG Elementary Stream in einzelne, sich überlappende Datenpakete – sogenannte
Packetized Elementary Stream (PES)-Pakete – konvertiert bzw. aufgeteilt.
Transport Stream Konstruktions Schicht: Hier werden die soeben erstellten PES Pakete in Transportpakete – sogenannte Transport Stream
(TS) Pakete – mit einer fixen Größe (188 Bytes) zerlegt.
Real-Time Transfer Protokoll (RTP) Schicht: Diese Schicht ist optional, wird dennoch von einer großen Anzahl von IPTV Applikationen
verwendet. Die RTP Schicht fungiert als ein Vermittler zwischen den
soeben beschriebenen Schichten und den unteren Schichten des Referenzmodells. Das Real-Time Transfer Protokoll stellt den wesentlichsten Teil dieser Schicht dar und unterstützt die Echtzeit-Datenübertragung von Mediadaten in einem IP Netzwerk.
Die unteren Schichten: Diese – d. h. die Transportschicht, die IP Schicht,
die Sicherungsschicht und die Bitübertragungsschicht dieses adaptierten Referenzmodells – erfüllen dieselben Aufgaben wie die jeweiligen
Schichten im bekannten OSI-Referenzmodell (siehe [23]).
19
http://www.iptvdictionary.com/iptv_dictionary_MPEG_Elementary_Stream_ES_
definition.html
1. Einleitung
10
Die Aufgaben der unteren Schichten dieses Refernzmodells weichen, wie
schon erwähnt, nicht von den Aufgaben des OSI-Refernzmodells ab, dennoch liegt gerade hier eine wichtige Eigenschaft, welche IPTV so interessant
erscheinen lässt.
Durch den Einsatz des IP auf der Vermittlungsschicht20 [23, Network
Layer S. 430] verfügt die bestehende Verbindung nicht nur über einen einseitigen Übertragungskanal (der Empfänger – in diesem Fall der Seher –
kann nur Daten empfangen, es besteht lediglich ein Hinkanal). Es existiert
auch ein Rückkanal, dementsprechend besteht für den Seher die zusätzliche
Möglichkeit Daten zu senden. Diese Tatsache erweitert die Palette an technischen Fähigkeiten eines solchen Systems um ein Vielfaches im Vergleich
zur Übertragung via Satellit zB. Der vorhandene Rückkanal stellt ein wichtiges Mittel der Interaktivität des IPTV dar [15]. Zusätzlich ist (wie schon
zuvor erwähnt) jeder Benutzer dadurch eindeutig identifizierbar und dieser
Umstand erlaubt es, die dargestellten Inhalte in Hinsicht auf den Seher zu
personalisieren. Durch diesen gegebenen Rückkanal wird nicht nur die Interaktivität unterstützt, ferner ergibt sich die Chance, die darzustellenden
Inhalte zu personalisieren, um auf den Benutzer bzw. Seher und seine Vorlieben eingehen zu können.
Überdies ist neben der Vermittlungsschicht natürlich auch die Transportschicht21 [23, Transport Layer S. 403] zur Datenübertragung bei einem
IPTV-System essenziell. Für IPTV wird hauptsächlich das User Datagram
Protocol (UDP) anstelle des Transmission Control Protocol (TCP) als Übertragungsprotokoll verwendet [7]. Der Grund dafür liegt wohl hauptsächlich
in der unterschiedlichen Art des Transports der beiden Protokolle.
TCP wird als
„zuverlässiges, verbindungsorientieres, Bytestrom Protokoll“ [8,
20]
bezeichnet, kurz gesagt es stellt sicher, dass alle gesendeten Daten beim
Emfpänger angekommen. TCP kümmert sich automatisch um beispielsweise
Zeitüberschreitungen und erneutes Senden der Daten [20]. Geht zB ein Datenpaket bei der Übertragung verloren, wird es ein weiteres Mal gesendet,
damit der Empfänger alle Datenpakete erhält. Ferner werden die Daten bei
TCP erst geschickt, wenn eine Verbindung zwischen IPTV Headend-Server
und dem Client-seitigen Empfangsgerät existiert [14]. Diese Eigenschaft kann
beim Senden von Daten zu Verzögerungen führen, da verlorene oder fehlerhafte Datenpakte wiederholt gesendet werden müssen und erst verspätet
beim Empfänger eintreffen [14].
UDP hingegen wird als
20
www.cisco.com/en/US/docs/internetworking/technology/handbook/Intro-toInternet.html#wp1020694
21
www.cisco.com/en/US/docs/internetworking/technology/handbook/Intro-toInternet.html#wp1020697
1. Einleitung
11
„unzuverlässiges, verbindungsloses, Datagramm Protokoll“ [8,20]
bezeichnet, es stellt nicht sicher, dass die Daten vollständig und korrekt
empfangen worden sind, auch muss keine Verbindung zwischen Server und
Client aufgebaut worden sein. Geht hier ein Paket beim Senden verloren, so
wird es nicht noch einmal geschickt. UDP kümmert sich lediglich um das
Senden der Mediendaten und nicht um die Fehlerbehandlung [14]. Diese Eigenschaft macht UDP zum idealeren Transportprotokoll für IPTV Systeme,
da IP Fernsehen als ein Echtzeitsystem bei Verzögerungszeiten gravierendere
Qualitätseinbussen verzeichnet, als bei fehlerhaften oder verlorenen Datenpaketen [14]. Demzufolge wird UDP mehrheitlich für IPTV Implementierungen
eingesetzt und um den Nachteil der nicht existenten Fehlerbehandlung auszugleichen, gibt es verschiedenen Ansätze, welche diese Funktionalität zB in
die am Netzwerk laufenden Applikationen einbauen oder in den Videodatenstrom selbst integrieren [14].
Neben den unterschiedlichen Protokollen zur Datenübertragung unterscheiden sich auch die Arten der Kanalübermittlung bei IPTV – hier wird
zwischen Unicast, Multicast und Broadcast unterschieden [6, S. 23ff]. Auf
die praktische Verwendung dieser differierenden Techniken wird zusätzlich
in Abschnitt 2.4 eingegangen.
Unicast
Abbildung 1.3 zeigt, dass bei dieser Art der Kanalübermittlung eine einzelne
Verbindung pro Client (IPTV Emfpangsgerät) zum Server besteht [14]. Die
technische Umsetzung eines solchen Systems ist zwar realtiv simpel, sie weist
jedoch einen gravierenden Nachteil auf: Ein solches System ist ineffizient, falls
mehrere Nutzer gleichzeitig zB denselben Fernsehkanal sehen möchten, denn
somit wird für jeden einzelnen Client eine Verbindung aufgebaut und die
gewünschte Information geschickt, dies wiederum führt dazu, dass sich beim
Server die Bandbreite mit der Anzahl der Verbindungen multipiziert (d. h.
je mehr Verbindungen umso größer die Bandbreite beim Server) [6]. Unicast
ist, aufgrund dieser Eigenschaften, für On-Demand IPTV Applikationen geeignet, bei denen jeder Benutzer seine eigenen Mediendaten empfängt [14].
Multicast
Im Vergleich zu Unicast stellt Multicast ein 1:n System dar, mehrere Clients
einer Gruppe erhalten dieselben Daten, wobei diese Informationen nur einmal vom Server gesendet werden. Eine Gruppe selbst wird zB durch einen
Fernsehkanal definiert, d. h. jeder Benutzer, welcher diesen Kanal auswählt,
erhält die gewünschten Daten [14]. Abbildung 1.4 zeigt, wie die Kanalübermittlung per Multicast beispielsweise aussehen könnte. Bei Multicast wird
somit nicht pro Client eine direkte Verbindung zum Server hergestellt [6]. Damit das möglich ist, müssen in einem Netzwerk spezielle Multicast-Router
1. Einleitung
12
Abbildung 1.3: Grundsätzliches System der Unicast Technologie für die
Kanalübermittlung bei IPTV. Pro IPTV Client wird vom Server des Service
Providers eine Verbindung hergestellt und die angeforderten Mediendaten
werden dem Client übermittelt(angelehnt an [14, Fig. 4.2]).
vorhanden sein, welche die Duplikation und Verteilung der Datenpakete auf
die richtigen Mitglieder der Empfangsgruppe übernehmen. Multicast ist jedoch im Vergleich zu Unicast ein etwas komplexeres System, da hier noch
die Verwaltung der Gruppen und die Verteilung der Pakete hinzukommt [6].
Durch diese Übertragungstechnik verringert sich die Anzahl der nötigen IP
Verbindungen in einem IPTV-System und die Daten gelangen nur zu jenen
Benutzern, welche diese auch angefordert haben. Somit stellt Multicast die
beste Kanalübermittlungstechnologie für Live IPTV Übertragungen dar [14].
Broadcast
Jene Kanalübermittlung schickt die Daten eines Fernsehkanals an alle Benutzer des Netzwerkes, egal ob ein Benutzer jene Informationen angefordert
hat. Somit stehen jedem Empfänger eines solchen Systems alle gesendeten
1. Einleitung
13
Abbildung 1.4: Grundsätzliches System der Mulitcast Technologie für die
Kanalübermittlung bei IPTV. Der Server des Service Providers schickt die,
von mehreren Clients angeforderten Mediendaten einmal. Die Router im
Netzwerk übernehmen das Duplizieren und Weiterleiten der gesendeten Daten, um jedem Client die passende Information bereitstellen zu können (angelehnt an [14, Fig. 4.3]).
Inhalte zur Verfügung [15]. Hier wird weder zwischen Gruppen unterschieden, noch werden Daten speziell für einen Client gesendet. Dies führt zu
Engpässen bei den Ressourcen des Empfangsgeräts, da dieses alle empfangenen Datenpakete verarbeiten muss. Zusätzlich unterstützt Broadcast kein
Routing [14].
1. Einleitung
1.3
14
Gliederung der Arbeit
Diese Arbeit gliedert sich grundsätzlich in drei Teile:
Einführung und Grundlagen: Hier wird auf die allgemeine Technik von
IPTV eingegangen, welche Besonderheiten es dabei zu beachten gibt.
Weiters werden verschiedene Möglichkeiten von IPTV Systemen beschrieben und miteinander verglichen. Diese unterschiedlichen Umsetzungen gehen vor allem auf die differierende Kanalübermittlung ein
– Multicasting, Unicasting und Broadcasting – und zeigen drei Systeme auf, welche als Repräsentanten dieser Techniken fungieren. Neben dem aktuellen Stand der Technik widmet sich dieses Kapitel auch
der Zukunft dieses Sektors, vor allem hinsichtlich der Darstellung von
Echtzeit- oder Webinhalten am Fernsehbildschirm. Es werden Möglichkeiten aufgezeigt, wie der IPTV Benutzer sein Fernsehvergüngen
personalisieren und Interaktion erreichen kann. Neben dem Aufzeigen
der nahen Zukunft werden mögliche Zukunftsvisionen erwähnt, wie das
Fernsehen bald aussehen könnte.
Praktische Arbeit: Sports Notification System: Dieser Arbeitsteil beschäftigt sich hauptsächlich mit dem praktischen Pendant, einem für
eine STB – die Dreambox – entwickelten Plug-In, welches es ermöglicht, Echtzeitdaten von Marathonläufern auf dem Fernsehbildschirm
darzustellen. Neben der Entstehung der Idee und der Entwicklung des
Konzepts wird weiters auf die verwendeten Technologien, sowie die letzendliche Implementierung und Gestaltung eingegangen.
Zusammenfassung: Als Abschluss werden die grundlegendsten Punkte der
Arbeit kurz aufgeführt und es wird ein kompakter Ausblick in die mögliche Weiterentwicklung der praktischen Arbeit gegeben.
Kapitel 2
Stand der Technik
Dieses Kapitel gibt einen kurzen Überblick über den jetztigen Stand der
Technik im Bereich des Internet Protokoll Fernsehens. Welche Möglichkeiten
hat der Benutzer, IPTV zu empfangen, wie unterscheiden sich diese verschiedenen Systeme voneinander und was verbindet sie?
Bevor jedoch unmittelbar auf die verschiedenen IPTV Technologien eingegangen wird, sollte ein kurzer Überblick über die bisherigen Überlegungen
hinsichtlich der Chance auf Interaktivität und Personalisierung bei einem
solchen System gegeben werden. Primär stellen diese beiden Charaktereigenschaften die Besonderheit des IP Fernsehens dar. Dier liegt sein Potential,
wodurch es sich maßgeblich von anderen TV Übertragungsarten (zB Kabel
oder Satellit) unterscheidet. Weiters handelt es sich bei der beschriebenen
praktischen Arbeit in Teil II um eine Möglichkeit der Personalisierung des
Fernsehens, aber dazu mehr im erwähnten Teil.
2.1
Personalisierung & Interaktivität
Wie schon unter Punkt 1.1 erwähnt, wird das Fernsehen von manchen Personen schon lange als Medium gesehen, das eine „mitgestaltende Reaktion
verlangt“ [10]. Genau diese Tatsache führt zum Punkt der Interaktivität im
TV, welche schon seit längerem in der Fernsehlandschaft vorhanden ist, sei
es in Form eines einfachen Rückkanals mit Medienbruch1 , zB Tele-Dialog
(TED)2 oder in Form eines vollwertigen Rückkanals, wie es bei IPTV der
Fall ist [15]. Ein vollwertiger Rückkanal hat einerseits den Vorteil, dass kein
Medienbruch erfolgt [22], andererseits ist – wie schon in Kapitel 1 erwähnt
– der Benutzer durch seinen Rückkanal eindeutig identifizierbar.
Die Chance auf Interaktivität eines IPTV Benutzers beginnt schon bei
minimalen Entscheidungsmöglichkeiten. Einerseits hat der Seher die Mög1
Der Rückkanal erfolgt über das Telefon, d. h. der Zuseher wechselt vom Medium Fernseher zum Medium Telefon.
2
TED wird seit Anfang der 1980er Jahre eingesetzt
15
2. Stand der Technik
16
lichkeit „ganz normal“ fernzusehen, andererseits kann er sich jederzeit zB
einen Film via VoD bestellen. Natürlich gibt es neben den Film- und FernsehAlternativen auch viele neue Möglichkeiten der Interaktivität bzw. der Einbindung des Sehers. So existieren Service-Provider, die eine Auswahl an Spielen bereitstellen, ferner gibt es Programme, die es dem Benutzer möglich machen, via TV einzukaufen (T-Commerce), d. h. der Benutzer kann per Klick
auf der Fernbedienung das von ihm gewünschte Produkt auswählen und kaufen [6, Kapitel 2]. Da der Anwender durch den vollwertigen Rückkanal eindeutig identifizierbar ist, kann ein solcher Einkauf passend zugeordnet und
das Produkt verrechnet werden. Derartige Entwicklungen auf diesem Sektor
verändern die Welt des Fernsehens nachhaltig.
Zusätzlich zur Interaktivität entwickeln sich vor allem am Sektor der Personalisierung eine beträchtliche Anzahl neuer Ideen und Lösungen. Gerade
die Tatsache, dass jeder Benutzer eines IPTV Systems eindeutig identifizierbar ist, ermöglicht es, Programme für den Benutzer zu erstellen oder Projekte
zu verwirklichen, die sich individuell dem Seher anpassen. Als Beispiel einer
einfachen Personalisierung dienen kollaborative Filter, welche aufgrund von
bestimmten Eigenschaften des Benutzers (zB demografische Merkmale) die
für ihn passenden Inhalte übermitteln. Dieses Prinzip ist nicht gänzlich neu,
denn es gibt schon seit einiger Zeit Digitale Video Recorder (DVR), welche
dem Benutzer automatisch Inhalte aufzeichnen, die aufgrund seines vergangenen Sehverhaltens gewählt wurden. Ein bekannter DVR nennt sich TiVo3 .
Schon diese Errungenschaft hat die Fernsehlandschaft verändert, da für den
Benutzer nicht nur Sendungen aufgenommen wurden, welche er selbst ausgewählt hat, sondern es wurde eine auf ihn zugeschnittene Vorauswahl getroffen. Zusätzlich zu diesem essentiellen Vorteil hat der Benutzer dadurch
die Möglichkeit, Werbungen zu überspringen oder sich Sendungen zeitverzögert anzusehen [4]. Durch IPTV geht diese Personalisierung noch weiter sie
werden
„...sehen, was sie wollen, wann immer sie es wollen...“ [12]
Eben diese Meinung wird prinzipiell auch von den Sehern vertreten, wie eine
Testreihe aus [3] ergeben hat.
„Nicht der Fernseher soll bestimmen wann es eine Unterbrechung
gibt, sondern ich will das bestimmen.“ 4
Und genau darauf – nicht nur hinsichtlich der Fernsehunterbrechungen, sondern auch hinsichtlich der gesehenen Inhalte – wird es früher oder später in
der Fernsehlandschaft hinauslaufen, aber dazu später mehr in Kapitel 3.
Zusätzlich zu jenen genannten Entwicklungen wird der Fernseher nicht
nur den Fernsehkanälen oder etwaigen Filmen und Serien vorbehalten sein.
3
4
www.tivo.com
Proband der Tests aus [3]
17
Schon jetzt gibt es einige wenige Möglichkeiten, Webinhalte auf den Fernsehbildschirm zu laden oder Webvideos anzusehen.
2.2
IPTV Anbieter
Ein IPTV Anbieter ist der in Teil 1.2.2 erwähnte Service Provider, welcher
den Endkunden mit TV-Inhalten und verschiedensten interaktiven Diensten versorgt. Der Seher ist sozusagen bei dem gewünschten Service Provider
registriert und bezieht die von ihm angebotenen Dienste. Grundsätzlich variiert die Anzahl und Auswahl der Dienstleistungen per Anbieter, dennoch
gibt es einige Umsetzungen, die von allen oder zumindest den meisten Service
Providern dem Kunden zur Verfügung gestellt werden (aus [3]):
• VoD:
Die Möglichkeit, sich Serien und Filme zu bestellen, um sie sich zu einem selbstgewählten Zeitpunkt anzusehen. Bei den meisten Anbietern
sind die bestellten Filme 24 Stunden verfügbar. Je nach Aktualität
der Filme muss der Kunde diese bezahlen oder nicht. Aber auch diese
Tatsache variiert.
• Electronic Program Guide (EPG):
Als elektronisches Fernsehprogramm, um dem Seher Informationen zB
über eine laufende Sendung zu bieten.
• DVR/PVR:
Die Funktionen des Pausierens, Vor- und Zurückspulens können während des normalen Fernsehbetriebs ausgeführt werden. Sie ermöglichen
es dem Benutzer, diese Funktionen während der laufenden Sendung
auszuführen. Hier wird der lineare Verlauf des aktuellen Programms
beeinflusst. Benutzt der Seher eine dieser Funktionen, zB pausieren,
so wird in diesem Fall die laufende Sendung auf dem Server des Service Providers aufgezeichnet und nach dem Beenden der Pause wird
die Sendung durch Abspielen der aufgenommenen Daten wieder fortgesetzt.
Dies sind die gängisten Dienste, welche von den Anbietern zur Verfügung
gestellt werden. Zusätzlich bieten nur einige wenige Service Provider (zB
Ocilion5 welcher in Teil 2.4 noch genauer beschrieben wird) die Fähigkeit
an, Webinhalte, wie zB das aktuelle Wetter, die neuesten Nachrichten oder
Online-Videos auf dem Fernsehgerät darstellen zu können.
Im Zuge dieser Arbeit wurden die Angebote dreier Direkt-Anbieter (Ocilion verkauft seine Produkte nicht an Endkunden) aus der Schweiz6 , Ös5
6
http://www.ocilion.at
Bluewin TV - http://www.swisscom.ch
18
terreich7 und Deutschland8 herangezogen und deren Leistungen hinsichtlich
der Möglichkeit der Darstellung von Webinhalten verglichen bzw. betrachtet. Dabei ist wiederum aufgefallen, dass weder Bluewin TV, noch Alice
dem Kunden derartige Funktionen und Leistungen zur Verfügung stellen,
die ihm diese Optionen ermöglichen. aonTV hingegen bietet zumindest die
Möglichkeit, sich Informationen bezüglich des derzeitigen Wetters und der
aktuellen Schlagzeilen auf den Fernsehbildschirm zu holen, dennoch werden
diese Inhalte nicht aus dem Internet bezogen. Diese noch nicht sehr ausgereifte Situation auf diesem Sektor wird sich aber in bevorstehender Zukunft
nachhaltig ändern (dazu mehr in Kapitel 3).
Die elementare Technik, welche die meisten Serviceanbieter verwenden,
bleibt – genauso wie die angebotenen Leistungen – meist die gleiche. Dem
Kunden wird eine STB zur Verfügung gestellt, welche meist nur das Dekodieren der Daten, sowie das Rendern des TV-Bildes übernimmt (Ocilion nennt
deren Box „Thin-Client“). Die Programmlogik selbst befindet sich auf einem
Frontend-Server beim Provider. Genaueres zu dieser Art von Server und zur
gesamten Service Provider Technologie wird unter Punkt 2.4.4 am Beispiel
von Ocilion, als auch aonTV´ ausführlicher erläutert.
2.3
IP Set-Top Boxen
Da sich die praktische Arbeit in Teil II mit einem Plug-In für eine „standalone“ IP STB (genauer gesagt, die Dreambox 9 ) beschäftigt, wird hier genauer auf die verschiedenen Arten von STBs eingegangen, deren Unterschiede
erläutert, sowie die verschiedenen Funktionalitäten und die üblichen physikalischen Schnittstellen erklärt.
Grundsätzlich ist eine Set-Top Box ein kleiner Computer, zu dessen
Standard-Hardware zB ein Prozessor gehört. Dieser Computer ist im Allgemeinen dafür zuständig, ein empfangenes, digitales Signal in ein Format
zu konvertieren, welches sich auf dem Fernsehbildschirm darstellen lässt, sei
dieses Endformat nun digital oder analog. Eine IP Set-Top Box verfügt, ergänzend zur obigen Beschreibung, über eine Netzwerkschnittstelle, welche
das digitale Signal via eines Breitbandanschlusses empfängt [14]. [14] teilt
die Funktionen einer IP STB in drei Hauptaufgaben ein:
• Empfang,
• Dekodierung und
• Präsentation von IP Mediendaten zur Darstellung am Fernsehbildschirm.
7
aonTV - http://www.aon.tv
Alice - http://www.alice-dsl.de
9
http://www.dream-multimedia-tv.de
8
2.3.1
19
Arten von IP Set Top Boxen
In diesem Teil der Arbeit wird primär auf die unterschiedlichen Ausführungen von IP Set-Top Boxen eingegangen. Jede Art von STB ist im Wesentlichen dazu da, das empfangene Audio- und/oder Videosignal in ein Format
umzuwandeln, welches das darstellende Endgerät, also das Fernsehgerät verwenden und präsentieren kann [6]. Dieses sogenannte Media Processing ist
die trivialste Funktion einer Set-Top Box. Je nach Aufgabengebiet existieren
verschiedene Ausführungen von IP Set-Top Boxen. [14] teilt sie folgendermaßen ein:
Multicast und Unicast Set-Top Box
Diese Ausführung einer IP STB stellt die Standardausführung dar. Sie ist
dementsprechend in der Lage, zB „live“ Datenströme via Multicast, sowie
VoD via Unicast empfangen und verarbeiten zu können. Abbildung 2.1 zeigt
die einzelnen Hardware Elemente, welche eine solche STB besitzt, um Multicast und Unicast bei der Kanalübermittlung zu unterstützen [14]. Diese
einzelnen Module übernehmen laut [14] folgende Aufgaben:
Prozessor: Dieser ist neben anderen Aufgaben für das Lesen der IPTV
Datenpakete, das Initialisieren der STB Hardwarekomponenten und
das Betreiben des Betriebssystems zuständig.
Random Access Memory (RAM): Dient als temporärer Speicher zur
Grafikverarbeitung und Ausführung interaktiver Applikationen.
Read-Only Memory (ROM): Speichert wichtige Informationen, wie zB
die Netzwerkeinstellungen.
Transport Stream Demultiplexer: Jener übernimmt die Auswahl und
das Entpacken der gewünschten Medienpakete.
Audio und Video Dekoder: Diese Elemente zeichnen sich für die Verarbeitung und Dekodierung von Audio- und Videoinhalten zuständig.
Sicherheitssystem: Hier werden die empfangenen Audio- und Videodaten
entschlüsselt.
Sonstigen Schnittstellen: Jene können beispielsweise eine Infrarotschnittstelle oder etwaige Video- und Audioausgänge (siehe dazu Abschnitt
2.3.3) sein.
IP Set-Top DVR
Hierbei handelt es sich um eine IP STB, welche zusätzlich die Funktionalität
eines digitalen Videorekorders (siehe Abschnitt 2.2) in sich birgt [14]. Durch
20
Abbildung 2.1: Hier werden die einzelnen Module einer Standard IP STB
dargestellt – angelehnt an [14, Fig. 5.9].
eine Festplatte, welche sich im Gerät befindet, können die DVR Funktionalitäten ausgeführt werden. Generell wird zwischen einer eigenständigen
(„Stand-alone“) und einer sogenannten „Multi-Room“-Variante unterschieden.
„Stand-alone“ Set-Top DVR: Hier handelt es sich um eine herkömmliche, eigenständige STB, welche über die Optionen eines digitalen Videorekorders verfügt [14].
„Multi-Room“ Set-Top DVR: Durch eine solche technische Ausführung
ist es möglich, zB aufgenommen Videoinhalte auf unterschiedlichen Fernsehgeräten anzusehen [14]. Technisch unterscheidet sich die zentrale von der
dezentralen Variante. Bei Ersterer wird die Haupt-DVR-STB an das Heim-
21
Abbildung 2.2: Vorderansicht der Dreambox DM800 HD PVR.
netzwerk angeschlossen, diese kümmert sich um das Aufnehmen, Pausieren
und Abspielen der Mediendaten [14]. Alle anderen Set-Top Boxen im Netzwerk erhalten die aufgenommenen Daten von jener Haupt-STB [14]. Die
dezentrale Variante arbeitet ebenfalls mit mehreren Set-Top Boxen, wobei
jede einzelne mit DVR Funktionaltität ausgestattet ist [14].
Hybride Set-Top Box
Bei einer Hybriden STB handelt es sich um ein hybrides Gerät, welches
Live-Videodaten via DVB-T, -C oder -S empfängt und zusätzlich einen Breitbandzugang bietet, um zB VoD oder Webinhalte empfangen zu können [14].
Da hierbei die Live-Fernsehinhalte nicht über den Breitbandzugang geschickt
werden, braucht eine solche STB weniger Bandbreitenkapazität als eine „herkömmliche“ IP STB, welche auch diese Art von Informationen über die Netzwerkschnittstelle empfängt [14]. Um nun Inhalte via DVB empfangen und
darstellen zu können, verfügen hybride Set-Top Boxen zusätzlich über einen
eingebauten Radiofrequenz (RF) Empfänger und einen Demodulator [14].
Bei der auf Seite 25 genauer erläuterten Set-Top Box – der Dreambox (siehe
Abbildung 2.2) – handelt es sich um eine hybride STB, welche Fernsehkanäle via DVB, als auch Medieninhalte via IP empfangen und am Fernsehgerät
anzeigen kann.
2.3.2
22
Funktionalität
Verschiedene Set Top Boxen bieten differierende Funktionalitäten an. Auch
hier gibt es wiederum Standardfunktionen, die wohl die meisten STB offerieren, wie zB das Rendern oder Skalieren des Fernsehbildes passend zum
Fernsehgerät. Die Fähigkeiten jener Set-Top Boxen, welche von einem Provider zur Verfügung gestellt werden, halten sich in Grenzen, da der Großteil
der Arbeit auf den Servern des Service Providers erledigt wird, welcher die
Daten zum passenden Client (in diesem Fall der STB) schickt. Jedoch verfügt
eine Standard STB laut [6] meist über folgenden Fähigkeiten:
Picture in Picture (PiP)
Diese Funktion gibt es schon seit längerer Zeit bei Set-Top Boxen oder Fernsehgeräten. Sie erlaubt es dem Seher, zB zwei Fersehprogramme gleichzeitig
anzusehen. Meist wird eines der beiden Programme in verkleinerter Form
auf dem gesendeten Bild des zweiten Programmes dargestellt.
Smart Card
Das naheliegendste Beispiel einer Smart Card ist jene des ORFs, welche
der Benutzer seit Einführung des digitalen terrestrischen Video-Rundfunks
(DVB-T)10 in seine STB einführen muss, um Zugang zu den österreichischen,
öffentlich-rechtlichen Sendern zu erhalten. Im Grunde genommen speichert
die Smart Card Informationen, welche benutzerabhängig sind. Zusätzlich zu
der physischen Smart Card existieren auch virtuelle Smart Cards, welche als
Software in der Set Top Box integriert sind und dem gleichen Zweck dienen.
Protokolle
Die Fähigkeiten jeder STB sind, wenn es um Kommunikationsprotokolle wie
zB TCP/IP11 geht, sehr hoch. Da eine Set Top Box eine beträchtliche Anzahl
von Mediendaten empfängt und sendet, wurde eine hohe Anzahl von Regeln
verfasst und als Protokolle umgesetzt, welche angeben, in welcher Art und
Weise diese Daten behandelt werden müssen. So ist gerade TCP/IP für das
Senden und Empfangen der Datenpakete aus dem IP Netzwerk zuständig.
Darüber hinaus existieren weitere Protokolle, welche die STB kennen und
verstehen muss (Siehe dazu Abschnitt 1.2.2).
Plug-In
Grundsätzlich ist ein Plug-In eine Software Applikation, welche auf der SetTop Box ausgeführt wird und standardmässig nicht darauf zu finden ist. Im
10
11
Digital Video Broadcasting Terrestrial, siehe http://www.dvb-t.at
Transmission Control Protocol/Internet Protocol
23
Abbildung 2.3: Die Rückansicht der Dreambox DM800 HD PVR zur Darstellung der vorhandenen physischen Schnittstellen.
Falle der Dreambox haben die Benutzer die Möglichkeit, eigene Plug-Ins zu
implementieren und von der Box ausführen zu lassen. Ein Plug-In erweitert
somit den Fähigkeitsumfang einer STB und kann zu einer besseren Personalisierung und größeren Interaktivität hinsichtlich Fernsehvergnügen führen.
Der Benutzer hat durch ein von ihm gewähltes Plug-In die Möglichkeit, die
Funktionalitäten seiner STB hinsichtlich seiner Interessen und Wünsche zu
erweitern. Die praktische Arbeit in Teil II befasst sich mit einem solchen
Plug-In, welches für die Dreambox erstellt wurde. In jenem Teil der Arbeit
werden auch die technische Umsetzung, sowie die anfänglichen Überlegungen
hinsichtlich Personalisierung und Interaktivität näher erläutert.
2.3.3
Physische Schnittstellen
Wie schon bei den Funktionalitäten einer Set Top Box gibt es auch bei
den physischen Schnittstellen, die eine STB bietet, Unterschiede. Hier soll
vor allem auf die schon zuvor erwähnte Dreambox von DreamMultimedia 12
eingegangen und anhand dieser die grundsätzlichen Funktionen der wichtigsten, physischen Interfaces aus Abbildung 2.3 erläutert werden. Die einzelnen
Schnittstellen werden hier nur kurz erklärt (aus [5]), denn wie schon in Abbildung 2.3 sichtbar wird, weist die Dreambox keine gänzlich neuen oder
unbekannten Interfaces auf.
12
http://www.dream-multimedia-tv.de
24
Low-Noise Block Converter (LNB) Ein- & Ausgang
Beim Eingang für LNB13 wird das Koaxialkabel der vorhandenen Satellitenanlage angeschlossen. Die LNB-Schnittstelle ist dafür zuständig, die höhere
Satellitenfrequenz auf die niedrigere Fernsehfrequenz zu transformieren. An
den LNB-Ausgang kann im Fall der Dreambox ein analoger oder digitaler
Satellitenempfänger angeschlossen werden.
Modem Schnittstelle (RJ-25)
Diese Schnittstelle ermöglicht eine direkte Verbindung zum Internet via analoger Telefonleitung, d. h. die STB wird direkt an die Telefonbuchse oder an
das jeweilige Modem angeschlossen. Über diese Schnittstelle können Inhalte
aus dem Internet oder via IPTV empfangen werden.
Serielle Schnittstelle (RS 232/EIA-232)
Der geräteabhängige Nutzen dieser Schnittstelle liegt beim Updaten der Betriebssoftware und/oder der Vorprogrammierung mittels PC.
Netzwerk Schnittstelle (Ethernet 10/100Mbit/RJ-45)
Hier ist es möglich, das Netzwerkkabel anzuschließen, um einerseits mittels
Hypertext Transfer Protokoll (http), File Transfer Protokoll (ftp), Network
File System (nfs), Telecommunication Network (Telnet) oder Samba14 mit
der Box zu kommunizieren, andererseits kann dadurch in einem Netzwerk
die indirekte Verbindung mit dem Internet und/oder mit einem vorhandenen
Service Provider hergestellt werden.
TV Anschlüsse
Natürlich bietet die Dreambox, wie die meisten anderen Set Top Boxen, unterschiedliche Schnittstellen zum Anschluss an das Fernsehgerät. Hier sind es
Digital Visual Interface (DVI) zur digitalen Signal- und falls möglich High
Definition (HD)-Übertragung, bei welchem am TV-Gerät ein HDMI Anschluss benötigt wird. Zusätzlich gibt es die Möglichkeit, per SCART das
Fernsehgerät anzuschließen und so das Video- und Audiosignal analog zu
übertragen.
Digitaler Audio Ausgang
Weiters verfügt die Dreambox über einen digitalen Audio Ausgang (Toslink15 ).
13
Rauscharmer Signalumsetzer
http://www.samba.org
15
„Fiber Optic Device“ von Toshiba http://www.toshiba.com
14
25
Weitere Schnittstellen
Wie schon zuvor erwähnt, sind dies nur jene Interfaces, welche auf der Dreambox vorhanden sind. Andere STBs unterstützen auch drahtlose Verbindungen, wie zB Wireless Local Area Network (WLAN) oder Ultra Wide Band
(UWB)16 zum Übertragen von Audio- und Videosignalen [6].
2.4
IPTV Systeme
Ein potentieller IPTV Benutzer steht schon heute einer Menge von Angeboten gegenüber. Größtenteils beherrschen den IPTV Markt Serviceanbieter
(siehe Punkt 2.2), dennoch gibt es für den Kunden andere Optionen für
IP Fernsehen. Dieser Abschnitt beschäftigt sich mit drei unterschiedlichen
IPTV Systemen, welche sich vor allem in der Art der Kanalübermittlung
unterscheiden und somit verschiedenste Vor- und Nachteile aufweisen. Als
Repräsentant der Multicast Technik wurde aonTV 17 ausgewählt, Unicast
kommt bei dem IPTV Anbieter Ocilion 18 zum Einsatz und via Broadcast
werden die Kanäle bei der hybriden STB – der Dreambox DM 800 HD PVR
– empfangen.
2.4.1
Dreambox DM 800 HD PVR als Broadcast System
In Abschnitt 2.3 wurde die Dreambox (kurz DM800 ) schon als Beispiel herangezogen und deren Funktionen und Schnittstellen kurz erläutert. Bei dieser
STB handelt es sich – laut deren Hersteller – um einen
„Digitalen Satellitenempfänger zum Empfang von freien und verschlüsselten DVB-Programmen mit optionaler digitaler Aufzeichnungsmöglichkeit.“ [5]
Die DM800 ist eine Set Top Box, welche neben DVB auch die Möglichkeit
hat Daten per IP zu empfangen und darzustellen. Es handelt sich hier um
eine intelligente, hybride STB, zu deren Standardhardware ein 300 Megahertz (MHz) Prozessor gezählt wird, auf welchem Linux als Betriebssystem
läuft19 . Hinsichtlich der Kanalübermittlung werden, aufgrund der hybriden
Technik, mittels DVB die einzelnen Videodaten empfangen, d. h. es kommt
Broadcast zum Einsatz. Die Kanalübermittlung mittels Broadcast wurde bereits in Abschnitt 1.2.2 erläutert.
Einen der wichtigsten Teile der Dreambox stellt die graphische Benutzeroberfläche (GUI - Graphical User Interface) dar. Diese nennt sich für die
16
Ultrabreitband
http://www.aon.tv/
18
http://www.ocilion.at
19
aus http://dream.reichholf.net/wiki
17
26
DM800 Enigma2 und basiert auf der Programmiersprache Python 20 , welche
die Progammierschnittstelle21 LinuxTV DVB 22 verwendet23 . Enigma2 ist
die zweite Version einer solchen „Framebuffer“-basierten Zapping Applikation und wird seit der DM7025 eingesetzt23 . Grundsätzlich wurde Enigma2
für die verschiedenen Dreambox Versionen entwickelt, doch die Tatsache,
dass sie ebenfalls mit der freien Multimedia-Bibliothek Simple DirectMedia Layer (SDL)24 arbeiten kann, ermöglicht es, diese GUI auch auf einem
Personal Computer (PC) anzuwenden23 . Das wiederum bietet jenen Vorteil, dass Benutzer nicht an die Dreambox als Hardware gebunden sind und
somit jeglichen, technisch passenden Computer verwenden können, um die
Funktionalitäten von Enigma2 zu nutzen, d. h. um sich eine „eigene STB“
zu schaffen.
Die Programmiersprache, in welcher Enigma2 verfasst ist, ist zum größten Teil Python. Zusätzlich verfügt diese grafische Applikation über ein in
C++ 25 verfasstes Backend 23 . Dies ist ein Relikt der ersten Enigma-Version,
welche vollständig in C++ verfasst war23 . Enigma2 stellt nun eine sehr flexible Open-Source GUI Applikation dar, welche von jeglichem Programmentwickler erweiterbar ist (sofern die Veränderungen der Lizenz entsprechen
und von den Herstellern akzeptiert wurden)23 . Zusätzlich zu der erweiterbaren Grundapplikation gibt es die Möglichkeit, Plug-Ins zu entwickeln. Diese
unterliegen keiner bestimmten Lizenz und können vom Entwickler frei gestaltet werden. Die Option, Plug-Ins zu gestalten, birgt einen enormen Vorteil
hinsichtlich Personalisierung, denn hier kann sich der Benutzer unbegrenzt
einbringen, ferner ergibt sich daraus eine Vielfalt von erstellten Zusatzapplikationen, welche bei Bedarf installiert werden können. Der offensichtliche
Nachteil dabei ist, dass diese Option der eigenständigen Plug-In Entwicklung nur den technisch versierten Benutzern vorenthalten ist und bis jetzt
leider keine Funktion angeboten wird, welche es Laien ermöglicht, Plug-Ins
zu entwickeln.
Neben der Steuerung der Box via Fernbedienung gibt es die Option,
verschiedenste Funktionalitäten mit Hilfe einer Webschnittstelle (WebIf )
zu steuern und abzufragen. Dieses WebIf kann via Browser bei Eingabe
der IP-Adresse der Dreambox oder per http:// dreambox erreicht werden23 .
Darüber hinaus erlaubt eine Programmierschnittstelle (API) durch httpAbfragen Informationen bezüglich der aktuellen Einstellungen (zB TimerEinstellungen) oder Auswahl (zB EPG) der Dreambox als Extensible Markup Language (xml)-Datei zu erhalten. Diese API basiert auf einem Client/Server-Konzept, welches zusätzlich zum http-Client den Informationszu20
http://www.python.org
API - Application Programming Interface
22
http://www.linuxtv.org
23
24
http://www.libsdl.org
25
http://www.cplusplus.com
21
27
griff via html, JavaScript26 , C++ oder Java27 ermöglicht28 . Somit erhält
der Entwickler die unkomplizierte Möglichkeit, Informationen – welche die
STB betreffen – abfragen zu können, um diese zB in einem möglichen Plug-In
zu verwenden.
Neben der Webschnittstelle verfügt die Dreambox darüber hinaus über
eine Wireless Application Protocol (WAP) Schnittstelle, die den Zugriff auf
die oben beschriebenen Inhalte mit Hilfe eines Mobiltelefons ermöglicht28 .
2.4.2
Ocilion als Unicast System
Bei Ocilion IPTV Technologies GmbH, kurz Ocilion, handelt es sich um ein
Unternehmen, das Live-Fernsehen, interaktive Dienste und zusätzliche Services (EPG, PVR, ...) für Service Anbieter vertreibt, welche diese Dienste
den Endbenutzern zur Verfügung stellen. Die Kunden dieses IPTV Unternehmens sind vornehmlich Kabel-TV Anbieter, Internet Service Anbieter oder
Anbieter von Telekommunikations Lösungen im Gast- und Pflegebereich (zB
Hotels oder Krankenhäuser) [13].
Ocilion repräsentiert jene Art von System, welches per Unicast die Daten
dem Client übermittelt. In Abschnitt 1.2.2 wurde die Funktionsweise von
Unicast bereits erläutert und illustriert. Das Besondere an dieser Systemart
ist, dass nicht wie bei Multi- und Broadcast pro Kanal sondern pro Client
enkodiert wird, da jedem Kunden ein Datenstrom übermittelt wird, d. h. je
mehr Systembenutzer, umso mehr Enkoder müssen zur Verfügung gestellt
werden, was zu etwaigen Engpässen hinsichtlich der technischen Ressourcen,
sowie der Bandbreite führen kann.
Um flexibel ihren Abnehmern gegenüber zu sein, stellt Ocilion zwei unterschiedliche Lösungen bereit, wobei eine Lösung auf eine hohe Anzahl von
Endbenutzern ausgerichtet ist und deshalb eher auf Kabel-TV und Internet
Service Anbieter abzielt [13]. Die zweite Option richtet sich vor allem an Telekommunikationsanbieter im Gast- und Pflegebereich, bei denen die Anzahl
der Endbenutzer deutlich unter jener der Kabel-TV und Internet Service
Anbietern liegt [13].
Jede dieser angebotenen technischen Lösungen basiert jedoch auf dem
in Abbildung 2.4 dargestellten System Design, das sich aus verschiedenen
Modulen zusammensetzt und in [13] folgendermaßen erklärt werden.
Die Videodaten dieses Systems werden im Video Input Teil einerseits per
DVB-S empfangen und an das TvDVB Modul weitergeleitet. Externe RTP
Daten werden an das TvRTP Modul gesendet. Weiters existiert ein System
Management, dessen Aufgabe es ist, alle Systemaktivitäten zu verwalten und
zu kontrollieren. Nur hier ist das System via Virtual Private Network (VPN)
mit der Ocilion Hauptzentrale verbunden, um zB einfach Fehler beheben zu
26
http://de.selfhtml.org/javascript/
http://java.sun.com
28
27
28
Abbildung 2.4: System Desgin des Ocilion IPTV Systems, adaptiert aus
[13, Figure 2-1].
können. Den dritten inneren Teil stellen Externe Daten Schnittstellen dar,
welche es ermöglichen, zusätzliche Inhaltsquellen in das IPTV System einzuspeisen (wie zB Webinhalte oder Spiele). Das Management Netzwerk ist
sozusagen das Verwaltungsnetzwerk, alle Module, sowie auch das System
Managment stehen in Verbindung mit ihm. Ein weiterer Punkt ist, dass an
der Stelle zwischen Management Netzwerk und den Modulen sich die Kanalübermittlung von reinem Unicast auf Unicast und Multicast ändert. Die
Funktionalität der Module wird in den Unterabschnitten von 2.4.2 genauer
erläutert. Jedes einzelne Modul steht mittels Datentransfer in Verbindung
mit den beiden „Backbone-Switches“. Die Module TvFrontend und TFTP/DHCP liegen wiederum, in Hinsicht auf die Kanalübermittlung, im reinen
Unicast-Bereich. Weiters haben nur diese beiden Module eine direkte Ver-
29
bindung zum Verteilungsnetzwerk, auf welches auch der Benutzer mit dem
Teilnehmer-Endgerät (CPE) Zugriff hat. Die einzelnen Module lassen sich
wiederum laut Ocilion [13] in vier Gruppen unterteilen.
Empfangsgruppe
Die Aufgaben der Module dieser Gruppe befassen sich mit dem Empfangen
verschiedenster Inhalte. Ihre Funktionen lauten folgendermaßen:
TvDVB: Dieses Modul kümmert sich um den Import von Daten der Fernsehkanäle, sowie um die Einspeisung dieser Daten in das Backbone-System.
Diese Daten werden zuvor wiederum von einem DVB-S Empfänger entgegengenommen und an das TvDVB Modul weitergegeben.
TvRTP:
Das TvRTP Modul ist für Inhalte im RTP Format zuständig.
TvTranscode: Zum Transkodieren oder neu Enkodieren eines Signals zeichnet sich dieses Modul verantwortlich. Einsatz findet es zB, falls ein Netzwerk eine limitiertere Bandbreite besitzt und ein Signal erneut enkodiert
werden muss.
Systemgruppe
Diese Module kümmern sich um verschiedenste Systemaufgaben, wie zB dem
Speichern und Archivieren von Logdateien.
TvTime: Jenes Modul stellt den restlichen Modulen die koordinierte Weltzeit (UTC) zur Verfügung.
TvConf: Wird zur Verwaltung der zentralen Konfigurationsinformationen
des Systems eingesetzt.
TvLog:
Dieses Modul sammelt alle Logdateien des Systems.
TvStat Wird zur Erfassung jeglicher Status Informationen der gesamten
Module des IPTV Systems eingesetzt und stellt diese Informationen für externe Applikationen bereit.
TvDB: Dieser Teil des Systems ist ein integriertes Datenbank-Modul für
Endnutzer, sowie für direkte Ocilion Kunden, zur Speicherung interner Daten zB Kundendaten.
TvFile: Das Systemmodul TvFile versorgt das TvFrontend Modul mit den
gewünschten Dateien.
30
TvXML: Bestehend aus dem TvXmlSystem Modul, welches eine xnl Aggregationsschicht zwischen internen und externen Services darstellt und dem
TvXMLPassThrough Modul, welches eine xml-basierte Schnittstelle zur Weiterleitung von STB Input an externe Applikationen und zur Darstellung von
Anweisungen jener externen Applikation, darstellt.
TvHTML: Jenes Modul stellt einen µhtml für Standard html-Formate
bereit. Somit können Webinhalte oder html Seiten dargestellt werden.
TvRFB: In Verbindung mit dem TvRfbDispatcher Modul wird dieses Systemmodul verwendet. Gemeinsam ermöglichen sie es, jegliche Applikationen, welche in einer X.11 Linux29 Umgebung laufen, auf der STB des Benutzers darstellen zu können.
Verarbeitungsgruppe
Die dritte der Modulgruppen befasst sich vor allem mit dem Verarbeiten
von darstellbaren Inhalten. In dieser Gruppe befinden sich auch jene Module, welche sich um die zusätzlichen System-Services wie EPG oder VoD
kümmern.
TvTeletext: Dieses Modul zeichnet sich sowohl für den Empfang, als auch
die Verarbeitung aller Teletext-Daten von jedweder TV Station verantwortlich und speichert diese ab, damit die Daten ohne Verzögerung an den Endbenutzer geschickt werden können.
TvEPG: Dieses Verarbeitungsmodul ist für das Extrahieren von EPG Informationen aus dem Video-Datenstrom bzw. das Empfangen von EPG Informationen aus externen Quellen, sowie das Abspeichern dieser Daten auf
einem zentralen EPG Server zuständig.
TvStore: Das TvStore Modul ermöglicht dem Benutzer ein zeitversetztes
Fernsehen. Verwenden Endbenutzer diese Systemeigenschaft, so wird der aktuelle Datenstrom des Fernsehkanals unmittelbar auf einer Modul-internenen
Festplatte aufgezeichnet. Weiters übernimmt dieses Modul auch die Aufgabe,
Zugang, auf die vom Benutzer via VoD gewählten Filme, welche gesamtheitlich auf einer zentralen Festplatte gespeichert werden, zu erhalten. Die dritte
Aufgabe besteht aus der Funktion des persönlichen Videorekorders (Erklärung siehe Abschnitt 2.2).
29
http://www.kefk.net/Linux/X11/index.asp
31
TvDir: Es arbeitet in enger Verbindung mit dem oben erwähnten TvStore
Modul, da es alle inhaltlichen Abfragen auf das TvStore Modul kontrolliert
und visualisiert.
Präsentationsgruppe
Auf jene Module dieser Gruppe kann der Endbenutzer zugreifen. Sie sind es
auch, welche die gewünschten Inhalte zur Darstellung an die Set-Top Box
schicken.
TvFrontend: Dies ist das Verbindungsmodul zwischen dem Verteilungsnetzwerk und den „Backend“-Services des IPTV Systems. Mit dem Verteilungsnetzwerk ist wiederum zB das Modem des Benutzers verbunden, mit
welchem die Set-Top Box zusammenhängt. D. h. das TvFrontend Modul ist
das einzige Modul, zu welchem der Benutzer fast direkt verbunden ist. Jegliche anderen Module sind durch zwei „Backbone“-Switches abgeschirmt.
TFTP/DHCP: Oder auch Trivial File Transfer Protocol und Dynamic
Host Configuration Protocol. Dieses Modul ist für das Neustarten der STB
zuständig. Eine weitere Verantwortung liegt beim Senden von anbieterspezifischer (d. h. spezifisch hinsichtlich des direkten Ocilion Kunden) Software
für die Set-Top Boxen.
2.4.3
aonTV als Multicast System
aonTV ist das IPTV System der Telekom Austria 30 und kann vom Benutzer
über das Telefonleitungssystem empfangen werden. Laut Telekom Austria
muss am Benutzerstandort ein Wählamt vorhanden sein, welches ADSL2 31
tauglich ist. Sind alle Voraussetzungen erfüllt, kann der Benutzer sich mit
einer simplen STB, welche ihm zur Verfügung gestellt wird, per SCART
oder HDMI zum Fernsehgerät verbinden. Die Verbindung zum Empfang der
Daten kann sowohl kabelgebunden, als auch drahtlos per WLAN erfolgen32 .
Der Benutzer hat nun die Möglichkeit, HD-, sowie auch SD33 -Daten zu
empfangen. Jene werden je nach Auflösung im H.264 (bei HD-Auflösung)
oder MPEG2 (bei SD-Auflösung) Format übertragen (laut 32 ).
Aus [11] geht hervor, dass es bei diesem System keine Möglichkeit des
zeitversetzten Fernsehens gibt. Weiters besteht die ausschließliche Personalisierungsoption für den Kunden darin, sich einen Film aus der sogenannten
aonTV Videothek auszuwählen [11]. Zusätzlich kann nur noch die Reihung
30
http://www.telekom.at/
http://www.itwissen.info/definition/lexikon/ADSL2-plus-ADSL2-plus.html
32
aus http://www.aontv.org/wiki/Hauptseite
33
Standard Definition
31
32
der Sender verändert werden, um sie an die Bedürfnisse des Kunden anzupassen [11].
Wie nun schon zuvor erwähnt, erfolgt die Kanalübermittlung der Fernsehkanäle per Multicast [9]. VoD wird jedoch per Unicast übermittelt [9]. Im
Gegensatz zu Ocilion wird die Übermittlungstechnik aufgrund der zu übertragenden Inhalte ausgewählt. In Abschnitt 1.2.2 wurden die Vorgehensweise
und die Vorteile dieser Variante der Kanalübermittlung bereits erklärt. Prinzipiell werden nur jene Daten enkodiert und an den Seher geschickt, welche er
verlangt. Die Daten werden danach gruppenspezifisch übermittelt, wobei eine
Gruppe von einem Fernsehkanal repräsentiert wird, d. h. nur jene Benutzer,
welche zB den ersten Kanal des österreichischen Rundfunks (ORF1) sehen,
empfangen die adäquaten Daten. Server-seitig wird pro Kanal enkodiert und
übermittelt. Die Verteilung an die Clients wird von den Multicast-Routern
übernommen. Aufgrund dieser Tatsachen bietet Multicast, laut [9], einen ernormen Vorteil gegenüber Unicast zur Übertragung von Live-Fernsehen.
2.4.4
Vergleich der Systeme
Dieser Abschnitt zieht einen Vergleich dieser drei Arten der Systeme. In manchen Punkten können die speziellen Eigenschaften der Systeme, die jeweils
Unicasting, Multicasting und Broadcasting repräsentieren, nicht außer Acht
gelassen werden.
System Design
Hier wird konkret auf das produktspezifische System Design eingegangen.
Broadcast System: Alle nötigen Funktionen, Hard- und Software sind
auf der STB vorhanden, da es sich um eine intelligente Set-Top Box handelt.
Somit hat der Benutzer alles vor Ort, ist selbst für die Wartung des Systems
(zB für seine gespeicherten Videoinhalte) zuständig und kann eigenständig
bestimmen, wann er etwas von seinen Daten manipulieren möchte. Dies hat
zum Vorteil, dass der Benutzer jegliche Inhalte auf seiner eigenen Set-Top
Box speichert und selber für deren Verwaltung zuständig ist. Gleichzeitig
ergibt sich daraus auch ein Nachteil für jene Anwender, die technisch nicht
versiert sind.
Unicast System: Das IPTV-System ist hier zentral gestaltet und gesteuert. Alle Funktionen, Daten und Einstellungen werden auf systeminternen
Servern gespeichert. Dem Kunden steht somit eine beschränkte Anzahl von
zB Gigabyte (GB) zum Abspeichern von Fernsehinhalten oder VoD-Filmen
zur Verfügung, welche zusätzlich nach Ablauf einer bestimmten Zeit nicht
mehr verfügbar sind. Der Endbenutzer besitzt lediglich eine STB (Ocilion
nennt jene „Thin-Client“) mit wenigen Funktionen. Sowohl die Wartung des
33
Systems, als auch die Verwaltung seiner Daten werden vom Anbieter übernommen.
Multicast System: Dieses IPTV System wird, ebenfalls wie das Unicast
System, zentral gesteuert und verwaltet. Der Benutzer ist wiederum in Hinsicht auf seine Daten und auf die Anzahl der empfangenen Kanäle vom Anbieter abhängig. Lediglich die VoD-Funktion ist vom System abgekoppelt.
Um Filme per Unicast effizienter übermitteln zu können, existieren mehrere Content-Server, welche in ganz Österreich verteilt sind. Der Kunde erhält Zugriff auf jenen Server, welcher ihm, hinsichtlich seines Standortes, am
nächsten ist [9]. Dies verteilt die Zugriffe und entlastet die Zentrale [9].
Kanalübermittlung
Broadcast System: Erfolgt bei diesem Beispiel eines solchen Systems je
nach angeschlossener Technologie. Falls die Live-Fernsekanalübermittlung
mittels DVB geschieht, wird Broadcast verwendet und unterscheidet sich
nicht von „nicht-IPTV-Systemen“ (wie zB DVB-S, DVB-T oder DVB-C).
Falls Live-TV-Inhalte via IP übertragen werden, so hängt die genutzte Kanalübermittlungstechnologie vom Sender der Inhalte ab. Die Box kann sowohl per Multicast, als auch per Unicast übertragene Inhalte empfangen.
Unicast System: Die genutze Technolgie zur Datenübertragung ist Unicast. Der Vorteil hier liegt darin, dass die technische Umsetzung relativ simpel ist und die Profilanforderungen an die STB nicht hoch sind. Da dieses
IPTV-System gänzlich zentral gesteuert wird, können durch die Verwendung
der Unicast Technologie Benutzer-spezielle Informationen und Daten übertragen werden, zB eine personalisierte Benutzeroberfläche. Da Ocilion neben
anderen Services auch VoD anbietet und jener Service vollständig in das System integriert ist, ist eine Übertragung per Multicast ohnehin nicht möglich,
außer der VoD-Service würde vom Gesamtsystem abkoppelt und die Daten
würden separat gesendet werden.
Multicast System: Hier werden die Fernsehkanäle per Multicast zu den
einzelnen Benutzern übertragen. Der Vorteil dieser Technik liegt hier bei der
geringeren Bandbreite zur Übertragung (im Gegensatz zu Unicast), sowohl
für HD-, als auch für SD-Übertragungen. Einen weiteren Vorteil hat diese Übertragung auch hinsichtlich Broadcasting, da der Empfänger lediglich
den von ihm gewünschten Inhalt erhält, anstatt des gesamten Umfanges an
Videodaten der einzelnen Fernsehkanäle.
34
Personalisierung
Dieser Abschnitt bezieht sich vor allem auf die systemspezifischen Optionen der Personalisierung. Auf den Umgang hinsichtlich Personalisierung bei
anderen IPTV-Systemen wird in dieser Arbeit nicht eingegangen.
Broadcast System: Wie schon unter „System Design“ erklärt, ist die Dreambox eine „Stand-alone“ STB und vereint jegliche Funktionalität, Hardund Software in ihrem Inneren. Diese Tatsache lässt es für den Benutzer
zu, auf jegliche Daten zugreifen und diese erweitern zu können, vor allem in
Hinsicht auf Plug-Ins. Der Besitzer des Gerätes kann somit die gewünschten Plug-Ins, welche ständig von Entwicklern erstellt werden, selbstständig
auf seine Box spielen und diese nach seinen Wünschen und Interessen erweitern. Durch den denkbaren Internetzugriff wird die Vielfalt und Auswahl
an möglichen Plug-Ins und übertragenen Inhalten erweitert. Ist der Besitzer technisch interessiert, so kann ein Plug-In selbst verfasst werden. Die
Personalisierungsmöglichkeiten sind hier enorm. Einen Nachteil bringt dies
jedoch mit sich, denn das Verfassen eines Plug-Ins bedarf eines größeren,
technischen Verständnisses und kann von Laien nicht problemlos umgesetzt
werden. Dennoch gibt es schon eine große Anzahl an bereits gefertigten Applikationen, die mühelos auf die Dreambox gespielt werden können.
Unicast System: Dieses IPTV-System bietet ebenfalls eine mögliche Personalisierung, jedoch ist diese Option nur den direkten Kunden Ocilions
vorbehalten. Jene können in der eigens entwickelten Skript-Sprache eine Datei verfassen, welche dann über die Externe Datenschnittstelle (siehe Abbildung 2.4 Seite 28) in das System eingespeist wird. Durch jene Skripte
kann die grafische Benutzeroberfläche des Endbenutzers verändert werden.
D. h. die Optionen der Personalisierung sind hier für den Seher nicht so
groß wie bei der zuvor beschriebenen Dreambox, jedoch gibt es dennoch eine gewisse Chancen auf familiäre Gestaltung seines Fernseherlebnisses. Dem
Direktkunden des Systems stehen hingegen durch die Option auf Verfassen eigener Skripte mehrere Personalisierungsmöglichkeiten zur Verfügung.
Aufgrund der Kanalübermittlung via Unicast wäre es allerdings auch kein
Problem, auf spezifische Endkundenwünsche einzugehen, da für jeden Client
ohnehin ein separater Übertragungskanal existiert.
Multicast System: Dieses System bietet keine Personalisierungsmöglichkeiten in Hinsicht auf Plug-Ins. Dennoch stellt es die Option auf zB Spiele
oder Online-Shopping34 zur Verfügung. Zusätzlich können Filme per VoD
für 24 Stunden verfügbar gemacht werden [9].
34
laut http://unternehmen.telekom.at/Content.Node/media/news/0530-aontv.php
35
Datensicherung
Broadcast System: Bei dieser IPTV-Variante ist wiederum der Benutzer
für etwaige Sicherungen verantwortlich. Da jedoch ein vollständiger Zugriff
via PC (falls die Dreambox an das eigene LAN angeschlossen ist, kann zB via
Telnet darauf zugegriffen werden, ansonsten steht dem Benutzer die Webschnittstelle – siehe Abschnitt 2.4.1 – zur Verfügung) auf alle Daten der STB
möglich ist, kann somit eine Sicherung einfach durchgeführt werden.
Unicast System: Hier werden jegliche Daten redundant (mindestens zweimal) abgespeichert, damit keine Fehler bei zB Modulausfällen auftreten. Dieser Vorgang sichert auch die Daten der Endkunden. Der Vorteil hierbei ist,
dass sich der Endbenutzer nicht um die Datensicherung kümmern muss.
Multicast System: Dieses IPTV-System stellt dem Kunden ohnehin keinen Speicherplatz zur Verfügung, somit kümmert es sich lediglich um die
Sicherung der internen Daten, auf die der Benutzer, zB per VoD-Funktion,
Zugriff erhält.
Sicherheit
Broadcast System: Für den STB-Zugriff ist ein Passwort nötig, das vom
zugriffsberechtigten Benutzer geändert werden kann, bzw. beim ersten Gebrauch der Box geändert werden sollte, vornehmlich falls die STB an das
Internet angeschlossen wird35 . Diese Vorgehensweise trifft auf die erwähnte
Dreambox zu.
Unicast System: Aufgrund des System Designs, bei welchem der Client
nicht authorisiert ist, direkt auf das IPTV-System zuzugreifen, dies erfolgt indirekt über das TvFrontend Modul, kann ein externer Zugriff auf das System
ausgeschlossen werden. Die Daten und Informationen des Systemanwenders
werden zentral auf einer Datenbank gespeichert, auf welche – wie oben schon
erwähnt – extern nicht zugegriffen werden kann.
Multicast System: Um auf dieses System Zugriff zu erhalten ist nicht nur
die adäquate Technik obligat, sondern auch eine persönliche Identifikationsnummer (PIN). Diese PIN kann laut [9] mit der einer Kreditkarte verglichen
werden, nennt sich One Time PIN und wird dem Kunden exklusiv zugesendet. Bei Erstinstallation muss die Nummer eingegeben werden, damit das
System für den Benutzer freigeschaltet wird. Weiters wird jeder Kunde über
diese PIN identifiziert und verwaltet (zB um Zugriff auf das VoD System zu
erhalten).
35
36
Inhalte
Broadcast System: Diese STB kann verschiedenste Arten von Inhalten
darstellen. Neben dem herkömmlichen Fernsehinhalt, welcher meist via DVBS empfangen wird, gibt es die Möglichkeit, über die Netzwerk- oder Modemschnittstelle (siehe Abschnitt 2.3.3) zB Webinhalte zu erhalten und darzustellen. Zusätzlich existiert die Option, ebenso Echtzeitdaten (wie zB das
aktuelle Wetter oder die neuesten Nachrichten) zu empfangen und darzustellen, welche von einem Server an die STB gesendet werden. Die einzige
Schwachstelle hierfür ist, dass vorher ein passendes Plug-In entwickelt werden muss, welches die gesendeten Daten richtig interpretiert und darstellt.
Ein solches Plug-In zum Empfang von Echtzeitdaten via IP wurde für diese
Arbeit entwickelt und wird in Teil II näher erklärt.
Unicast System: Jene IPTV-Systeme von Ocilion bieten ebenfalls die
Möglichkeit, externe Dateninhalte darstellen zu können (siehe bei Abbildung
2.4 die Externe Daten Schnittstellen). Im System gibt es passende Module,
welche neben dem html- und xml-Format auch noch Anwendungen darstellen und interpretieren, die in einer X.11 Linux Umgebung laufen (siehe dazu Abschnitt 2.4.2). D. h. auch dieses System kann zB Echtzeitdaten wie
Wetter und Nachrichten empfangen, sie müssen jedoch eines dieser Formate
besitzen, um vom System erkannt, interpretiert und dargestellt werden zu
können. Zusätzlich bietet Ocilion einen Webbrowser namens Ocifox, welcher
auf Mozilla Firefox 36 basiert und speziell für diese Laufzeitumgebung adaptiert wurde [13]. Der Benutzer kann dadurch mit Hilfe des Fernsehgeräts
und der Fernbedienung im Internet „surfen“ [13]. Wie in anderen Systemen
damit umgegangen wird, hängt sowohl vom System Design, als auch von den
Vorstellungen und Zielen des Anbieters ab.
Multicast System: Beim Repräsentanten der Multicast Übermittlungstechnik, aonTV, lassen sich neben Fernsehinhalten auch die neuesten Nachrichten und das aktuelle Wetter darstellen. Diese Daten werden von Content
Providern ausschließlich für aonTV zur Verfügung gestellt, von der Telekom
Austria für die Darstellung aufbereitet und dem Kunden zur Verfügung gestellt [11]. Die Option Webinhalte darstellen zu können, wird derzeit noch
nicht angeboten laut [11].
2.4.5
Trend
Grundsätzlich kann kein allgemeiner Trend erkannt werden, da jedes dieser
Systeme, sowie deren Repräsentanten, verschiedene Zielgruppen haben.
Hinsichtlich des System Designs könnte ein solches Unicast System, welches Ocilion verwendet, eher für Abnehmer aus Gast- und Pflegebetrieben
36
http://www.mozilla-europe.org/de/firefox
37
verwendet werden, da hier die Anzahl der Endbenutzer überschaubar ist und
es nicht zu Engpässen hinsichtlich Ressourcen sowie Bandbreite kommen
kann. Der direkte Kunde kann die maximale Anzahl der Benutzer genauer
bestimmen.
Für die breite Masse wäre diese Lösung eher nicht passend, hier würde
sich ein Multicast System – so wie es aonTV repräsentiert – oder ein Broadcast System – wie bei der Dreambox – besser eignen. Wobei beide Varianten
wiederum unterschiedliche Zielgruppen haben. So wäre eine intelligente, hybride STB, wie es die Dreambox ist, eher für Benutzer, welche sich nicht nur
für das Fernsehen selbst, sondern auch für die Technik, die dahintersteckt
und die Möglichkeiten, die eine solche STB bietet, interessieren. Ein System
wie aonTV ist eher für Benutzer geeignet, welche zwar neben den Fernsehkanälen auch die Option auf etwas Personalisierung und Abwechslung haben
möchten, sich aber nicht eingehender mit der Technik beschäftigen bzw. Änderungen und Anpassungen vornehmen wollen.
2.5
Andere Technologien
Neben den oben genannten Optionen zum Empfang von IPTV gibt es natürlich auch noch andere Geräte oder Möglichkeiten.
2.5.1
Multimedia Computer
Die meisten Heim-PCs können als Multimedia Computer bezeichnet werden,
denn es handelt sich hierbei um PCs, welche eine Netzwerkschnittstelle besitzen und zu deren Software-Anwendungen ein Media Player, wie zB jener
von Microsoft 37 zählt [6]. Zusätzlich ist zum Empfang von Fernsehen mittels IP eine Verbindung zu einem IPTV-Serviceanbieter oder einem IPTVMedienserver obligat [6].
2.5.2
Multimediale Mobiltelefone
Diese Art von Mobiltelefon hat die Fähigkeit, Videosignale zu empfangen und
darzustellen [6]. Jene multimedialen Inhalte können natürlich auch via Internet empfangen werden, somit haben diese Telefone die Möglichkeit, IPTV
zu empfangen und darzustellen [6]. Dennoch gibt es bei diesem Empfangsgerät aufgrund der eingeschränkten Bandbreite und den höheren Kosten beim
Datenempfang über das Internet einige Abweichungen zu Standard IPTVSystemen [6]. Es werden vor allem effizientere Kompressionsmethoden sowie
Protokolle verwendet [6].
37
http://www.microsoft.com/windows/windowsmedia/player/11/default.aspx
2.5.3
38
IP Fernsehgeräte
Jene Fernsehgeräte brauchen keine STB, um IPTV empfangen zu können,
denn alle Funktionalitäten, Hard- und Software, die zum Empfang erforderlich sind, sind im Gerät integriert [6]. Die Entwicklung in diesem Sektor von
IPTV Empfangsgeräten38 wird zur Zeit durch aktuelle Entwicklungen enorm
vorangetrieben und revolutioniert (siehe Kapitel 3).
Kapitel 3
Zukunft des IPTV
3.1
Die nahe Zukunft von IPTV
Die nahe Zukunft des IPTV lässt sich jetzt schon fast als Gegenwart bezeichnen, da vor allem die Entwicklung auf dem Sektor der Fernsehgeräte
mit Internetzugang (d. h. IP Fernsehgeräte siehe Seite 38) in diesem Jahr
(2009) konsequent voranschreitet.
Zur Zeit steigt am Markt die Anzahl der TV-Geräte mit Internetanschluss stetig an. Frühere Ansätze, Webinhalte auf den Fernsehbildschirm zu
bringen, schlugen meist aufgrund der zu geringen Bandbreite, der umständlichen Bedienung oder der qualitativ minderwertigen Darstellung von Bild und
Text fehl [1]. Die neuen Geräte achten aber darauf, solche Inhalte optimal für
den Benutzer zu integrieren. So werden meist Web-Seiten nicht exakt wie sie
im Internet-Browser auf dem Heimcomputer erscheinen für das TV-Gerät
übernommen. Die meisten Hersteller dieser neuen Generation von Fernsehern achten auf die Darstellung und adaptieren diese Inhalte in einer Weise,
die es erlaubt, zB ohne lange textuelle url-Eingabe die gewünschte Webseite
zu betrachten1 . Weiters werden alle darzustellenden Inhalte auch hinsichtlich
ihrer Steuerung verändert, damit der Kunde bequem mit seiner Fernbedienung interagieren kann1 . Aufgrund dieser Entwicklungen finden sich schon
die ersten positiven Kritiken hinsichtlich der neuen Technologie:
„Die neuen Konzepte überzeugen mit ähnlich einfacher Bedienung
und attraktiven Inhalten, womit sich gerade auch PC-Muffel angesprochen fühlen dürften.“ Video2
1
Zeitschrift, http://downloads.magnus.de/download/inhaltsverzeichnis-video-homevision52009.html
2
39
3. Zukunft des IPTV
40
Abbildung 3.1: Fernsehbild bei Verwendung von NetTV von Philips (Quelle: http://www.heise.de).
3.1.1
Internet am Fernsehbildschirm
Die Mehrheit namhafter Fernsehgerätehersteller hat begonnen, auf diesen
Fortschritt zu reagieren und bringt ihre Versionen jener Fernsehgeräte mit
Netzwerkschnittstelle bzw. Internetanschluss auf den Markt.
Philips: Philips 3 hat jegliche Geräte der 9000er-, 8000er-Serie, sowie das
Cinema 21:9 Gerät mit der Möglichkeit Internetinhalte darzustellen ausgestattet4 . Bei Philips nennt sich diese Funktion NetTV 4 . Bei diesem Service
hat der Benutzer neben dem Ansehen von Webinhalten der Philipspartner
(siehe Abbildung 3.1) die Möglichkeit, urls frei einzugeben4 . Das Manko von
NetTV ist jedoch, dass es Java und Flash 5 nicht darstellen kann4 .
Panasonic: Hier nennt sich der Service Viera Cast und setzt sich aus mehreren kleinen Programmfenstern, welche um das Hauptfernsehbild angereiht
sind, zusammen (siehe Abbildung 3.2)4 . Wie die Abbildung zeigt, sieht der
3
http://www.philips.at/
5
http://www.adobe.com/support/documentation/de/flash
4
3. Zukunft des IPTV
41
Abbildung 3.2: Fernsehbild bei Verwendung von Viera Cast von Panasonic
(Quelle: http://pss.panasonic.eu).
Benutzer hier eine Auswahl an dargestellten Echtzeitdaten, zB dem Wetter oder den aktuellen Börsenkursen. Auch Viera Cast verfügt über einen
Webdienst zur Darstellung von Fotos, in diesem Fall übernimmt Picasa 6
von Google diese Aufgabe7 . Weiters verfügen die Dienste von Panasonic und
Philips über Partnerseiten (zB http://www.tagesschau.de bei beiden Optionen), welche speziell für die TV-Darstellung angepasst wurden7 .
Sony: AppliCast lautet Sonys Antwort auf Viera Cast oder NetTV. Laut
http://www.sony.at/hub/bravia/block/6/subblock/2 stellt dieses System dem
Benutzer verschiedenste Widgets zur Verfügung, mit denen der Anwender
wiederum Echtzeitdaten, wie Nachrichten oder aktuelle Uhrzeiten rund um
den Globus, erhalten kann. Diese Widgets werden auf einer Seitenleiste direkt am Bildschirm angezeigt, während das normale Fernsehbild ungestört
weiterläuft7 . Dem Aufbau der GUI liegt laut Sony die Überlegung, das Fernseherlebnis des Sehers nicht zu beeinträchtigen und die Widgets sanft in das
Fernsehbild einzubauen, zugrunde. Zur Erstellung der Widgets wird hier Yahoo Widget 8 verwendet7 .
Samsung: Dieser Hersteller bietet ebenfalls eine Reihe von Widgets, erstellt durch Yahoos Widget Engine 9 (siehe Abbildung 3.3)7 . Wie schon Sony,
6
http://picasa.google.com/
8
http://widgets.yahoo.com/
9
http://widgets.yahoo.com/tools/
7
3. Zukunft des IPTV
42
Abbildung 3.3: Fernsehbild bei Verwendung von Internet@TV von Samsung (Quelle: http://www.gadgetreview.com).
stellt auch Samsung Echtzeit- und Internetdaten am Fernsehbildschirm dar
und versucht, diese so sanft wie möglich in das Fernsehbild einzugliedern10 .
Zusätzlich kann der Benutzer mittels der Yahoo Widget Engine kleine Applikationen selbst erstellen und auf sein Fernsehgerät laden. Abschnitt 3.1.2
geht näher auf die Funktionsweise und Technik dieser „Engine“ ein10 .
3.1.2
Yahoo Widget Channel
Wie schon in Abschnitt 3.1.1 kurz erklärt, handelt es sich bei dem sogenannten Yahoo Widget Channel um eine Applikation, welche es via TV ermöglicht, auf Informationen des Internets zugreifen zu können. Diese Appliktion
setzt sich aus mehreren kleinen Applikationen, sogenannten Widgets zusammen, wobei der Benutzer hier aus einer Liste von Widgets jene aussuchen
kann, welche er gerne auf seinem Fernsehgerät benutzen möchte11 .
Entwickelt wurde der Widget Channel vor allem durch die Kooperation
von Intel 12 und Yahoo 13 . Weiters findet diese Applikation nun Verwendung
bei einigen Fernsehgeräten der Marken Samsung 14 , Sony 15 , LG 16 und VI10
http://connectedtv.yahoo.com/
12
http://www.intel.com/
13
http://www.yahoo.com
14
http://www.samsung.com
15
http://www.sony.com
16
http://www.lg.com
11
3. Zukunft des IPTV
43
ZIO 17 (aus7 ).
Neben der oben erwähnten Liste an möglichen Kleinapplikationen für den
Fernsehbildschirm (darunter befinden sich neben Wetter- und NachrichtenWidgets auch Informations-Widgets von Firmen wie The New York Times
oder VoD-Widgets von zB Blockbuster ) haben zur Zeit Unternehmen aus der
Programmentwicklungs-, der Werbe-, der Verlags-, sowie der Unterhaltungselektronikbranche die Möglichkeit, eigene Widgets zu entwickeln und diese
auf dem Widget Channel dem Benutzer zugängig zu machen.
Widget Entwicklung
Zur Entwicklung selbst stellt Yahoo das sogenannte Widget Development Kit
(WDK) zur Verfügung, welches dem Programmierer ermöglicht, via einer
API seine eigene kleine Applikation zu entwickeln. Die gesamte Technologie
des WDK baut auf die schon bestehende Widget Engine von Yahoo auf. Diese
benutzt xml, um jene Widgets zu erstellen und die Objekte, aus denen sie
bestehen, zu definieren [21]. Das Handbuch [21] zur Erstellung einer solchen
Kleinapplikation führt das folgende, einfache Beispiel an:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
17
Listing 3.1: Yahoo Widget Beispiel
<widget minimumVersion="4.0">
<window id="main_window"
title="Sample Yahoo! Widget"
width="500"
height="500">
<image id="sun1"
src="Resources/Sun.png"
hOffset="250"
vOffset="250"
hAlign="center" />
<text id="text1"
style="font-size:35px;
font-weight:bold"
hOffset="250"'
vOffset="250"'
hAlign="center"
onMouseUp="this.changeOpacity();"
Click Here/>
</window>
<script>
function changeOpacity() {
this.opacity = (this.opacity/100)*90;
}
</script>
</widget>
http://www.vizio.com
3. Zukunft des IPTV
44
Dieses Widget würde nun bei jedem Klick auf den Text „Click Here“ die
Deckkraft des Bildes um 10% verringern. An diesem Beispiel ist erkennbar,
dass sowohl mit xml, als auch mit JavaScript gearbeitet wird. Wobei JavaScript für die Funktionalität der Kleinapplikation eine wichtige Rolle spielt.
Bei umfangreicheren Widgets gibt es die Möglichkeit, das gesamte JavaScript in eine .js-Datei auszulagern. Weiters unterstützt die Widget Engine
auch css bei einigen Objekten, die Stilangaben müssen aber zur Zeit noch
direkt im xml-Code vermerkt werden (siehe style Attribut des text Objektes). Bei zukünftigen Versionen wird es laut Yahoo die Möglichkeit geben,
css-Dateien einzubinden.
3.1.3
Zukunft für Internet am TV
Intel und Yahoo sehen diesem Trend positiv entgegen und bemühen sich,
viel Energie in diese aufstrebende Technologie zu stecken18 . Vor allem der
Benutzer steht für die Entwickler dafür im Vordergrund. Intel setzt hierfür
Anthropologen ein, welche erforschen sollen, wie Menschen das Fernsehgerät
benutzen. Damit wird garantiert, dass sich die entwickelte Technologie so
sanft wie möglich in die jetzige Fernsehlandschaft einbettet. Laut Patrick
Barry – Vizepräsident der Yahoo Connected TV Initiative – soll die Zukunft
folgendermaßen aussehen:
„We see this as moving into the mainstream. In 2009 we’re going
to see good penetration into the product lineups of the consumer
electronics companies. Beginning in 2010 ... you’re going to see
Internet-connected consumer electronics devices dominating the
lineup.“ Patrick Barry18
Um solche Aussagen zu stützen, wurden von Intel darüber hinaus Konsumentenbefragungen durchgeführt, bei denen erhoben wurde, wie sich die Probanden das Zukunftsfernsehen vorstellen würden. Die Antworten können in
drei Kategorien eingeteilt werden und passen ideal zu den Vorstellungen und
technischen Entwicklungen von Yahoo und Intel 18 . Folgende Möglichkeiten
sollten beim Zukunftsfernsehen gegeben sein:
• Teilnahme am Gesehenen, zB durch exaktere Informationen über die
einzelnen Schauspieler und bei welchen Filmen diese bisher mitgewirkt
haben oder welche weiteren Projekte ein bestimmter Regisseur verwirklicht hat. Zusätzlich wären ebenfalls Filmkritiken und -beurteilungen
für die Seher von Interesse.
• Verbindung mit Leuten über soziale Netzwerke wie zB Facebook 19
18
19
aus http://news.zdnet.com/2100-9595\_22-256992.html
http://www.facebook.com
3. Zukunft des IPTV
45
• Bereitstellung von relevanten Echtzeit-Informationen, zB Wetter oder
Nachrichten.
Jene Aussagen der Befragten zeigen deutlich eine Richtung, welche das
Fernsehen in Zukunft einschlagen wird und sollte. Vor allem IPTV, die Verbindung zum Internet und Enwicklungen wie der Widget Channel machen
es möglich, die Fernsehlandschaft nachhaltig und positiv dem Seher gegenüber zu beeinflussen. Innovationen und Entwicklungen in der TV-Branche
werden sich laut Patrick Barry nun eher auf die neuen Potentiale, welche ein
Internetzugang dem Fernsehen bringt, konzentrieren20 .
„...the consumer electronics industry has not really explored the
... connectivity that the Internet provides.“ Patrick Barry20
D. h. die Zukunft liegt in diesem Gebiet und bietet eine Menge an interessanten, innovativen und interaktiven Möglichkeiten für beide, den Benutzer und
den Entwickler.
3.2
Zukunftsvisionen
Abschnitt 3.1 gibt einen Einblick in die Gegenwart bzw. nahe Zukunft des
Fernsehens. Durch technische Fortschritte wie IPTV könnten solche Szenarien bald zu einem fixen Bestandteil der Fernsehlandschaft werden. Dieser Abschnitt geht nun mehr auf die technischen Möglichkeiten, welche sich durch
jene Errungenschaften entwickeln könnten, ein. Wozu wird ein Seher sein
Fernsehgerät in zehn Jahren benutzen?
Der Zugriff auf das Internet ermöglicht es, auf eine enorme Anzahl von
Daten zugreifen zu können und jene für das Fernsehgerät aufzubereiten. Weiters machen Technologien wie zB der Widget Channel es möglich, mittels
Programmierung diese Daten zur eigenen Zufriedenheit bzw. zur Zufriedenheit des Kunden zu verändern, um somit auf dessen Bedürfnisse einzugehen.
Diese Errungenschaften ermöglichen, das Fernseherlebnis für den Kunden
hochgradig zu personalisieren. Bisherige Personalisierungen mittels VoD oder
PVR werden in den Schatten gestellt werden. So wird man zB als Benutzer in
Zukunft in Echtzeit Informationen über jenen Schauspieler erfahren, welcher
soeben durchs Fernsehbild gelaufen ist, obwohl man dessen Namen nicht
kennt. Umgesetzt könnte das Ganze mittels Bildverarbeitungsalgorithmen
werden, welche das ausgewählte Fernsehbild analysieren und die nötige Information an eine Datenbank weiterleiten, diese wiederum schickt die passenden
Daten zurück an das Gerät des Sehers. Auch die Verwendung von sozialen
Netzwerken via TV-Gerät bietet dem Seher viele neue Möglichkeiten der
Interaktion. So besteht die Möglichkeit sich über einen Film noch währenddessen auszutauschen oder zB in Erfahrung zu bringen, welches Programm
20
3. Zukunft des IPTV
46
ein Freund zur Zeit sieht. Diese Option der Einbindung hängt natürlich in
erster Linie vom Benutzer ab, da man dadurch schon sehr in die Privatsphäre des Sehers eindringt. Eine weitere Anwendung fände im Bereich des
T-Commerce statt. Hier könnten nicht nur Produkte, welche ein bestimmter
Fernsehkanal anbietet gekauft werden. Wird ein interessantes Auto in einem
Film gesehen, so kann zB der Kaufpreis oder andere Informationen bezüglich des PKWs abgefragt werden. Dies bietet der Produktvermarktung via
Product Placement viele neue Möglichkeiten. So könnte man Produkte nicht
nur in Werbungen, sondern auch in Serien und Filmen speziell kennzeichnen, damit der Seher bei Interesse auf die Website des jeweiligen Produktes
gelangen und sich darüber informieren kann.
Auch hinsichtlich IPTV-Systemen von Serviceanbietern könnte es eine
Vielzahl von Möglichkeiten geben, diese Technologie auszunutzen. So könnte
zB die Tatsache, dass ein Serviceanbieter für jedes Hotel einer Hotelkette rund um den Globus zuständig ist, eine Personalisierung hinsichtlich des
einzelnen Hotelgasts bieten. Einem Geschäftsreisenden, welcher den Großteil
seines Arbeitsjahres in Hotels verbringt, wird eine SmartCard mit allen nötigen Profileinstellungen, Benutzerdaten und benutzten Applikationen vom
Hotel gegeben. Jene Karte kann der Reisende nun in allen Set-Top Boxen
der gleichen Hotelkette verwenden, um somit immer auf sein persönliches
Fernsehprofil zugreifen zu können, welches ihm zB immer Echtzeit-Daten
über die neusten Nachrichten seiner Branche oder das aktuelle Wetter seines
gegenwärtigen, sowie seines zukünftigen Aufenthaltsortes liefert. Dies würde
somit den Vorteil für den Kunden bringen, immer auf die nötigen Daten zugreifen zu können, in einem stets gleich zu bedienenden System. Auch für die
Hotelkette bietet es den Vorteil, dass somit ein Kunde wiederholt in einem
ihrer Hotels übernachten wird.
Dies sind nur einige Visionen bezüglich der Zukunft des Fernsehens, eine
weitere Vision wird in Teil II thematisiert, konkretisiert und umgesetzt.
Teil II
Praktische Arbeit: Sports
Notification System
47
Kapitel 4
Entwurf und Konzept
Dieser Teil der Arbeit beschäftigt sich mit der entsprechendend praktischen
Umsetzung einer Applikation, welche Echtzeit-Informationen auf den Fernsehbildschirm bringt. Das aktuelle Kapitel geht auf die Ideenfindung, die
Ziele der Anwendung, sowie die Anforderungen, welche an die Applikation
gestellt werden, ein.
4.1
Ziele der Anwendung
Aufgrund der, in Teil I erläuterten Entwicklungen von IPTV bzw. der Fernsehlandschaft, war das grundsätzliche Ziel, eine Anwendung zu schaffen, welche sich die Vorteile von IPTV (zB den Rückkanal) zunutze macht und dem
Seher zusätzlich eine mögliche Personalisierungs-, sowie Interaktionsoption
bietet, die sich sanft in das bisherige Fernseherlebnis einbindet.
Von jenem grundsätzlichen Ziel ausgehend wurde dann die Entscheidung
gefällt, eine Applikation zu entwickeln, welche es dem Benutzer ermöglichen
soll, Informationen über einen bestimmten, von ihm gewählten Marathonläufer zur Zeit des Marathons auf den Fernsehbildschirm geliefert zu bekommen.
Ausschlaggebend für die Idee hinsichtlich des Marathons war die Tatsache,
dass ein solches System für Mobiltelefone bereits besteht und schon mehrmals erfolgreich eingesetzt wurde. D. h. die Marathon-spezifischen Daten, um
nun eine solche TV-Applikation zu entwickeln, werden zur Zeit des Marathons in eine bereits bestehende Datenbank geschrieben und können für die
Anwendung verwendet werden.
Zusätzlich zur Idee hinsichtlich der zu entwickelnden Anwendung wurde
auch eine technische Plattform zur Umsetzung gesucht und gefunden. Die
Entscheidung fiel auf die in Kapitel 2.3 erwähnte Dreambox, die es erlaubt,
Plug-Ins zu erstellen, welche aufgrund der Verbindung zum Internet auch
mit Datenbank-Inhalten von netzwerkfremden Servern arbeiten können. Ein
weiterer Grund, eine intelligente Set-Top Box als IPTV Gerät zu verwenden,
war die Tatsache, dass die Dreambox es ermöglicht, das Fernsehvergnügen
48
4. Entwurf und Konzept
49
auf einfache, direkte Weise zu personalisieren. Wie schon in Abschnitt 2.4
erwähnt, ist ein flexibles, persönliches und unkompliziertes Arbeiten, ohne
Umwege über ein fremdes System möglich. Prinzipiell ist alles erlaubt und
die Entwicklung eines Plug-Ins auf diesem Gerät unterliegt keinen massiven
Restriktionen, welche die Arbeit einschränken würden.
4.2
Anforderungen an das Plug-In
Eine der wichtigsten Anforderung im Vorfeld der Konkretisierung der Idee
war die Tatsache, dass das Plug-In simpel und zuverlässig hinsichtlich Bedienung und Betriebsweise sein musste1 . Vor allem der Benutzer und dessen
Sehgewohnheiten sollten im Vordergrund stehen, nachdem vergangene Versuche das Fernsehen interaktiver zu gestalten gescheitert sind, da Passivität
im Gegensatz zu aggressiver Interaktivität bei Weitem bevorzugt und meist
vom Seher als Wohltat empfunden wird [17]. Deshalb sollte die Applikation
sanft integrierbar sein, ohne die bisherigen Fernsehgewohnheiten des Sehers
bewusst zu verletzen2 . Diese Tatsache bestätigt auch Intels Anthropologin
Genevieve Bell.
„The success of these services partly hinges on the usability of
the interface. TVs are easy to use, and the interface needs to flow
in smoothly without breaking the TV experience people are used
to“ Genevieve Bell2
D. h. die Anforderungen, sowie auch die weitere Ideenentwicklung kann in
zwei wichtige Teile eingeteilt werden:
Benutzerfreundlichkeit: Vor allem hinsichtlich der Gestaltung der Oberfläche, der Integration in das Fernsehbild und der Logik der Steuerung.
Technik: Hier sollten in erster Linie alle technischen Vorteile, welche durch
IPTV bzw. durch eine Verbindung mit dem Internet und mit fremden Datenservern möglich sind, genutzt werden. D. h. eine aktive Verwendung des Rückkanals muss im Endprodukt gegeben sein, um eine
gewisse Interaktivität zu gewährleisten. Weiters spielt die Schnelligkeit der Datenübertragung eine Rolle, die in enger Verbindung mit der
Benutzerfreundlichkeit steht.
Diese beiden Hauptanforderungen müssen im Plug-In bestmöglich miteinander verschmelzen damit ein optimales technisches sowie auch benutzerfreundliches Endergebnisse zustande kommen kann.
1
2
aus http://www.itworld.com/print/59340
4.3
50
Präzisierung der Idee
Nachdem die Grundidee gefunden und die Anforderungen an das Plug-In
gestellt sind, folgt nun die Präzisierung der konzeptionellen Anfangsgedanken
mit Rücksicht auf die in Abschnitt 4.2 definierten Anforderungen hinsichtlich
Benutzerfreundlichkeit und Technik.
4.3.1
Der Inhalt
Eine der am Anfang zu klärenden Fragen betrifft den Inhalt, welchen das
Plug-In darstellen sollte. D. h. welche Informationen sollen dem Benutzer zur
Verfügung stehen. Im Wesentlichen wurde der darstellbare Inhalt vom Umfang der bereits bestehenden Datenbank (DB) beeinflusst. Hinzu kam noch
die Zeitspanne, in der jene Daten aktualisiert wurden, d. h. ein Einflussfaktor war das bestehende System, mit welchem die Inhalte für die Datenbank
gemessen wurden3 .
Aufgrund der oben genannten Restriktionen kamen nur Inhalte in Frage,
welche sich aus den Daten der Datenbank berechnen oder übernehmen ließen.
Da das Plug-In zudem so simpel wie möglich gehalten werden sollte, wurden
folgende Läufer-spezifische Daten festgelegt:
• Startnummer
• Name des Läufers
• Gelaufene Kilometer
• Aktuelle Laufzeit
• Aktuelle Platzierung
• Aktuelle Geschwindigkeit
• Startgruppe
• Gruppenplatzierung
Weitere Überlegungen hinsichtlich des darzustellenden Inhalts betrafen
folgende Laufinformationen:
• Voraussichtliche Ankunftszeit
• Voraussichtliche Platzierung
3
Das System funktioniert mittels eines General Packet Radio Service (GPRS) Chips,
welchen der Läufer ständig bei sich trägt. Auf der gesamten Laufstrecke liegen in gleichmässigen Abständen Matten. Läuft nun ein Teilnehmer über diese Matte, wird er registriert und die Datenbank aktualisiert die jeweiligen Spalten des entsprechenden Läufers.
51
• Voraussichtliche Gruppenplatzierung
• Durchschnittsgeschwindigkeit
• Laufzeit zwischen zwei Messpunkten
4.3.2
Die Funktionen
Das Augenmerk bei den Funktionalitäten der Anwendung lag auf der logischen Anordung, sowie der einfachen Bedienbarkeit hinsichtlich des Benutzers. Er sollte durch das Plug-In so wenig wie möglich in seinem normalen
Fernsehvergüngen gestört werden. Dennoch war es wichtig, die Applikation
so zu gestalten, dass sich der Seher bei größerem Interesse soviele Informationen wie möglich dadurch beschaffen konnte.
Die weiteren Überlegungen betreffend der Funktionalitäten waren von
den gegebenen Inhalten (siehe Abschnitt 4.3.1) sowie den Möglichkeiten hinsichtlich der zur Verfügung stehenden Technik abhängig. Folgende Überlegungen bezüglich des möglichen Funktionsumfanges des Plug-Ins wurden in
Erwägung gezogen:
Informationen über den favorisierten Läufer: Der Benutzer sollte sich
einen favorisierten Läufer (FL) auswählen können, dessen Informationen (siehe Abschnitt 4.3.1) standardmäßig angezeigt werden. Die Auswahl des FL könnte mittels einer Anmeldung auf einer Webseite (per
PC) oder bei Start der Anwendung passieren.
Liste aller Läufer: Dem Anwender steht eine geordnete Liste aller teilnehmenden Läufer zur Verfügung, welche er nach einem bestimmten
Teilnehmer durchsuchen kann.
Informationen über einen Läufer: Aus der Liste aller Teilnehmer kann
der Benutzer einen auswählen, dessen Informationen ihm im gleichen
Format wie jene des FL angezeigt werden.
Läufer wechseln: Die Applikation muss ein einfaches Wechseln zwischen
den verschiedenen Läufern und deren Informationen ermöglichen. Vor
allem sollte der Benutzer so einfach wie möglich wieder zu den Informationen seines FL zurückkehren können.
Ein-/Ausblenden der Applikation: Zur sanften, also nicht aufdringlichen Einbettung der Applikation in das Fernseherlebnis, soll sich jene
einfach ein- und ausblenden lassen können bzw. diese Funktion automatisch erledigen. Das Ausblenden ist, so scheint es, eine der wichtigsten
Funktionen hinsichtlich Benutzerfreundlichkeit, da die Benutzer laut
Intel den Wunsch haben, Fernsehapplikationen mit einem einfachen
52
Knopfdruck verschwinden lassen zu können4 . Die Funktionalität des
Einblendens sollte abhängig von der Aktualität des Inhalts sein, d. h.
sobald die Informationen des FL in der Datenbank aktualisiert wurden,
sollen jene automatisch am Fernsehbildschirm erscheinen. Somit kann
der Benutzer seine gewünschte Passivität beim Fernsehen (siehe [17])
behalten und sich nur bei speziellen Wünschen der Bedienung widmen.
Standortinformationen des Läufers: Zur Erweiterung des Informationsinhalts bezüglich des gewählten Teilnehmers kann der Benutzer mittels
integrierter Satellitenansicht den aktuellen Standort betrachten.
Informationsvergleich der Läufer: Die Informationen (zB aktuelle Laufzeit, Geschwindigkeit oder Position) von zwei unterschiedlichen Läufern können miteinander verglichen werden. Auch der aktuelle Standort der beiden Läufer kann via Satellitenbild vergleichend betrachtet
werden.
Informationsvergleich eines Läufers: Eine weitere mögliche Funktionalität der Anwendung könnte der Informationsvergleich eines einzelnen
Läufers mit sich selbst sein, um zB Verbesserungen oder Verschlechterungen zum Vorjahresmarathon zu erkennen. Diese Funktion ist nur
entwickelbar, falls die alten Daten archiviert und zur Verfügung gestellt
werden.
Dies sind jene Funktionen, welche sich lediglich auf die Informationsüberlieferung der Marathon-spezifischen Daten des gewählten Läufers an den Benutzer konzentrieren. Zusätzlich zu diesen Fähigkeiten der Anwendung gibt
es eine Vielzahl weiterer Möglichkeiten. Eine Option wäre, dass sich die Informationen zB nicht nur auf jene aus der Datenbank beschränken. Wählt der
Benutzer einen berühmten Marathonläufer aus, so würden dem Anwender
bei Bedarf persönliche Details dieser Person aus dem Internet geliefert werden. Eine andere Möglichkeit wäre das Fernsehbild zu analysieren und nur
die darauf sichtbaren Läufer aufgrund ihrer Startnummer zu identifizieren
und deren Details anzuzeigen.
Die Liste der potentiellen Möglichkeiten eines solchen Plug-Ins sind umfangreich und müssen vor der technischen Entwicklung sorgfältig hinsichtlich
des gewünschten Zieles aussortiert werden.
Ein weiterer wichtiger Punkt des Funktionsumfanges betrifft die logische
Bedienung der Applikation. Aufgrund der Tatsache, die Bedienung für den
Benutzer so unkompliziert wie möglich zu gestalten4 , kann und sollte keine komplexe Menüstruktur umgesetzt werden. Die Navigationslogik sollte so
einfach und überschaubar realisiert werden, damit der Benutzer keine Probleme bei der Steuerung hat.
4
53
Abbildung 4.1: Dieser Ansatz der Benutzeroberfläche stellt alle Informationen gleichzeitig dar. Die Voraussetzung dafür ist ein zusätzliches Ein- und
Ausblenden der einzelnen Informationsfenster. Weiters ist das Fernsehbild
durch die Transparenz der einelnen GUI-Elemente nicht vollständig verdeckt.
Hauptfenster hierbei ist jenes Element mit den „Läuferinformationen“. Die
„Steuerungsinformationen“ dienen zur Erklärung der Navigation durch die
Anwendung bzw. der Funktionsweise des Plug-Ins, d. h. was muss auf der
Fernbedienung gedrückt werden, um zB die Läuferliste auszublenden. Die
Elemente „Läuferliste“ und „Standort des Läufers“ beinhalten einerseits eine
Liste aller Teilnehmer, andererseits ein Satellitenbild des aktuellen Standortes des Läufers.
4.3.3
Benutzeroberfläche
Wie schon in Abschnitt 4.2 erwähnt, soll sich die Anwendung sanft in das
bisherige Fernseherlebnis des Sehers einfügen. Hierbei spielt vor allem die
Gestaltung und Positionierung der Grafischen Oberfläche (GUI) eine entscheidende Rolle. Die Überlegungen hinsichtlich dieser Thematik befassen
sich vor allem mit der Größe und der Positionierung der Applikation, da die
grafische Gestaltung durch die vorhandenen grafischen Themen der Dreambox bereits vorbestimmt ist.
Abbildung 4.1 zeigt die ersten Versuche zur Positionierung, welche aber
hinsichtlich der Verbindung von Fernsehbild und Applikation nicht zufriedenstellend waren. Weitere Überlegungen zogen die gegenwärtigen GUI-Positionierungen auf dem Fernsehgerät in Betracht, vor allem jene hinsichtlich
54
(a)
(b)
(c)
Abbildung 4.2: Diese Abbildungen zeigen die verschiedenen Modi der Applikation. Der Standardmodus (a) besteht aus einem aus- und einblendbaren
Element, das die Informationen eines Läufers anzeigt. Neben diesen Informationen gibt es auch noch Auskunft über die Funktionsweise der Navigation, die auch im „Standort“-Modus (b) gegeben wird. Dieser Modus zeigt
den aktuellen Standort des Läufers in Form eines Satellitenbildes. (c) zeigt
den „Listen“-Modus, welcher eine Liste aller Läufer anzeigt. Auch hier gibt
es wieder Steuerungsinformationen. Es ist möglich zwischen allen Modi zu
wechseln.
55
Abbildung 4.3: Positionierung der allgemeinen Kanal- und Programminformation bei Verwendung der Dreambox DM 800 HD PVR.
der allgemeinen Kanal- und Programminformation (siehe Abbildung 4.3).
Diese Informationen werden stets am unteren Rand des Fernsehbildschirms
angezeigt und verschwinden meist nach einiger Zeit wieder automatisch (hierbei entstand auch die Idee der Ein-/Ausblend-Funktion aus Abschnitt 4.3.2).
Untertitel, d. h. spezielle Informationen zu Filmen, erscheinen auch stets im
unteren Bereich des Fernsehbildschirms. Aussagen der Intel-Anthropologin
Genevieve Bell zufolge, bevorzugen Seher den unteren Rand bei der Positionierung der Widget Channel Applikation, da jene an Informationen in diesem
Bereich ohnehin gewohnt sind5 . Somit zeigt und erklärt Abbildung 4.2 die
GUI-Positionierung und -Aufteilung nach diesen Überlegungen.
4.3.4
Programmlogik
Die in Abbildung 4.2 gezeigte Benutzeroberflächenlösung war ein wichtiges
Kriterium bei den Überlegungen hinsichtlich der Programmlogik, d. h. wie
ist die Applikation zu bedienen, was ist von wo aus steuerbar. Aufgrund
der Aufteilung in drei verschiedene Programmmodi ist eine grundsätzliche
Programmlogik bereits vorgegeben.
Wie schon in Abschnitt 4.3.3 erwähnt, soll der Benutzer vom aktiven
Modus die zwei inaktiven Modi erreichen. Diese Tatsache setzt voraus, dass
für jeden Modi eine spezielle Taste auf der Fernbedienung zuständig ist, welche sich unabhängig vom aktiven Modus nicht verändert, dies wäre also eine
5
aus http://www.itworld.com/print/59340
56
Abbildung 4.4: Diese Grafik zeigt den Funktionsaufbau der einzelnen Modi. Die Anwendung ist aufgeteilt in drei Module, die „Läuferinformation“, die
„Läuferliste“ und den „Läuferstandort“. Alle drei Programmteile sind funktionsmässig miteinander verknüpft, d. h. bei zB aktuellem „Läuferliste“-Modus,
wird bei Auswahl eines bestimmten Läufers in den „Läuferinformations“Modus gewechselt. Zusätzlich kann dessen Standort im „Läuferstandort“Modus angesehen werden. Weiters müssen bestimmte Daten zwischen den
Modulen ausgetauscht werden (dazu später mehr in Kapitel 6). In jedem
Modus soll es möglich sein, die Anwendung beenden zu können. Zusätzlich
verfügt jedes der einzelnen Module über eigene Funktionen.
global gültige Bedienungsregel. Neben den global gültigen Regeln bzw. Funktionen gibt es noch Modus-spezielle Funktionen, welche nur für den jeweils
aktiven Modus gelten (beim „Läuferlisten“-Modus zB die Funktion, die Liste
zu durchsuchen oder einen Eintrag aufgrund einer Sucheingabe zu finden).
Abbildung 4.4 gibt eine Übersicht über die verschiedenen Funktionalitäten
der einzelnen Modi und wie diese miteinander verknüpft sind. Die finale Lösung hinsichtlich der Programmlogik wird in Abschnitt 6.1 näher erörtert.
Kapitel 5
Technologien
Für die technische Umsetzung des in Kapitel 4 beschriebenen Konzepts waren einige zu verwendende Technologien schon vorgegeben (zB Dreambox ).
Auch hinsichtlich der Softwaretechnologie zur Plug-In Programmierung wurde die Auswahl an Programmiersprachen auf eine einzige – Python 1 – reduziert. In diesem Kapitel wird nun auf die verschiedenen Technologien eingegangen.
5.1
Hardwaretechnologien
Die für die Umsetzung verwendete Hardwaretechnologie wurde durch das
Konzept dieses Projekt bereits festgelegt. Wie in Kapitel 4 erwähnt, befasst
sich das praktische Projekt damit, ein Plug-In für die STB Dreambox DM 800
HD PVR zu enwickeln. Diese Tatsache selbst legt nicht gänzlich fest, dass die
Hardwaretechnologie auch jene Box sein muss, denn wie schon in Abschnitt
2.4.1 erklärt, kann jene grafische Programmschnittstelle – die Enigma2 –,
welche unter Anderem auf der DM 800 Verwendung findet, auch auf PCs
benutzt werden. Deshalb war die praktische Umsetzung des Konzepts hinsichtlich der zur Verfügung stehenden Hardware nicht völlig eingeschränkt.
Die Entscheidung fiel letztendlich trotzdem auf die in den Abschnitten
2.3 und 2.4.1 näher erläuterte Version der Dreambox (siehe Abbildung 2.2).
Ein Grund dafür war der geringere Arbeitsaufwand zu Beginn der Durchführung, da die nötige Software schon auf dem Gerät installiert ist und das
Augenmerk nun primär auf der Entwicklung des Plug-Ins liegen konnte. Ein
zusätzlicher, wohl noch ausschlaggebenderer Grund war, dass die Verwendung von Enigma2 auf einem Computer noch nicht gänzlich ausgereift ist2 .
Dies hätte den Prozess der Entwicklung um einiges erschwert und der nötige
Fokus auf die Entwicklung einer für den Benutzer optimalen Applikation –
wie in Kapitel 4 beschrieben – wäre nicht mehr so stark gewesen.
1
2
http://www.python.org
57
5. Technologien
58
Die Dreambox hinsichtlich ihrer Hardware bietet – wie bereits in Kapitel
2 erwähnt – folgendes:
• 300 Megahertz(MHz) MIPS3 Prozessor
• Organische Leuchtdiode (OLED) für die Anzeige
• MPEG-2 / H.264 Hardware-Dekodierung
• DVB-S Tuner4
• Smartcard Leser
• 64 Megabyte Flash-Electrically Erasable Programmable Read Only Memory (EEPROM)
• 256 Megabyte RAM
• Integrierter Serial Advanced Technology Attachment (SATA) Anschluss
• Infrarot (IR) Fernbedienung mit äquivalentem IR-Empfänger an der
Dreambox
Angeschlossen wird diese STB entweder via DVI und HDMI oder via
SCART an das Fernsehgerät. Ein weiterer wichtiger Teil der HardwareAusstattung ist die Fernbedienung, welche die Benutzerschnittstelle darstellt.
Der Anwender steuert damit die Applikation, in dem er die dafür vorgesehenen Tasten bedient. Das in Kapitel 4 erläuterte Plug-In verwendet zur
Steuerung nicht alle Tasten der Fernbedienung. Es beschränkt sich lediglich
auf die in Abbildung 5.1 gezeigten. Im nächsten Kapitel wird die Verwendung
der einzelnen Tasten und die dafür nötige Implementierung ausführlicher erklärt.
5.2
Softwaretechnologien
Die Auswahlmöglichkeiten hinsichtlich der Softwaretechnologien war größtenteils vorgegeben. Da die GUI der Dreambox – Enigma2 – grundsätzlich
in Python entwickelt ist (siehe dazu Abschnitt 2.4.1), ist diesbezüglich eine
Plug-In-Entwicklung in Python ebenso vorgesehen. Um ein Plug-In erstellen
zu können, ist ein Standardaufbau vorgegeben, welcher entsprechend erweitert und verändert werden kann bzw. muss. Dieser Aufbau wird in diesem
Abschnitt erklärt, in Abschnitt 6.1 wird konkret auf das entwickelte Plug-In
und dessen speziellen Aufbau eingegangen.
3
„Microprocessor without Interlocked Pipeline Stages“ bzw. „Mikroprozessor ohne
Pipeline-Sperren“
4
DVB-C und DVB-T sind optional
5. Technologien
59
Abbildung 5.1: Die Fernbedienung der DM800. Hervorgehoben sind jene
Tasten, welche beim Plug-In eine Funktion haben.
Alle Plug-Ins, welche auf der Dreambox installiert sind, liegen im Ordner /usr/lib/enigma2/python/Plugins. Dort sollte auch jene Anwendung
einen Ordner besitzen, welche selbst erstellt wird5 . Im Ordner selbst kann die
Aufteilung hinsichtlich Dateien in Unterordnern oder Code in .py-Dateien
beliebig gestaltet werden5 . Vorgabemässig müssen folgende zwei Dateien vorhanden sein, damit das Plug-In ordnungsgemäß ausgeführt werden kann5 :
__init__.py: Diese Datei muss keine Information bzw. keinen Code enthalten – kann also leer sein – sie wird dennoch zur Ausführung des
Plug-Ins benötigt, da das Verzeichnis ansonsten von Python nicht als
Modul erkannt wird5 .
plugin.py: Diese Datei stellt das Hauptskript der Applikation dar, dessen
Inhalt teilweise vorgegeben ist, wie Listing 5.1 zeigt5 .
5
5. Technologien
60
Listing 5.1: plugin.py
from Plugins.Plugin import PluginDescriptor
#Import des PluginDescriptors, welcher der GUI Eigenschaften des Plugins
#übergibt (zB Wie lautet der Name? In welchem Menü soll es angezeigt
#werden? ...)
1
2
3
4
5
#Funktion welche noch bevor das Plugin gestartet, zur Ermittlung der
#Eigenschaften des Plug-Ins aufgerufen wird.
#Rückgabewert dieser Funktion ist entweder ein einzelner PluginDescriptor
#oder eine Liste von PluginDescriptoren
def Plugins(**kwargs):
#hier wird ein einzelner PluginDescriptor zurückgegeben, welcher unter
#Anderem angibt, dass das Plug-In im Plug-In-Menü der Dreambox
#erscheint
return PluginDescriptor(name="my_Plugin", description="Example
Plugin", where=PluginDescriptor.WHERE_PLUGINMENU, fnc=main)
6
7
8
9
10
11
12
13
14
15
#die zweite Option zur Rückgabe wird hier gezeigt, eine Liste
#von PluginDescriptoren, wobei das erste Plug-In im Plug-In-Menü, das
#zweite beim Autostart der Box aufgerufen wird
return [PluginDescriptor(name="my_Plugin", description="Example
Plugin", where=PluginDescriptor.WHERE_PLUGINMENU, fnc=main),
PluginDescriptor(where = PluginDescriptor.WHERE_AUTOSTART,
fnc = autostart) ]
16
17
18
19
Neben dem in Listing 5.16 gezeigten Code gibt es natürlich auch eine
main-Funktion, welche beim Start des Plug-Ins aufgerufen wird. Diese Funktion erhält einen Parameter session, welcher sich zB um den Aufruf eines Screens kümmert, wie in Listing 5.26 , wobei es sich hierbei um zwei
Varianten des Screen Aufrufs handelt. Im Gegensatz zu session.open verfügt session.openWithCallback über einen zweiten Parameter, welcher eine Funktion angibt, die beim Schließen des mit session.openWithCallback
geöffneten Screens aufgerufen wird.
Nun sollte ausgehend von der main-Methode die gesamte Programmlogik
aufgebaut werden.
Listing 5.2: Aufrufen eines Screens
#Variante 1
session.open(<screen>)
#Variante 2
session.openWithCallback(<boxClosed>, <screen>)
1
2
3
4
Der Platzhalter <boxClosed> steht für die Methode, welche beim Schließen des jeweiligen Screens aufgerufen wird. Der Ausdruck <screen> stellt ein
Objekt einer Klasse dar, welche von Screen abgeleitet ist und den Aufbau
sowie die Funktionalität des zu öffnenden Screens beschreibt. Ein einfacher
Aufbau einer solchen Klasse wird in Listing 5.36 gezeigt.
6
5. Technologien
61
Listing 5.3: MyPlugin Klasse
class MyPlugin(Screen):
#Diese Variable definieren Aussehen und Inhalt des Screens
#Diese Angaben können entweder direkt an dieser Stelle gemacht werden
#oder in eine XML-Datei ausgelagert werden
skin = """
<screen position ="20,20" size="300,200" title ="Anfangs−Screen" >
<widget name="button" position="10,0"
size ="190,250" scrollbarMode="showOnDemand" />
<widget name="label" position="200,0"
size ="190,250" alphatest="on" />
</screen>"""
1
2
3
4
5
6
7
8
9
10
11
12
#Konstruktor der Funktion
def __init__(self, session, args = None):
#die Screen-Klasse muss hier ebenfalls initialisiert werden um über
#alle Funktionen verfügen zu können
Screen.__init__(self, session)
13
14
15
16
17
18
#hier werden die Variablen des Screens initalisiert, welche im XML-Code
#definiert wurden
self["button"] = Button(_("ButtonName"))
self["label"] = Label(_("LabelName"))
19
20
21
22
23
#zusätzlich wird mittels einer ActionMap bestimmt, welche Tasten der
#Fernbedienung bedienbar sind und wofür diese zuständig sind
#pro verwendeter Taste wird eine Klassenfunktion angegeben, welche
#beim Drücken der Taste aufgerufen wird
self["actions"] = NumberActionMap(["WizardActions", "
InputActions"],
{
"ok": self.ok,
"back": self.close,
"left": self.keyLeft,
"right": self.keyRight,
"1": self.keyNumberGlobal,
"0": self.keyNumberGlobal
}, -1)
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Listing 5.37 zeigt die Möglichkeit des in die Python-Datei integrierten
7
5. Technologien
62
Screen-Aufbaus. Als zusätzliche Option existiert die Auslagerung dieser Angaben in eine seperate .xml-Datei. Dies ist vor allem üblich oder praktisch,
falls der grafische Aufbau etwas komplexer ist oder eine Reihe von Widgets
aufgelistet sind. Listing 5.48 zeigt den oben beschriebenen Screen, wie er in
einer xml.-Datei umgesetzt werden würde.
Listing 5.4: skin.xml
<skin>
<screen name="MyPlugin" position="20,20" size="300,200" title="
Anfangs-Screen" >
<widget name="button" position="10,0"
size="190,250" scrollbarMode="showOnDemand" />
<widget name="label" position="200,0"
size="190,250" alphatest="on" />
</screen>
</skin>
1
2
3
4
5
6
7
8
Der einzige Unterschied zur Implementierung in Listing 5.32 ist, dass
<skin> den restlichen Code als weiteres Element umschließt und dass <screen>
als zusätzliches Attribut name enthält. Beide Lösungen ergeben den exakt
gleichen Screen.
Die einzelnen <widget> Elemente werden nun einer passenden Klasse zugewiesen, wie Listing 5.38 zeigt. Hierbei gibt es vordefinierte Klassen, welche
im Ordner /usr/lib/enigma2/python/Plugins/Components zu finden sind.
Als Beispiel sind hier Label() und Button() angegeben, wobei Label() zB
die Kennzeichnung eines Elementes darstellt. Button() hingegen wird dazu
verwendet, ein Element als Schaltfläche auszuzeichnen, welche aktivier- bzw.
deaktivierbar ist.
Der Entwickler hat nun zusätzlich die Möglichkeit eine beliebige Anzahl
von Klassen, welche von Screen abgeleitet sind, zu kreieren und diese in
beliebiger Reihenfolge und willkürlich zu verwenden.
Um nun ein solches entwickeltes Plug-In auf der Dreambox abspeichern
zu können, gibt es verschiedene Arten des Zugriffs auf jene (wie schon in
Abschnitt 2.3.3 kurz erwähnt). Eine Verbindung zwischen Dreambox und einem Windows PC kann mittels Samba hergestellt werden. Die STB kann
dadurch simpel über die Netzwerkumgebung von Windows erreicht werden
(siehe Abbildung 5.2). Da Linux als Betriebssystem auf der Dreambox läuft,
gibt es eine Zugriffsoption, die es ermöglicht, direkt auf die Shell zugreifen zu
können. Dies ist via Telnet oder Secure Shell (SSH) 9 realisierbar (siehe Abbildung 5.3) und wird meist nur für administrative Zwecke verwendet8 . Für
die Realisierung eines solchen Zugriffs existieren verschiedenste Programme
wie zB das in Abbildung 5.4 gezeigte PuTTY10 .
8
http://cplus.about.com/od/glossar1/g/SSH.htm
10
http://www.chiark.greenend.org.uk/~sgtatham/putty/
9
5. Technologien
63
Abbildung 5.2: Zugriff auf die Dreambox mittels Netzwerkumgebung via
Samba.
Abbildung 5.3: Zugriff auf die Dreambox mittels PuTTY via Telnet bzw.
SSH.
5.3
Netzwerkprogrammierung
Dieser Abschnitt behandelt das Thema Netzwerkprogrammierung hinsichtlich der Verbindung der externen Läuferdatenbank mit dem Plug-In. Anfänglich wurden zwei Aufbauarten von Verbindungen in Betracht gezogen:
Socket API: Dies stellt eine Reihe von Funktionen für die Netzwerkprogrammierung zur Verfügung, welche es ermöglichen, Daten via zB TCP
zu übertragen [19]. Für Client und Server ergibt sich dadurch die Möglichkeit, verschiedene APIs sowie auch Betriebssysteme zu verwenden,
vorausgesetzt es wird das gleiche Netzwerkprotokoll zur Datenübertragung eingesetzt [19]. Somit können nun Daten vom Client zum Server
5. Technologien
64
Abbildung 5.4: PuTTY - ein Client-seitiges, freies Programm für MS Windows und Unix um auf einen SSH- bzw. Telnet-Server zugreifen zu können.
und vice versa übertragen werden. Listing 5.6 und 5.5 [16, S. 565]
veranschaulichen einen einfachen Aufbau eines solchen Netzwerkübertragungssystems in Python.
Remote Procedure Call (RPC): Bei dieser Lösung der Netzwerkübertragung werden Client-seitig Server-seitige Funktionen aufgerufen [19].
Für den Entwickler selbst hält sich der Netzwerkprogrammierungsteil in Grenzen bzw. wird gänzlich obsolet. Zur Durchführung von
RPC ist die Einbindung spezieller Programmbibliotheken nötig, wie
zB xmlrpclib11 im Falle von Python. Listing 5.8 und 5.7 [16, S. 803]
stellen eine einfache Anwendung von xmlrpclib dar.
11
http://docs.python.org/library/xmlrpclib.html
5. Technologien
65
Listing 5.5: Socket Server
1
import socket
2
3
4
5
6
#Symbolischer Name, bedeutet alle verfügbaren Schnittstellen
HOST = ''
#Zufälliger, nicht belegter Port
PORT = 50007
7
8
9
10
11
12
#Erstellung eines neuen Sockets
#AF_INET definiert IPv4 als Protokollfamilie
#SOCK_STREAM bestimmt die Kommunikation via TCP
#Bei SOCK_DGRAM würde via UDP kommuniziert werden
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
13
14
15
#Bindet den Socket an die Adresse (definiert durch HOST und PORT)
s.bind((HOST, PORT))
16
17
18
19
#Warten (Horchen) auf Verbindungen zum Socket
#Der Parameter gibt die maximale Anzahl an möglichen Verbindungen an
s.listen(1)
20
21
22
23
24
25
26
#Akzeptieren eine Verbindung
#Rückgabewert ist einerseits „conn“ welches zum Senden und Empfangen von
#Daten zuständig ist
#Andererseits „addr“ welches die an den Socket gebundene Adresse auf der
#anderen Seite (d. h. beim Client) darstellt
conn, addr = s.accept()
27
28
29
30
31
32
33
while 1:
#vom Client gesendete Daten werden empfangen
data = conn.recv(1024)
if not data: break
#die empfangenen Daten werden wieder an den Client zurückgeschickt
conn.send(data)
34
35
36
37
#Schließen des Sockets, vom Client gesendete Daten werden somit nicht
#mehr empfangen
conn.close()
Listing 5.6: Socket Client
1
import socket
2
3
4
5
6
#Server
HOST = 'daring.cwi.nl'
#gleicher Port wie beim Server
PORT = 50007
7
8
9
#Erstellung eines neuen Sockets
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
5. Technologien
66
10
11
12
#Verbinden zum Server
s.connect((HOST, PORT))
13
14
15
#Senden der gewünschten Daten
s.send('Hello, world')
16
17
18
#Empfangen der vom Server gesendeten Daten
data = s.recv(1024)
19
20
21
1
#Schließen der Verbindung
s.close()
Listing 5.7: RPC Server
import SimpleXMLRPCServer
2
3
4
5
#Erstellen des Servers, welcher auf einkommende Anfragen des „localhost“ auf
#Port 8000 wartet
server = SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost",
8000))
6
7
8
9
#Erstellen einer Funktion
def add(x,y):
return x + y
10
11
12
13
#Registrieren der definierten Funktion um jene für den Client zugängig
#machen zu können
server.register_function(add)
14
15
16
17
18
#Erstellen einer Klasse mit Funktion
class MyFuncs:
def div(self, x, y):
return x // y
19
20
21
22
#Registrieren der gesamten Klasse MyFuncs um diese für den Client zugängig
#zu machen
server.register_instance(MyFuncs())
Listing 5.8: RPC Client
1
import xmlrpclib
2
3
4
5
#Erstellen des XMLRPC Server Proxy Objekts, welches auf den passenden
#Server verweist
s = xmlrpclib.ServerProxy('http://localhost:8000')
6
7
8
9
#Aufrufen der registrierten Server-seitigen Funktionen
print s.add(2,3) #Gibt 5 zurück
print s.div(5,2) #Gibt 5//2 = 2
5. Technologien
67
10
11
12
#Gibt die Liste der verfügbaren Methoden aus
print s.system.listMethods()
XMLRPC in dieser Form verwendet xml zur Enkodierung und http zum
Transport der Daten. Da mittels http übertragen wird, wird TCP als grundlegendes Protkoll verwendet [20]. Obwohl in Kapitel 1 UDP als das vorteilhaftere Protokoll zur Übertragung bei IPTV erwähnt wird, ist die Verwendung von TCP bei dieser praktischen Arbeit problemlos zu vertreten, da
jene Daten, welche gesendet werden, nicht in dem Ausmaß zeitsensibel sind,
wie Audio- und Videoinhalte von Fernsehkanälen. Somit wird eine minimale Verzögerung bei der Übertragung der Daten vom Benutzer meist nicht
erkannt.
Wie schon in Listing 5.8 ersichtlich, wird Pythons xmlrpclib nur Clientseitig verwendet, um auf registrierte Funktionen des Servers zugreifen zu
können. Eines der wichtigsten Elemente hinsichtlich der möglichen Benutzung von XMLRPC beim Client, ist die Instanz des ServerProxy Objektes,
welche sich hauptsächlich um die Kommunikation mit dem XMLRPC Server
kümmert [16]. Server-seitig ist zur Verwendung von XMLRPC der Import
der SimpleXMLRPCServer Bibliothek obligat. Diese stellt ein einfaches Server
System für XMLRPC Server dar [16]. Die Bibliothek selbst verfügt über eine Klasse SimpleXMLRPCServer, welche – siehe Listing 5.7 – über Methoden
zur Registrierung von Funktionen oder Klassen verfügt, die vom XMLRPC
Protokoll aufgerufen werden können [16].
Die praktische Arbeit verwendet hinsichtlich der Netzwerkprogrammierung jene XMLRPC Funktionen für Python, da diese vor allem den Vorteil
der einfachen Umsetzung mit sich bringen, zumal die Netzwerkprogrammierung hauptsächlich von der Bibliothek selbst übernommen wird. Durch die
Verwendung von XMLRPC konzentriert sich die Entwicklung des Projektes
auf den Hauptteil – die Erstellung des Dreambox Plug-Ins.
Kapitel 6
Implementierung
Dieses Kapitel beschäftigt sich mit dem konkreten Projekt bzw. Plug-In,
dessen Entwurf und Technologien in den vorangegangenen Abschnitten besprochen wurden. Hier wird ein Einblick in die Implementierung hinsichtlich
Plug-In, Netzwerk und GUI gegeben.
6.1
Das Plug-In
Dieser Abschnitt gibt eine Übersicht über die aus Kapitel 4 tatsächlich realisierten Funktionen und den endgültigen Aufbau des Dreambox Plug-Ins.
Die Aufteilung der einzelnen Funktionalitäten in drei unterschiedliche
Screens, wie in Abschnitt 4.3.3 beschrieben, wurde beibehalten. Deshalb wird
nun zuerst auf die einzelnen Zuständigkeiten der verschiedenen Plug-In Module und danach auf deren Interaktion untereinander eingegangen.
6.1.1
Läuferinfo Modus
Dieser stellt das Standardfenster (siehe Abbildung 6.1) der Applikation dar,
welches nach dem Starten und Anmelden (mehr dazu später) sofort die Informationen des favorisierten Läufers angezeigt. Jene Informationen bestehen,
wie teilweise in Abschnitt 4.3.1 erwähnt, aus folgenden Inhalten:
Abbildung 6.1: Läuferinfo Modus.
68
6. Implementierung
69
• Name des Läufers
• Startnummer des Läufers
• Information ob jener Läufer der FL ist
• Gelaufene Kilometer
• Aktuelle Laufzeit
• Aktuelle Platzierung
• Startgruppe
• Gruppenplatzierung
• Durchschnittliche Laufgeschwindigkeit
Zusätzlich befinden sich rechts neben diesen Informationen drei Schaltflächen in blau, gelb und grün, welche für verschiedene Funktionen zuständig
sind.
Blaue Schaltfläche: Diese zeigt dem Benutzer an, falls er die blaue Taste
auf seiner Fernbedienung drückt, so wechselt er von diesem Modus in
den Standort Modus (siehe Abschnitt 6.1.3).
Gelbe Schaltfläche: Drückt der Benutzer nun die gelbe Taste auf seiner
Fernbedienung, so werden entweder die Daten des angezeigten favorisierten Läufers aktualisiert oder – falls der favorisierte Läufer zur Zeit
nicht angezeigt wird – die Informationen seines FL geladen.
Grüne Schaltfläche: Beim Drücken der grünen Taste wechselt die Anwendung vom Läuferinfo Modus in den Listen Modus (siehe Abschnitt
6.1.2).
Dieses Modul wurde – sowie auch die anderen zwei Module –, wie in
Abschnitt 5.2 beschrieben, als von Screen abgeleitete Klasse SNSInfobar1
umgesetzt. Neben Screen als Superklasse besitzt SNSInfobar eine zusätzliche Superklasse – InfoBarShowHide2 – welche es ermöglicht, den Screen
automatisch sowie auch manuell ein- und auszublenden. Listing 6.1 zeigt
den elementaren Aufbau der SNSInfobar-Klasse.
1
2
Sports Notification System (SNS) Infobar
Pfad /usr/lib/enigma2/python/Screens/InfoBarGenerics.py
6. Implementierung
1
2
3
70
Listing 6.1: SNSInfobar.py
class SNSInfobar(Screen, InfoBarShowHide):
#Aufbau des Screens im xml Format
raw_skin = """ ... """
4
5
6
7
8
9
10
def __init__(self, session, clientID, runID = None):
Screen.__init__(self, session) #Initialisierung der Superklasse
InfoBarShowHide.__init__(self) #Initialisierung der Superklasse
...
#Anwenden des definierten Screen Aufbau
self.skin = applySkinVars(SNSInfobar.raw_skin,skindict)
Die GUI dieses Moduls besteht hauptsächlich aus Label-, ePixmap- und
Button-Elementen, wobei die beiden Letzteren zur Darstellung der drei Schaltflächen auf der rechten Seite gebraucht werden. Listing 6.2 und 6.4 zeigen
Beispiele aus dem xml-Code der Elemente mit dazugehörigem Python-Code
zur Initialisierung.
1
2
3
4
5
6
7
8
9
10
11
Listing 6.2: Label
...
#xml-Code eines Informationselementes
<widget name="kmInfoLabel" position="25,30" size="180,15"
valign="center" font="Regular;20" transparent="1"
foregroundColor="blue" shadowColor="black"
shadowOffset="-1,-1" zPosition="3" halign="left" />
<widget name="kmInfo" position="205,30" size="400,15"
valign="center" font="Regular;20" transparent="1"
foregroundColor="white" shadowColor="black"
shadowOffset="-1,-1" zPosition="3" halign="left" />
...
12
13
14
15
16
17
18
#Funktion welche die Labels mit Inhalten füllt
def setLabels(self):
...
self["kmInfoLabel"] = Label(_("gelaufene km"))
self["kmInfo"] = Label(self.getKMInfo())
...
19
20
21
22
23
24
25
#Funktion welche die Inhalte aus einer erstellten Informationsliste
#filtert und zurückgibt
def getKMInfo(self):
km = self.runnerInfoList[2]
return "%skm/42.195km" % (km)
...
Pro Informationselement existieren zwei xml-Widgets, wobei das Erste
die dargestellte Information für den Benutzer betitelt und das zweite Element die aus der Datenbank ausgelesene Information visualisiert. Diese Information ist in der SNSInfobar-Klasse in Form einer Liste (runnerInfoList)
6. Implementierung
71
verfügbar, welche ständig neu, durch einen Aufruf der entsprechenden ServerFunktion (per RPC – siehe Abschnitt 6.2) aktualisiert wird. Zur adäquaten
GUI-Aktualisierung wird der Inhalt des passenden Label, wie Listing 6.3
zeigt, verändert.
Listing 6.3: Label Aktualisierung
...
def updateLabels(self):
...
self["kmInfo"].setText(self.getKMInfo())
...
1
2
3
4
5
Listing 6.4: Button
...
#xml-Code einer Schaltfläche
<widget name="yellowKey" position="450,40" size="140,40"
transparent="1"
zPosition="3" valign="center" halign="center"
foregroundColor="white" shadowColor="black" shadowOffset=
"-1,-1"
font="Regular;20" />
<ePixmap name="yellow" position="450,40" size="140,40"
transparent="1"
zPosition="2" pixmap="skin_default/buttons/yellow.png"
alphatest="on" />
...
...
#Initialisieren der Schaltfläche
self["yellowKey"] = Button(_("My Runner"))
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Für jede Schaltfläche gibt es zwei verschiedene Arten von xml-Elementen,
einerseits ein widget, welches als Button initialisiert und mit einem Titel
versehen wird. Andererseits besteht die Schaltfläche aus einer ePixmap, welche den Hintergrund des Buttons definiert. In diesem Fall wird eine Portable
Networks Graphics (PNG) 3 -Datei angegeben, welche auf der Dreambox standardmäßig zur Verfügung steht.
Um nun die Funktionen der einzelnen Schaltflächen definieren zu können,
werden in einer speziellen xml-Datei die für jenen Modus aktiven Tasten der
Fernbedienung als ActionMap (siehe Abschnitt 5.2) definiert. Listing 6.5 zeigt
als Beispiel die Definition der ActionMap des Läuferinfo-Moduls.
3
http://www.libpng.org/pub/png/
6. Implementierung
72
Listing 6.5: Auszug aus keymap.xml
1
2
3
4
5
6
7
8
9
10
11
12
<keymap>
...
<map context = "SNSInfobarActions">
<key id="KEY_OK" mapto="ok" flags="m" />
<key id="KEY_BLUE" mapto="googleMaps" flags="m" />
<key id="KEY_EXIT" mapto="exit" flags="m" />
<key id="KEY_RED" mapto="updateInfo" flags="m" />
<key id="KEY_GREEN" mapto="searchRunner" flags="m" />
<key id="KEY_YELLOW" mapto="getFavRunner" flags="m" />
</map>
...
</keymap>
Innerhalb des <keymap>-Elements können mehrere ActionMaps mittels
<map> definiert werden. Das context Attribut bezeichnet jene ActionMap.
Durch das Hinzufügen von <key>-Elementen können einzelne Tasten der
Fernbedienung per passender id Angabe ausgewählt und speziell bezeichnet
werden (mapto Attribut). Listing 6.6 zeigt, wie die vordefinierten ActionMaps
in einer Screen-Klasse Verwendung finden.
1
2
3
4
5
6
7
8
9
10
11
12
Listing 6.6: Verwendung der ActionMap
...
self["actions"] = ActionMap(["SNSInfobarActions"],
{
"ok": self.keyOK,
#ok key
"googleMaps": self.getMap,
#blue key
"updateInfo": self.updateLabels,
#red key
"searchRunner": self.getRunnerList, #green key
"getFavRunner": self.getFavRunner, #yellow key
"exit": self.exit
#exit key
}, -1)
...
Hier wird definiert, welche Funktion beim Drücken der vom Benutzer
gewählten Taste ausgeführt wird.
Neben dem Darstellen von Läufer-spezifischen Informationen, birgt dieses Modul auch eine Ein- und Ausblend-Funktion in sich. Wie schon zuvor
erwähnt, hat die Klasse SNSInfobar auch InfoBarShowHide als Superklasse,
welche diese Funktionalität zur Verfügung stellt. Die Eigenschaft des Ausblendens wird automatisch nach 5000 Millisekunden (ms) ausgeführt, falls
die Infobar eingeblendet war. Mit der Taste OK hat der Benutzer selbst die
Möglichkeit, das Ein- und Ausblenden manuell zu vollziehen. Zusätzlich zu
dieser Funktion wurde eine weitere implementiert, welche die GUI automatisch einblendet (falls diese ausgeblendet ist), wenn die Daten des Läufers
aktualisiert worden sind. Listing 6.7 zeigt die praktische Umsetzung dieser
6. Implementierung
73
Eigenschaft, welche alle 10000ms überprüft, ob neue Daten in der Datenbank
abgespeichert wurden.
Listing 6.7: Automatisches Einblenden bei aktuellen Daten
1
2
3
4
5
6
7
8
9
10
from enigma import eTimer
...
...
#Timer zum Überprüfen der Aktualität der Datenbank
self.checkDataTimer = eTimer()
#Funktion welche beim Ablauf des Timers aufgerufen wird
self.checkDataTimer.callback.append(self.checkData)
#Funktion welche beim Beenden des Konstruktors aufgerufen wird
self.onLayoutFinish.append(self.onLayoutFinished)
11
12
13
14
def onLayoutFinished(self):
#Start des Timers
self.checkDataTimer.start(10000,True)
15
16
17
18
19
20
21
#Funktion zum Überprüfen der Aktualität der Datenbank
def checkData(self):
self.checkDataTimer.stop()
...
#Aufruf der Server-Funktion bezüglich Aktualität der Daten
update = self.proxy.isUpdateNew(self.runID, True)
22
#Neue Daten
if update:
#Aktualisieren der Daten
self.updateLabels()
#Infobar anzeigen
self.showScreen()
#Timer neu starten
#Keine neuen Daten
else:
#Timer neu starten
self.checkDataTimer = eTimer()
self.checkDataTimer.callback.append(self.checkData)
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
...
Über die beschriebenen Funktionalitäten hinaus, hat der Benutzer noch die
Möglichkeit, die Applikation per EXIT -Taste zu beenden. Abbildung 6.2
gibt eine Übersicht der Tasten der Fernbedienung, welche in diesem Modus
genutzt werden und welche Funktionen sie übernehmen.
6. Implementierung
74
Abbildung 6.2: Funktionstasten im Läuferinfo-Modus.
Abbildung 6.3: Listen Modus.
6. Implementierung
6.1.2
75
Listen Modus
Dieser Modus zeigt dem Benutzer eine Liste aller Teilnehmer (siehe Abbildung 6.3), aus denen er einen wählen und dessen Informationen im LäuferinfoModus betrachten kann. Die Liste der Läufer wird nach deren aktuellen Positionierungen sortiert. Die Startnummern der Läufer stehen nach dem Namen,
weiters wird der vom Benutzer favorisierte Läufer speziell (mit einem „F“)
gekennzeichnet.
Dieser Modus wurde wiederum als eine eigene Klasse – SNSRunnerList
–, welche wiederum von der Screen Klasse erbt, umgesetzt. Der xml-Aufbau
dieses Fensters ist sehr simpel, wie Listing 6.8 zeigt, besteht er lediglich aus
einem widget-Element, welches als MenuList() initialisiert wird.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Listing 6.8: XML Screen Aufbau Läuferliste
class SNSRunnerList(Screen):
raw_skin = """
<screen position ="{screen.pos}" size ="{screen. size }"
title ="Available List of Runners">
<widget name="runners"
position ="{runners.pos}"
size ="{runners.size}"
scrollbarMode ="showOnDemand" />
</screen>
"""
...
def __init__(self, session, favRunnerName):
...
self.skin = applySkinVars(SNSRunnerList.raw_skin,skindict)
...
self["runners"] = MenuList([])
...
Das MenuList Element ist, wie schon Label und Button in Abschnitt
6.1.1, unter /usr/lib/enigma2/python/Plugins/Components zu finden. Dieses Objekt ermöglicht es, eine Liste von Einträgen darzustellen und diese mit
den Navigationspfeilen auf der Fernbedienung durchsuchen zu können. Listing 6.9 zeigt, wie die Liste in diesem Fall mit Werten befüllt wird.
Listing 6.9: Befüllen der MenuList
1
2
3
4
5
6
7
8
9
...
def getRunnersList(self):
list = []
...
#Aufrufen der Server-Funktion welche eine Liste aller Teilnehmer
#mit deren Startnummer und Position zurückgibt
runners = self.proxy.getAllRunnerNames()
...
6. Implementierung
76
#Iterieren der empfangenen Liste
#Formatieren der Werte
#Speichern der Werte in eine neue Liste
for row in runners:
if row[0] == self.favRunnerName:
#spezielles Kennzeichnen des favorisierten Läufers
list.append("%s. (F) %s #%s" %(row[1],row[0],row[2]))
else:
list.append("%s. %s #%s" %(row[1],row[0],row[2]))
...
#MenuList mit Werten füllen
self["runners"].setList(list)
...
10
11
12
13
14
15
16
17
18
19
20
21
22
MenuList verfügt über einige Funktionen, welche es zB ermöglichen, den
aktuell ausgewählten Eintrag oder den Index des aktuellen Eintrages (siehe
Listing 6.10) zu erhalten.
Listing 6.10: MenuList Abfrage des ausgewählten Eintrages
#Abfrage des ausgewählten Elements
runner = self["runners"].getCurrent()
#Abfrage des Index des ausgewählten Elements
idx = self["runners"].getSelectedIndex()
1
2
3
4
Diese Funktionen finden Verwendung, falls der Benutzer per OK einen
Läufer auswählt und dessen Informationen sehen will.
Der Listen-Modus bietet dem Benutzer lediglich die Möglichkeit, durch
die Liste zu navigieren und einen Läufer per Druck auf die OK -Taste auszuwählen, um danach zum Läuferinfo-Modus zu wechseln, welcher die ausgewählten Informationen anzeigt. Zusätzlich gibt es die Option, diesen Modus ohne Auswahl eines Teilnehmers zu verlassen. Dies geschieht mit der
EXIT -Taste, bei deren Druck der Listen-Modus beendet wird, um in den
Läuferinfo-Modus zurückzukehren. Abbildung 6.4 illustriert die verwendbaren Tasten und deren Funktion.
6.1.3
Standort Modus
Der Standort-Modus ist (siehe Abbildung 6.5), im Gegensatz zum ListenModus etwas komplexer im Aufbau. Hier wird die Google Maps-API 4 verwendet, um den aktuellen Standort des Läufers anzuzeigen. Die Umsetzung
dieser Funktionaltiät wurde in Anlehnung an das bereits bestehende Dreambox Plug-In5 von Rico Schulte entwickelt. Die Umsetzung jenes Moduls
umfasst mehrere Klassen:
4
5
http://code.google.com/intl/de-DE/apis/maps/
http://www.i-have-a-dreambox.com/wbb2/thread.php?threadid=96626
6. Implementierung
77
Abbildung 6.4: Funktionstasten im Listen-Modus.
GlobalMercator
Berechnet aus den vorhandenen Koordinaten, bestehend aus Längengrad
(longitude - lon) und Breitengrad (latitude - lat), die passenden Werte für
ein GoogleMaps-Tile, welches am Bildschirm mittels Google Maps darstellbar
ist. Zur Berechnung wird eine Mercator-Projektion6 verwendet, welche die
von Google Maps verwendete Kartenprojektion ist. Im Zusammenhang mit
dem Projekt finden vor allem folgende Funktionen Verwendung:
LatLonToMeters(self, lat, lon ): Diese Funktion konvertiert WSG84 7 konforme Breiten- und Längengrade in XY Koordinaten mittels sphärischer Mercator-Projektion.
MetersToTile(self, mx, my, zoom): Konvertiert Mercator-Koordinaten
in Tile Map Service (TMS)-konforme Daten, welche einer Region eines
Tiles entsprechen. Der Parameter zoom bestimmt die Höhe (altitude
- alt) bzw. den Zoom-Faktor mit dem der Benutzer den Standort betrachtet.
6
7
http://mathworld.wolfram.com/MercatorProjection.html
http://geoportal.bafg.de/karte/help/de/WebHelp/whgdata/whlstg0.htm
6. Implementierung
78
Abbildung 6.5: Standort Modus.
GoogleTile(self, tx, ty, zoom): Hier werden TMS-Tiles in Google-Tiles
konvertiert, da sich die beiden durch einen differierenden Ursprung unterscheiden und TMS-Tiles von Google Maps falsch dargestellt werden
würden.
Diese Klasse ist Teil der globalmaptiles.py Datei, welche von Klokan
Petr Pridal entwickelt und zur Verfügung gestellt wurde.
WebPixmap
Diese Klasse kümmert sich um das Laden und Darstellen der passenden Bilder, welche den Daten der Google-Tiles entsprechen. Hier wird die Verbindung zum Google Maps Server hergestellt und die passenden Daten heruntergeladen. Diese Klasse wurde von Rico Schulte entwickelt und zur Verfügung
gestellt.
MapPlace
Hier werden die aus der GlobalMercator-Klasse beschriebenen Funktionen
auf die passenden Daten aus der Datenbank angewendet. Der Konstruktor
dieser Klasse nimmt WDG84 -konforme Werte (Längen- und Breitengrad)
entgegen. Weiters besitzt diese Klasse die Funktion getTile(self, alt),
welche die Konvertierung der Werte vornimmt und drei Werte – googleX
6. Implementierung
79
(entspricht dem Längengrad), googleY (entspricht dem Breitengrad) und
alt (entspricht der Höhe bzw. dem Zoom-Faktor) – retourniert.
Diese Klasse wurde in Anlehnung an die KmlPlace-Klasse von Rico Schule
entwickelt.
SNSGoogleMaps
Diese Klasse stellt die von Screen abgeleitete Klasse dar. Auch hier wird per
xml die GUI implementiert, welche aus neun WebPixmap Elementen besteht,
die die darstellbaren neun Google-Tiles repräsentieren. Listing 6.11 zeigt ein
Beispielelement des xml-Codes und dessen Initialisierung.
Listing 6.11: XML-Aufbau & Initialisierung
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
...
class SNSGoogleMaps(Screen,HelpableScreen):
raw_skin = """
<screen position ="{screen. position }" size ="{screen. size }" title ="
GoogleMaps">
#Eines von neun Widgets
#Die Variablen pixmap1.pos & pixmap.size werden in der __init__
definiert
#bevor der Screen initialisiert wird
<widget name="pic1" position="{pixmap1.pos}" size="{pixmap.size
}" zPosition="1" alphatest="blend"/>
...
</screen>"""
...
def __init__(self, session, position):
...
#Laden eines Default-Bildes bevor die Bilder aus
#Google Maps geladen werden
self["pic1"] = WebPixmap(default=plugin_path+not_found_pic)
...
#Laden der Bilder passend zu den definierten Koordinaten
self.setNewXYZ(self.x, self.y, self.z)
...
21
22
23
24
def setNewXYZ(self,x,y,z):
#Lädt das passende Google-Tile
self["pic1"].load(getURL(x-1,y-1,z))
Um nun die passende Position des Läufers anzeigen zu können, wird dem
Konstruktor die Variable position übergeben, welche Längen- und Breitengrad des Teilnehmers beinhaltet, der in der Datenbank aufgrund der GPRS Daten des Läufers abgespeichert wurde. Aufgrund dieser Variablen werden
mit Hilfe der Funktionen der Klasse MapPlace sowie GlobalMercator die
passenden Werte, welche ganzzahlig sind, zur Anzeige der Google-Tiles berechnet. Der dafür notwenige Zoom-Faktor wird beim erstmaligen Anzeigen
6. Implementierung
80
des Läuferstandortes mit 17 definiert. Anschließend hat der Benutzer die
Möglichkeit, diesen Wert zu verändern. Listing 6.12 zeigt den Aufruf der
Funktion von MapPlace.
1
2
3
4
5
6
Listing 6.12: Erhalt der Variablen x y z
#position[0][0] := Längengrad
#position[0][1] := Breitengrad
self.place = MapPlace(position[0][0], position[0][1])
#Berechnung der Google-Tiles-Werte
#x := longitude, y := latitude, z := altitude
self.x, self.y, self.z = self.place.getTile(17)
Nachdem die passenden Werte für Längen- und Breitengrad sowie der Höhe berechnet wurden, wird mittels der load-Funktion der WebPixmap Klasse,
sowie der getURL-Funktion das passende Google-Tile geladen. Listing 6.13
zeigt die getURL-Funktion, welche die berechneten Werte in den passenden
URL zum Erhalt des adäquaten Satellitenbildes einfügt.
Listing 6.13: getURL()
1
2
def getURL(x,y,z):
return "http://khm1.google.com/kh/v=43&hl=de&x=%i&y=%i&z=%i" %(
x,y,z)
Nachteilig an dieser Vorgehensweise zum Erhalt des Satellitenbildes ist
nur, dass Google diesen url von Zeit zu Zeit ändert und er somit aktualisiert
werden muss. Außer dem Satellitenbild ist es natürlich auch möglich, eine
Kartenansicht zu erhalten, welche mittels "http://mt1.google.com/mt?v=w
2.92&hl=en&x=%i&y=%i&z=%i&s=G" %(x,y,z) geladen werden kann.
Da sich die Standortanzeige aus neun Google-Tiles zusammensetzt, werden die Werte x, y und z dementsprechend angepasst. Jenes WebPixmap,
welches sich in der Mitte befindet, zeigt die genauen Werte. Alle anderen
werden, wie Abbildung 6.6 zeigt, angepasst.
Der Benutzer hat bei diesem Modul verschiedene Möglichkeiten der Interaktion hinsichtlich des betrachtbaren Bildausschnittes. Abbildung 6.7 zeigt
die in diesem Modus aktiven Tasten der Fernbedienung und deren Funktionen. Der Betrachter hat somit die Möglichkeit, sich mittels der Zifferntasten herumzubewegen bzw. den Bildausschnitt in eine Richtung zu bewegen.
Weiters zeigt die Abbildung, dass er mittels der Tasten 5 und 0 den Vergrößerungsfaktor – d. h. den Z -Wert – verändern kann. Je größer dieser Wert,
umso genauer ist der Bildausschnitt, d. h. ein Wert von 0 würde die gesamte
Karte der Erde zeigen. Hinsichtlich des Vergrößerungsfaktors kann es, abhängig vom Bild welches Google liefert, zu Darstellungsproblemen kommen.
Beispielsweise könnte ein zu kleiner Vergrößerungwert nicht darstellbar sein.
Der Benutzer kann, wie Abbildung 6.7 zeigt, in jegliche Himmelsrichtungen navigieren.
6. Implementierung
Abbildung 6.6: Anpassung der X, Y und Z Werte hinsichtlich der GoogleTiles Anordnung.
Abbildung 6.7: Funktionstasten im Standort-Modus.
81
6. Implementierung
82
• Nordwest (NW)
• Nord (N)
• Nordost (NO)
• West (W)
• Ost (O)
• Südwest (SW)
• Süd (S)
• Südost (SO)
Die Umsetzung des Navigierens im dargestellten Bild, erfolgt durch Anpassung des X - bzw. Y -Wertes (zB nach Südwest X -= 1 und Y += 1). Geschieht dies oder wird der Vergrößerungsfaktor Z vom Benutzer verändert, so
wird das gesamte Bild aktualisiert und die Funktion setNewXYZ(self,x,y,z)
(siehe Listing 6.11) wird mit den entsprechend veränderten Werten aufgerufen.
Auch in diesem Modus hat der Benutzer, wie Abbildung 6.7 illustriert,
die Möglichkeit per Klick auf den EXIT Knopf diesen Modus zu verlassen
und in den Läuferinfo-Modus zurückzukehren.
6.1.4
Interaktion zwischen den Modi
Dieser Abschnitt gibt einen Überblick über die Interaktion bzw. das Zusammenspiel der einzelnen Modi. Kapitel 4 stellte schon den Entwurf einer solchen Interaktion dar, die finale Implementierung weicht jedoch vom
Entwurfsmodell aus Abbildung 4.4 ab. Das endgültige Zusammenspiel der
einzelnen Screens wird in Abbildung 6.8 dargestellt.
Die Benutzersicht
Anfänglich war geplant, alle drei Module gleichwertig zu gestalten, im finalen und umgesetzten Modell ist dies nicht der Fall. Das Läuferinfo-Modul
spielt eine zentrale Rolle, da dieses die Hauptinformationsquelle des Benutzers darstellen soll. Das Plug-In soll vor allem dem Seher als Informationsplattform hinsichtlich der Läuferdaten des FL zur Verfügung stehen.
Standort- und Listen-Modul spielen eine nebensächliche Rolle und sollen die
Applikation hinsichtlich ihrer Funktionalitäten abrunden. Die zentrale Rolle des Läuferinfo-Modus hat zur Folge, dass nur aus diesem das Programm
verlassen werden kann, ausschließlich hier dient die EXIT -Taste dem Beenden der Applikation. Die beiden anderen Modi werden per Klick auf die
EXIT -Taste beendet, dennoch kehrt der Benutzer in den Läuferinfo-Modus
6. Implementierung
83
Abbildung 6.8: Zusammenspiel der einzelnen Programmmodi.
zurück. Startet der Benutzer das Programm, so befindet er sich, nachdem
er sich mit der ihm zugewiesenen ClientID angemeldet hat, zu Beginn im
Läuferinfo-Modus, welcher ihm die Daten seines favorisierten Läufers (FL)
anzeigt.
Die Anmeldung mittels ClientID ist ein zusätzliches kleines Modul, welches hinzugefügt wurde. Der Grund einer solchen Anmeldung liegt an der
Tatsache, dass der Benutzer einen Läufer favorisieren kann. Damit dies möglich wird, ist eine vorhergehende Registrierung des Benutzers nötig, bei der
er seinen FL angibt und im Gegenzug eine Identifikationsnummer erhält,
welche zum Start des Plug-Ins obligat ist. Ein Registrierungssystem wird
derzeit bei der Informationsüberlieferung per Handy eingesetzt und könnte
hinsichtlich dieses Systems adaptiert und verwendet werden. Zu Testzwecken
wurden jene ClientIDs manuell generiert und verwendet.
Befindet sich der Benutzer zu Beginn im Läuferinfo-Modus, so kann er
durch Druck auf die grüne oder blaue Taste (wie in Abschnitt 6.1.1 erläutert)
in den Listen- bzw. Standort-Modus wechseln.
Bei Wechsel in das Listen-Modul wird jenem der Name des FL übergeben, damit dieser in der Liste speziell gekennzeichnet werden kann. Im
Modul selbst existieren mehrere Möglichkeiten, um zum Läuferinfo-Modus
zurückzukehren. Einerseits durch die bereits erwähnte EXIT -Taste, welche
6. Implementierung
84
diesen Modus lediglich beendet, andererseits durch die Auswahl eines Läufers bei Bestätigung mit der OK -Taste. Zweiteres Szenario wählt den Läufer
aus und übergibt der Klasse SNSInfobar dessen runID.
Wird anstatt des Listen-Moduls das Standort-Modul gewählt, so wird
jenem die Position (Längen- und Breitengrad) des Läufers übergeben, dessen
Information aktuell angezeigt wird. Dieser Modus kann nur durch Druck auf
die EXIT -Taste beendet werden. Bei Rückkehr in den Läuferinfo-Modus
werden dem Benutzer wiederum die Information seines FL angezeigt.
Die Entwicklersicht
Um nun das oben erwähnte Zusammenspiel zwischen den Modi zu ermöglichen, wurde eine spezielle Klasse erstellt, welche sich um das Steuern und
Verwalten der Daten und Screens kümmert. Die Klasse SNSManager wurde
in der Datei plugin.py implementiert, ein Objekt wird in der main-Funktion
initialisiert. Listing 6.14 zeigt den Aufruf der „Startfunktion“ des SNSManager
Objektes in der main-Funktion.
1
2
3
4
5
6
7
8
9
10
Listing 6.14: Initialisierung und Aufruf des SNSManagers
def main(session, **kwargs):
try:
#Erstellung des SNSManager Objektes
#Übergabe des session Parameter
snsManager = SNSManager(session)
except Exception, e:
session.open(MessageBox, _("Error:\n%s" % e), MessageBox.
TYPE_ERROR, 5)
else:
#Aufruf der „Startfunktion“
snsManager.showNumberInputbox()
Primär wird die Klasse SNSManager gebraucht, um nach dem Schließen
eines Screens die übergebenen Variablen entgegen zu nehmen, den darauf
folgenden Screen aufzurufen und die entsprechenden Variablen an jenen weiterzuleiten. D. h. wird ein Modus beendet, so kehrt der Fokus der Applikation
zunächst zum SNSManager zurück, um von da ausgehend weiterzuhandeln.
Grundsätzlich ist der Aufbau eines Plug-Ins so, dass ein Screen geschlossen
werden muss, bevor ein anderer geöffnet werden kann. Der Entwickler hat
jedoch die Möglichkeit Variablen beim Schließen zu übergeben, damit danach der Grund des Schließens abgefragt werden kann. So gibt es zB im Fall
des Läuferinfo-Moduls mehrere Ursachen warum dieser Screen geschlossen
wurde.
• Beenden des Plug-ins
• Wechsel zu Standort-Modus
6. Implementierung
85
• Wechsel zu Listen-Modus
Listing 6.15 zeigt den Befehl, mit dem vom Läuferinfo-Modus in den
Listen-Modus gewechselt wird, wobei zusätzlich Variablen übergeben werden.
Listing 6.15: Schließen eines Screens
1
2
3
4
5
6
7
8
9
10
def getRunnerList(self):
list = []
#Information über den Grund des Schließens
list.append("RUNNERS")
#Anhängen weiterer Informationen welche beim
#Öffnen des Listen-Modus gebraucht werden
if self.isFavoriteRunner:
list.append(self.runnerInfoList[0])
else:
list.append("NOT_FAV")
11
12
13
#Schließen des Modus inklusive Übergabe der Variablen
Screen.close(self, list)
Die übergebene Liste wird in jener Funktion des SNSManagers entgegengenommen, welche als Callback -Funktion (siehe Listing 5.2) beim Öffnen
des Läuferinfo-Screens definiert wurde. Listing 6.16 zeigt die entsprechende
Funktion, welche beim Schließen des Läuferinfo-Modus aufgerufen werden
würde.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Listing 6.16: Callback-Funktion des Läuferinfo-Modus
def infoBarClosed(self, msg):
#Falls der Screen nicht aufgrund der EXIT-Taste geschlossen wurde
if msg is not None:
#Wechsel in den Listen-Modus
if msg[0] is "RUNNERS":
#Angezeigter Läufer war FL
if msg[1] is not "NOT_FAV":
self.favoriteRunnerName = msg[1];
#Öffenen des Listen-Modus & Übergabe der entsprechenden Variable
self.session.openWithCallback(self.runnerListClosed,
SNSRunnerList, self.favoriteRunnerName)
#Wechsel in den Standort-Modus
elif msg[0] == "GOOGLE":
#Öffnen des Standort-Modus & Übergabe der Position
self.session.openWithCallback(self.googleMapsClosed,
SNSGoogleMaps, msg[1])
#Schließen aufgrund eines Fehlers
elif msg[0] == "ERROR":
self.showMsgBox('Server is currently not available!')
6. Implementierung
86
Die unterschiedlichen Übergabeparameter beim Schließen eines Screens
ermöglichen es zwischen den verschiedenen Gründen zu unterscheiden und
dementsprechend zu handeln. Wird die gesamte Applikation beendet, so wird
kein Parameter übergeben und in Folge dessen kein anderer Modus aufgerufen.
Zusätzlich ist noch zu erwähnen, dass in der Klasse SNSManager Werte
wie clientID und favoriteRunnerName gespeichert werden, um bei Bedarf
darauf zugreifen zu können.
6.2
Server und Datenübertragung
Dieser Abschnitt gibt einen Einblick in die Umsetzung des Servers zur Datenübertragung. Wie in Kapitel 5 bereits erläutert, wurde die Netzwerkprogrammierung als Remote Procedure Call (RPC) umgesetzt. Genauer gesagt
handelt es sich dabei um Pythons xmlrpclib, welche in Abschnitt 5.3 detailierter beschrieben wurde.
Server-seitig existieren zwei Klassen, welche essentiell für die adäquate
Übertragung der nötigen Informationen sind.
Database: Diese Klasse kümmert sich um die Kommunikation zwischen
Datenbank und Server. Sie liest die nötigen Daten aus und bereitet sie
auf. Zusätzlich wird Database per RPC registriert, um ihre Funktionen
für den Client verfügbar zu machen. Abschnitt 6.2.1 geht näher auf die
Funktionen dieser Klasse und die Datenübertragung zwischen Client
und Server ein.
RPC_Server: Jene Klasse übernimmt die eigentliche RPC Server Funktion, welche aus dem Initialisieren des Servers, dem Ein- und Ausschalten
des Servers, sowie dem Registrieren der Klasse besteht. Abschnitt 6.2.2
gibt einen Einblick in die Umsetzung dieser Funktionen.
6.2.1
Klasse Database
Eine der Hauptfunktionen dieser Klasse besteht darin, die nötigen Informationen aus der Datenbank auszulesen und optimal für den Client aufzubereiten. Zu Beginn ist hier zu erwähnen, dass zur Zeit der Implementierung kein
Zugriff auf aktuelle Daten der Originaldatenbank möglich war. Zu Testzwecken wurde eine Testdatenbank erstellt, welche sich in einzelnen Punkten von
der Originaldatenbank unterscheidet, jedoch die Wesentlichsten Inhalte enthält. Aufgrund dieser Tatsache wurde die Klasse Database hinsichtlich der
Testdatenbank entwickelt und müsste für die Originaldatenbank adaptiert
und angepasst werden.
6. Implementierung
87
Zum Auslesen der Daten aus der MySQL Datenbank wurde die MySQLdb 8 Schnittstelle für Python verwendet. Listing 6.17 zeigt das Verbinden
zur Datenbank sowie das Auslesen von Daten aus der Datenbank.
Listing 6.17: Daten aus MySQL Datenbank auslesen
...
def __init__(self):
#Verbinden zur Datenbank
self.__conn = MySQLdb.connect(self.__host, self.__user, self.
__passwd, self.__db, self.__port)
...
#Erstellt einen „cursor“
def createCursor(self):
self.__cursor = self.__conn.cursor()
1
2
3
4
5
6
7
8
9
#Schließt „cursor“
def closeCursor(self):
self.__cursor.close()
...
#Gibt die runID des FL des Client zurück
def getFavRunnerID(self, clientID):
self.createCursor()
...
self.__conn.commit()
self.__cursor.execute('SELECT runID FROM clients WHERE
client_id = %s' % (clientID))
row = self.__cursor.fetchall()
10
11
12
13
14
15
16
17
18
19
20
21
for entry, in row:
runID = entry
22
23
24
self.closeCursor()
return runID
...
25
26
27
Das in Listing 6.17 erstellte cursor Objekt ist zum Ausführen von Abfragen obligat. Um sich zur Datenbank verbinden zu können, werden die
nötigen Parameter, welche Listing 6.17 bei MySQLdb.connect() ersichtlich
macht, mit den nötigen Informationen initialisiert.
Annähernd alle Funktionen dieser Klasse führen Datenbankabfragen aus
und bereiten die erhaltenen Informationen dementsprechend auf. Einige jener Funktionen werden mittels RPC vom Client aufgerufen. Um dies zu
ermöglichen, wird in den Klassen auf der Client Seite Pythons xmlrpclib
Bibliothek importiert und verwendet. Listing 6.18 zeigt die Schritte, welche
nötig sind um eine Server-seitige Funktion aufzurufen.
8
http://mysql-python.sourceforge.net/MySQLdb.html
6. Implementierung
1
2
3
4
5
6
7
8
9
10
11
12
88
Listing 6.18: RPC Client
class SNSInfobar(Screen, InfoBarShowHide):
...
...
#Stellt das Verbindungsobjekt zum Server her
self.proxy = xmlrpclib.ServerProxy('http://10.0.0.1:3000')
...
def getRunnerInfoList(self):
...
#Ruft die Funktion getRunnerInfo() der Klasse Database auf
self.runnerInfoList = self.proxy.getRunnerInfo(self.runID)
...
Listing 6.18 ist ein Beispiel aus der SNSInfobar Klasse, bei der vom Server eine Liste, in der jegliche Information eines Läufers enthalten ist, zurückgibt. Neben dieser Funktion gibt es weitere, welche vom Client aufgerufen
werden. Abbildung 6.9 gibt einen Überblick über jene Funktionen.
Diese sechs Funktionen übertragen verschiedenste Daten:
isUpdateNew: Überprüft, ob die Information, welche dem Benutzer angezeigt werden, noch aktuell sind oder nicht. Sie gibt true oder false
zurück. So wurde die Funktionalität des automatischen Einblendens
realisiert. D. h. der Client ruft immer wieder diese Funktion auf und
reagiert bei der Rückgabe von true dementsprechend.
getFavRunnerID: Gibt die Identifikationsnummer des FL zurück. Diese
Funktion wird aufgerufen, wenn das Plug-In startet und der Benutzer
soeben seine ClientID eingegeben hat.
getRunnerInfo: Liest aus der Datenbank die entsprechenden Läuferinformationen aus und gibt diese als Liste dem Client zurück, damit sie
angezeigt werden können.
getRunnerIDbyName: Sucht die Nummer des Läufers zum angegebenen
Namen. Diese wird verwendet, wenn ein Läufer aus der Liste ausgewählt wurde und in den Läuferinfo-Modus zurückgekehrt wird.
getAllRunnerNames: Diese Funktion liest die Namen aller Teilnehmer
aus der Datenbank aus und übergibt sie dem Client, damit im ListenModus die Läuferliste aufgebaut und angezeigt werden kann.
checkClientID: Überprüft die vom Benutzer eingegebene ClientID auf ihre Gültigkeit und gibt entweder true oder false zurück.
Diese Auszüge aus Database sind die grundsätzlich wichtigsten und spielen bei der Kommunikation zwischen Server und Client, als auch zwischen
Applikation und Datenbank, eine essentielle Rolle.
6. Implementierung
89
Abbildung 6.9: Die von den Client Klassen aufgerufenen Server Funktionen.
6.2.2
Klasse RPC_Server
Die Klasse RPC_Server ist lediglich dazu da, den gesamten RPC ServerAufbau gesamtheitlich zu präsentieren und zu verwalten. Die Implementierung des RPC Servers wurde gänzlich wie in Abschnitt 5.3 umgesetzt. Das
Erstellen des SimpleXMLRPCServer Objekts wird in der __init__ Funktion
der Klasse vorgenommen. Zusätzlich gibt es zwei weitere Funktionen:
connect(): Diese Funktion kümmert sich mittels serve_forever() um Anfragen bis der Serverprozess beendet wird [16].
disconnect(): Bei Aufruf dieser Funktion beendet der Server mit Hilfe von
server_close() die Verbindung nach außen.
6. Implementierung
90
Abbildung 6.10: Anmeldefenster zur Eingabe der ClientID des Benutzers.
Zusätzlich ist noch zu erwähnen, dass zur Zeit der Entwicklung keine Marathonläufe stattfanden und somit die Serverfunktion in einer lokalen Netzwerkumgebung getestet wurde. Um die Applikation zum Einsatz zu bringen,
muss Client-seitig die Host-Adresse des Servers angepasst bzw. richtig gestellt werden.
6.3
Benutzeroberfläche
Dieser Abschnitt befasst sich mit dem finalen Aufbau der Benutzeroberfläche.
Die technische Umsetzung der GUI wurde in Abschnitt 6.1 sowie in Kapitel 5
bereits erläutert, darum setzt sich dieser Teil der Arbeit mit dem Endergebnis
und dessen Überlegungen hinsichtlich des Benutzers auseinander.
In Abschnitt 4.3.3 wurde das Konzept hinsichtlich Gestaltung und Positionierung der Benutzeroberfläche erläutert und illustriert. Der Aufbau, den
Abbildung 4.2 darstellt, wurde grundsätzlich übernommen und umgesetzt,
d. h. der Screen des Läuferinfo-Modus befindet sich am unteren Rand des
Bildschirms und lässt sich per Knopfdruck einfach ein- und ausblenden, bzw.
geschieht diese Funktion automatisch. Die Screens der anderen zwei Module
befinden sich zentriert in der Bildschirmmitte. Der Grund dafür liegt daran,
dass der Läuferinfo-Modus als Hauptmodus der Applikation fungiert. Die
zusätzlichen Modi dienen als Erweiterung bzw. zusätzliche Information für
jene Benutzer, welche sich im Besonderen für einen Läufer bzw. für die Applikation interessieren. Weiters wird beim Listen- sowie beim Standort-Modus
die aktive Interaktion und Konzentration des Benutzers verlangt, dies soll
für diesen durch die zentrale Positionierung einen erleichternden und unterstützenden Effekt zur Folge haben.
Neben den hier schon erwähnten Modulen wurde ein weiteres, simples
6. Implementierung
91
Zwischenmodul umgesetzt, welches lediglich zum Anmelden des Benutzers
dient. Auch dieses wurde am unteren Bildschirmrand positioniert, um das
Fernsehvergüngen des Benutzers so wenig wie möglich zu beeinflussen. Abbildung 6.10 zeigt den Aufbau und die Positionierung des neuen Moduls.
Neben dem Aufbau der Benutzeroberfläche wurde auch hinsichtlich der
Bedienung per Fernsteuerung auf eine einfache und intuitive Auswahl der
Tasten geachtet, zB das Bestätigen eines Eintrages per OK oder das Schließen eines Fensters bzw. der Applikation per EXIT. Der einzige negative
Punkt der Steuerung ist, dass der Benutzer nicht die Option hat, während des
Plug-In Betriebes den Fernsehkanal zu wechseln, d. h. die Applikation muss
bei einem Programmwechsel zuvor beendet und kann danach wieder gestartet werden. Abschließend gibt Abbildung 6.11 einen Überblick hinsichtlich
der finalen Positionierung und des Aufbaus der verschiedenen Module.
6. Implementierung
92
(a)
(b)
(c)
Abbildung 6.11: Die drei Module Läuferinfo (a), Liste (b) und Standort
(c) und ihr endgültiger Aufbau sowie die finale Positionierung.
Teil III
Zusammenfassung
93
Kapitel 7
Resümee und Ausblick
7.1
Resümee
Diese Arbeit versucht einen Einblick in die aktuelle Welt des IPTV zu geben.
Aufgrund des aktuellen Standes der Technik auf diesem Gebiet wurden Möglichkeiten gezeigt, wie die Vorteile von IPTV genutzt und in die derzeitige
Fernsehlandschaft eingebunden werden können. Zusätzlich werden Optionen
aufgezeigt, die dem Benutzer durch diese Technik geboten werden bzw. geboten werden könnten.
Durch die praktische Arbeit soll vor allem dargestellt werden, wie in
diesem Fall Echtzeitdaten, generell aber jegliche Fremdinhalte – ob aus dem
Web oder aus Datenbanken – sanft integriert werden können, damit sich
der Benutzer nicht gestört fühlt. Mithilfe der, in dieser Arbeit aufgezeigten
Möglichkeiten, kann die Fernsehlandschaft auf eine Weise verändert werden,
die von den Sehern auch angenommen und verwendet wird.
IPTV und vor allem die Verbindung von Internet- und Fernsehinhalten ist
zukunftsweisend und bietet eine für den Benutzer bequeme Errungenschaft,
welche es ihm erlaubt, zwei häufig genutzte Medienquellen zu verbinden und
gemeinsam zu verwenden. Durch eine solche Verschmelzung ist es möglich,
die Vorteile beider Medien zu vereinen, einerseits die Passivität des Fernsehens, welche für den Benutzer nicht verloren gehen darf und andererseits die
Aktivität, sowie auch Aktualität des Internets, welche dem Benutzer die von
ihm gewünschten Informationen auf „Knopfdruck“ liefert.
Das Sports Notification System stellt eine mögliche Art der Personalisierung eines IPTV Systems dar und soll zeigen, wie spezifisch der Seher sich
in Zukunft seine Inhalte auswählen und zusammenstellen kann. Durch die
Möglichkeit solcher Plug-Ins, oder auch Widgets (wie sie von Yahoo geboten werden), müssen Informationen nicht mehr auf eine größere Gruppe von
Sehern zugeschnitten werden. Der einzelne Benutzer kann somit selbst für
seine Inhalte verantwortlich sein, muss es aber nicht, d. h. er kann weiterhin
die Passivität des Fernsehens genießen. Dennoch ist es wichtig, diese Mög-
94
7. Resümee und Ausblick
95
lichkeit anzubieten, vor allem da die jetzige Technik eine solche Entwicklung
erlaubt und fördert.
Neben den derzeit möglichen technischen Entwicklungen zeigt die Arbeit
ebenso mögliche Zukunftsvisionen auf, welche vor allem auf die Verschmelzung von Internet und Fernsehen, sowie die hochgradige Personalisierung der
Inhalte abzielen. Derzeit ist die Grenze zwischen Fernsehen und anderen Inhalten noch definitiv spürbar, doch schon in Zukunft könnte der Benutzer die
Integration jener Inhalte für selbstverständlich ansehen und die Einbindung
nicht mehr bemerken. So wird der Seher, falls er Informationen über einen
soeben gesehenen Schauspieler erhalten möchte, in Zukunft nicht mehr via
Computer ins Internet einsteigen. Das Zukunftsfernsehen liefert ihm diese
Informationen automatisch. Zusätzlich wird es vielleicht auch möglich sein,
mit einem Freund über einen Film zu sprechen, ohne ihn anzurufen, sondern
die gewünschte Person kann kontaktiert werden.
Die Entwicklung auf diesem Sektor ist erst in der Anfangsphase, doch
durch die in dieser Arbeit aufgezeigten Möglichkeiten der Personalisierung,
der Datenintegration und der Verschmelzung der Medien, wird die Zukunft
bald zur Gegenwart werden.
7.2
Ausblick
Die praktische Arbeit kann hinsichtlich der Zukunftsvisionen aus Abschnitt
7.1 erweitert und verbessert werden. Falls der Benutzer auch die Übertragung
des Marathons im Fernsehen ansieht, besteht die Option einer Analyse bzw.
Verarbeitung des Fernsehbildes, um somit zB Informationen über den am
Bildschirm sichtbaren Läufer anzuzeigen. Zusätzlich ist die Standortanzeige
mittels Google Maps bei Weitem nicht perfekt. Hier gäbe es die Möglichkeit,
die exakte Position des Läufers mit einem Icon anzuzeigen. Weiters wäre es
interessant, zwischen den Stationen die Position zu interpolieren. Dies könnte
mittels der bereits vorhandenen Daten geschehen, d. h. wo wäre der Läufer,
würde er mit der berechnenten Durchschnittsgeschwindigkeit der Strecke folgen. Auch der Informationsumfang könnte um Prognosen über die mögliche
Ankunftszeit, eine mögliche Platzierung oder die Gesamtlaufzeit erweitert
werden.
Zusätzlich müsste der Quellcode der Applikation im Live-Betrieb angepasst werden, da die Programmtests nur auf einem Testserver und mit einer
Testdatenbank durchgeführt wurden.
Um nun einen Schritt weiter zu gehen, könnte dem Benutzer die Option gegeben werden, zB auf die persönliche Website des Läufers zu zugreifen
oder dessen bisherige Platzierungen bei Läufen anzuzeigen. Aufgrund der
Datenmenge, auf die mittels IP zugegriffen werden kann, sind der Fantasie
hier keine Grenzen gesetzt. Jedoch sollte der Benutzer, als auch die Sinnhaftigkeit der angezeigten Daten nie außer Acht gelassen werden. D. h. bei
7. Resümee und Ausblick
96
einer Weiterentwicklung der Applikation sollten umfangreiche Benutzertests
durchgeführt werden, welche einerseits Auskunft über die Nützlichkeit der
gegebenen Informationen, sowie über die Benutzerfreundlichkeit des Plug-Ins
geben. Vor allem auf die sanfte Einbindung in das Fernsehbild sollte bei einer
Weiterentwicklung geachtet und durch Benutzertests verbessert werden.
Anhang A
Inhalt der CD-ROM
File System: Joliet
Mode:
A.1
Single Session
Diplomarbeit
Pfad: /
dm07010_diplomarbeit.pdf Diplomarbeit
A.2
Zusätzliche Ressourcen
Pfad: /
Abbildungen/ . . .
LaTeX/ . . . . . .
Literatur/ . . . . .
Literatur/Online/ .
Projekt/ . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
In der Arbeit verwendete Abbildungen
TEX-Dateien
Online-Dokumente (PDF-Dateien)
Duplizierte Web-Seiten der Online-Quellen
Projekt-Dateien
97
[1] Fehlstart, 2001.
http://www.test.de/themen/computer-telefon/test/Webboxen/19306/19306/.
[2] Al-Khatib, M. und M. S. Alam: IPTV Multimedia Networks: Concepts,
Developments, and Design.
International Engineering Consortium,
2007.
[3] Broszeit, J.: IPTV und Interaktives Fernsehen. VDM Verlag Dr. Müller,
2007.
[4] Chorianopoulos, K. und D. Spinellis: Coping with tivo: Opportunities of
the networked digital video recorder. ScienceDirect, S. 11, Dez. 2005.
[5] DREAMmultimedia: Dreambox DM 800 HD PVR Manual.
[6] Harte, L.: IPTV Basics. Althos, 2007.
[7] Held, G.: Understanding IPTV. Auerbach, 2007.
[8] Holtkamp, H.: Einführung in TCP/IP, Juni 1997. http://www.rvs.unibielefeld.de/~heiko/tcpip/tcpip.pdf.
[9] Klocker, K. H.: Telefongespräch bezüglich aonTV. Persönl. Telefon Kontakt, Sep. 2009.
[10] McLuhan, M.: Understanding Media: The Extensions of Man.
MIT Press, 1994.
The
[11] Mutavdzic, S.: E-Mail Verkehr bezüglich aonTV. Persönl. E-Mail Kontakt, Juli 2009. Kopie auf CD-ROM.
[12] Noam, E. M.: Cyber-TV: Thesen zur dritten Fernsehrevolution. Verlag
Bertelsmann Stiftung, 1996.
[13] Ocilion IPTV Technologies GmbH: Handbook Part 1 - Getting Started,
Jan. 2008.
[14] O’Driscoll, G.: Next Generation IPTV Services and Technologies. Wiley
& Sons, 2008.
98
99
[15] Redl, B.: IPTV - neu gewonnene Möglichkeiten der Interaktivität und
Personalisierung des Fernsehens. Diplomarbeit, FH St. Pölten, 2007.
[16] Rossum, G. van: The Python Library Reference. Python Software Foundation, Aug. 2009.
[17] Schönbach, K.: Das hyperaktive Publikum - noch immer eine Illusion:
Ein Essay, "revisited. In: Salm, C. zu (Hrsg.): Zaubermaschine interaktives Fernsehen? TV-Zukunft zwischen Blütenträumen und Businessmodellen, S. 113 – 120. Gabler, Okt. 2004.
[18] Stanek, D.: Internet-Fernsehen boomt, Juni 2009. http://www.bitkom.
org/files/documents/BITKOM-Presseinfo_IPTV_17_06_2009.pdf.
[19] Stevens, W. R.: TCP/IP Illustrated, Bd. 1. Addison-Wesley, 1994.
[20] Stevens, W. R., B. Fenner und A. M. Rudoff: UNIX Network Programming – The Sockets Networking API, Bd. 1. Addison-Wesley, 3. Aufl.,
2004.
[21] Yahoo: Konfabulator 4.5 Reference Manual. Nov. 2007.
[22] Ziemer, A.: Digitales Fernsehen - Eine neue Dimension der Medienvielfalt. Hüthig GmbH, 2. Aufl., 1997.
[23] Zimmermann, H.: OSI Reference Model, Apr. 1980. http://www.comsoc.
org/livepubs/50_journals/pdf/RightsManagement_eid=136833.pdf.
Messbox zur Druckkontrolle
— Druckgröße kontrollieren! —
Breite = 100 mm
Höhe = 50 mm
— Diese Seite nach dem Druck entfernen! —
100

Einsatz von IPTV zur Übertragung und Darstellung von Echtzeitdaten

Transcrição

Documentos relacionados

PDF #15 - Heldart

Einschaltung 1 im HoTele

CeBIT 2007 2. ausg. s01.qxp - Die

Poster

Crestron Makro zur Steuerung von Dream Multimedia Sat Receivern

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

Tendenz 3/2006

Heiß oder kalt? - Rheinlands Reiter+Pferde

AGB herunterladen als PDF-Datei