Technischer Bericht Bachelor Thesis

Transcription

Media-Streaming
in Hotels
Technischer Bericht
Bachelor Thesis
Joël Dubois, Fabrice Thut
Studiengang Informatik, 6. Semester
Betreuer:
Prof. Dr. Christoph Stamm
MSc. Matthias Krebs
Auftraggeber:
hotelplus GmbH
Alain Schwaller (GL/Administration)
Biagio Aeberhard (Technik & Beratung)
Windisch, 14. August 2015
Studiengang Informatik
Zusammenfassung
Das Ziel dieser Projektarbeit ist eine Mediastreaming-Lösung für Hotelbetriebe zu entwickeln. Damit soll ein Gast
den Hotel-Fernseher in seinem Zimmer über eine Webapplikation kontrollieren und Filme vom hoteleigenen Server
mieten und abspielen können. Sowohl eine Software-Architektur als auch ein Sicherheitskonzept wurden in der
ersten Projektphase erarbeitet. Für die anschliessende Umsetzung wurden Java und das Applikationsframework
Spring eingesetzt. Benutzerinteraktion wird durch eine REST-Schnittstelle ermöglicht. Das Steuern der Fernseher
erfolgt über Universal Plug and Play (UPnP), einer Technologie, die einfache Peer-to-Peer-Kommunikation über
ein Netzwerk ermöglicht. Die Webapplikation wurde in eine bestehende CMS-Lösung als eigenes Modul integriert.
Die Interaktion aller Komponenten funktioniert anforderungserfüllend. Sowohl das Starten, Pausieren und Stoppen,
als auch das Vor- oder Zurückspulen eines Streams, funktionieren erwartungsgemäss. Die Performance wird durch
die vorhandene Netzwerkleitung und die Hardware-Ressourcen des Servers limitiert.
Inhaltsverzeichnis
Zusammenfassung ........................................................................................................................ 1
1
Einleitung.............................................................................................................................. 1
2
Theorie ................................................................................................................................. 2
2.1
Universal Plug and Play (UPnP) ............................................................................................... 2
2.2
UPnP Audio/Video (AV) ........................................................................................................... 6
2.3
DLNA ...................................................................................................................................... 10
3
Konzept .............................................................................................................................. 12
3.1
Infrastruktur-Anforderungen................................................................................................. 12
3.2
Use-Cases .............................................................................................................................. 12
3.3
Aufbau ................................................................................................................................... 13
3.4
Mögliche Lösungsansätze für direktes Streamen .................................................................. 14
3.5
Definitives Lösungskonzept ................................................................................................... 18
4
Streaming-System ............................................................................................................... 35
4.1
CMS-Server ............................................................................................................................ 35
4.2
Streaming-Server ................................................................................................................... 37
4.3
Media Renderer ..................................................................................................................... 45
5
Testkonzept ........................................................................................................................ 47
5.1
Unit-Tests .............................................................................................................................. 47
5.2
Integrationstests ................................................................................................................... 47
6
Ausblick .............................................................................................................................. 48
6.1
Netzwerk und CMS überarbeiten .......................................................................................... 48
7
Bekannte Fehler .................................................................................................................. 49
8
Fazit .................................................................................................................................... 50
9
Abkürzungsverzeichnis ........................................................................................................ 51
10
Ehrlichkeitserklärung ....................................................................................................... 52
11
Literaturverzeichnis ......................................................................................................... 53
12
Anhang ........................................................................................................................... 55
12.1
REST-API Beschreibung .......................................................................................................... 55
12.2
Device Description Document ............................................................................................... 62
12.3
Abnahmetests........................................................................................................................ 64
12.4
Mailverkehr mit Herrn Dr. Dominik Gruntz über Probleme mit Cling Library ....................... 68
12.5
Mailverkehr mit Samsung-Support ....................................................................................... 72
1
Einleitung
Diese Arbeit befasst sich mit Media-Streaming in Hotelbetrieben. Im Auftrag der Firma hotelplus
GmbH wird ein zugeschnittenes Produkt konzipiert und umgesetzt.
Hotelplus installiert WLAN- und Multimedia-Infrastrukturen in Hotels unter Berücksichtigung aktueller
Anforderungen wie Benutzerauthentifizierung, Client Isolation und Bandbreitenkontrolle. Eine bestehende Webapplikation ermöglicht den Gästen Informationen über das Hotel und die Region abzurufen, sowie Essensbestellungen zu tätigen.
Immer häufiger steht auch ein Smart-TV in jedem Hotelzimmer. Dieser bietet den Gästen ein grossflächiges Display zur Wiedergabe unterschiedlichster Medien. Eine beliebte Funktion ist das Mieten und
Abspielen von Filmen aus der Videothek des Hotels. Für diese Funktion existieren bereits einige
Lösungen. Das aktuell eingesetzte Produkt bezieht hotelplus über einen Drittanbieter. Es umfasst eine
Serverapplikation, die zentral auf einem internen Server gehostet wird und eine Clientapplikation, die
jeweils auf den Smart-TVs installiert werden muss. Da die Fernseherapplikation geräteabhängig ist,
müssen Offerten für neue Installationen immer den aktuell unterstützten Fernsehern angepasst werden. Wenn die TV-Hersteller neue Modelle herausgeben, so muss gewartet werden, bis der Drittanbieter eine Aktualisierung der Clientapplikation zur Verfügung stellt.
Das Ziel dieser Projektarbeit ist ein Konzept für das Mediastreaming im Kontext von Hotels zu erarbeiten und umzusetzen. Der Benutzer soll die Möglichkeit haben, über eine Webapplikation mit seinem
persönlichen Gerät (Computer, Tablet oder Smartphone), den Fernseher im Zimmer zu kontrollieren.
Grundsätzlich müssen zwei Anwendungsfälle abgedeckt sein. Einerseits soll ein Gast aus einem
Angebot von Filmen einen mieten und abspielen können. Andererseits muss er auch in der Lage sein,
seine eigenen Medien von seinem Endgerät auf dem Fernseher wiederzugeben. Die korrekte Funktion der Webapplikation kann über manuelle Tests sichergestellt werden. Das robuste Streamen der
Daten soll über eine Test-Applikation automatisiert geprüft werden.
Als Streaming-Technologie wird Universal Plug and Play Audio Video (UPnP AV) eingesetzt. Benutzerfreundlichkeit und Robustheit haben hohe Priorität. Auch den Aspekten Pausieren, Wiederaufnehmen und Wechsel von Medien soll besondere Beachtung geschenkt werden. Die neuen Funktionalitäten werden in die bestehende Webapplikation integriert. Ein besonderes Augenmerk muss auf die
lose Koppelung von Soft- und Hardware gelegt werden. Auch darf keine Middleware, wie beispielsweise eine Settop-Box, benötigt werden.
In Kapitel 2 dieser Arbeit werden theoretische Aspekte zu UPnP und dem darauf aufbauenden DLNA
behandelt. Danach folgen in Kapitel 3 konzeptionelle Überlegungen zum Ablauf der Anwendungsfälle.
Auch Sicherheitsaspekte sind Teil der Konzeptphase. In Kapitel 0 wird die Software-Architektur erklärt. Dabei wird vom grossen Gesamtbild aus Schritt für Schritt auf die wichtigen Details eingegangen. Zum Schluss wird das Testkonzept erläutert und ein Ausblick für mögliche Erweiterungen gegeben.
Seite 1
2
Theorie
2.1
Universal Plug and Play (UPnP)
Die UPnP-Technologie definiert eine Architektur, um möglichst einfach intelligente Geräte in einem
Netzwerk miteinander zu verbinden (Peer-to-Peer). Die einzigen Anforderungen an ein Netzwerkgerät
sind, dass es mit einem Netzwerk verbunden ist, eine gültige IP-Adresse besitzt und UPnP unterstützt.
Für die Netzwerkkonnektivität können sämtliche Transportmedien (Ethernet, WLAN, etc.), die IPbasierte Kommunikation unterstützen, eingesetzt werden [1]. Die IP-Adresse kann entweder statisch
konfiguriert sein, über DHCP bezogen oder, wenn die ersten beiden Methoden nicht funktionieren,
automatisch generiert werden. In letzterem Fall handelt es sich um eine Link-Local-Address aus der
IP-Range 169.254.0.0/16. Dieses Feature ist nativ aber nur in Windows und Mac OS X implementiert.
[2]
UPnP kennt zwei Gerätetypen: Devices und Control Points. Ein Device bietet Schnittstellen um sich
steuern zu lassen. Ein Control Point kann Devices im Netzwerk suchen und steuern.
Damit über UPnP kommuniziert werden kann, sind keine Gerätetreiber notwendig. Anstelle von Treibern werden bekannte Netzwerkprotokolle wie IP, TCP, UDP, HTTP und SOAP verwendet. UPnP ist
weder an ein Betriebssystem, noch an eine Programmiersprache gebunden, lediglich die Spezifikationen für die Datenübertragung muss exakt eingehalten werden.
2.1.1
Sicherheit
Zero-Configuration ist ein Hauptmerkmal von UPnP. Damit dieses Feature auch ohne Probleme
funktioniert, ist eine Authentifizierung oder Autorisierung der Geräte untereinander weder vorgesehen,
noch in irgendeiner Art implementiert. Jeder Control Point im Netzwerk kann also auf ein UPnPDevice zugreifen und dessen Funktionen abfragen und nutzen. [3]
2.1.2
Geschichte
UPnP wurde ursprünglich von Microsoft entwickelt und bereits in Windows ME eingeführt. Am 18.
Oktober 1999 wurde das Universal Plug and Play Forum gegründet. Es ist eine Vereinigung von
mittlerweile über 1000 Herstellern aus den Bereichen Unterhaltungselektronik, Computer, Home
Automation und Haushaltsgeräten. Die Arbeit des Universal Plug and Play Forum ist das Definieren
von Spezifikationen. [4]
Die Website www.upnp.org ist das zentrale Repository für XML-Schemas und Spezifikationen. Auch
Informationen über Aktivitäten und Fortschritte des Forums werden publiziert.
Die UPnP Device Architecture liegt aktuell in Version 2 vor. Die Spezifikation wurde am 20. Februar
2015 zuletzt revidiert. [5]
2.1.3
Einsatzgebiet von UPnP
UPnP hat zwei Haupteinsatzzwecke. Einerseits im Bereich Netzwerkkonnektivität, andererseits beim
Verteilen von Multimediainhalten über das Netzwerk.
In ersterem geht es darum, Geräte einfach miteinander über das Internet zu verbinden. Dafür spezifiziert UPnP ein Internet Gateway Device (IGD) [6]. Dieses schliesst ein Local Area Network (LAN) an
das Wide Area Network (WAN) an. Es kann von anderen Geräten konfiguriert werden. Beispielsweise
können Portweiterleitungen eingerichtet werden, ohne dass der Benutzer etwas davon sieht. Dies ist
auf der einen Seite sehr benutzerfreundlich, auf der anderen Seite aber auch eine Sicherheitslücke,
da sich Drittpersonen Zugriff auf das gesamte LAN verschaffen können [7].
Der zweite Teil, Verteilen von Medien über das Netzwerk, wird in Kapitel 2.2 detailliert erklärt.
Seite 2
2.1.4
Komponenten
Services
Services, im Sinne von UPnP, sind logische Gruppierungen von Funktionen (Actions) und Zustandsvariablen (State Variables). Zustandsvariablen haben einen definierten Datentyp und teilweise auch
definierte Werte, die sie annehmen können. [8] Ein Beispiel für einen Service wäre der Connection
Manager Service (CMS). Seine Aufgabe ist es UPnP-Geräte miteinander zu verbinden und wieder zu
trennen. Eine State Variable wäre ConnectionManager. Sie speichert den Identifier für den verbunden Connection Manager Service des Nachbarn. Ein Beispiel für eine Action ist
GetCurrentConnectionInfo(). Sie liefert einige Informationen über den Status der aktuellen Verbindung, unter anderem den Wert der State Variable ConnectionManager. [9]
Devices
Mit UPnP-Device ist nicht das physikalische Gerät gemeint, sondern eine softwarebasierte Umsetzung
der UPnP-Spezifikation. Ein UPnP-Device kann als Container angesehen werden, der wiederum
eingebettete Devices oder Services enthalten kann. Welche Funktionalität ein Device zur Verfügung
stellt, muss jeweils im Device Description Document (DDD) des Devices nachgelesen werden (Beispiel in Snippet 9). Snippet 1 zeigt die Tags, die die Funktionalitäten anzeigen.
…
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:serviceType:v</serviceType>
<serviceId>urn:upnp-org:serviceId:serviceID</serviceId>
<SCPDURL>URL to service description</SCPDURL>
<controlURL>URL for control</controlURL>
<eventSubURL>URL for eventing</eventSubURL>
</service>
</serviceList>
<deviceList>

</deviceList>
…
Snippet 1: serviceList und deviceList in DDD
Nebst der Serviceliste und der Deviceliste enthält das DDD auch allgemeine Information über das
Device (z.B. Herstellerinformationen, Modellnamen und eine Beschreibung). [8]
Control Points
Ein Control Point kann UPnP-Devices im Netzwerk finden und Actions auf den Devices ausführen.
Ausserdem kann er auf Events von Devices reagieren. Er hat selber aber keine Services implementiert.
2.1.5
UPnP Device Architecture
Die UPnP Device Architecture spezifiziert wie Devices und Control Points miteinander kommunizieren.
Abbildung 1 zeigt die verwendeten, allgemein bekannten Netzwerkprotokolle.
Dieses Kapitel orientiert sich an der offiziellen Spezifikation [10]. Wenn ein Gerät neu mit einem
UPnP-Netz verbunden wird, so durchläuft es folgende 6 Schritte:
Seite 3
Abbildung 1: Von UPnP verwendete Netzwerkprotokolle
Phase 0: Addressing
Damit ein UPnP-Gerät in ein UPnP-Netz aufgenommen werden kann, muss es eine valide IP-Adresse
besitzen. Diese kann es, wie erwähnt, statisch konfiguriert haben, dynamisch über DHCP beziehen
oder je nachdem automatisch generieren.
Phase 1: Discovery
Wenn das Device eine gültige IP hat, muss es seine Anwesenheit mittels einer Discovery Message
den Control Points melden. Dafür nutzt es das System Service Discovery Protocol (SSDP) über die
Multicastadresse 239.255.255.250 und den UDP-Port 1900.
Wenn ein Control Point neu ins Netz kommt, so sucht er ebenfalls mit SSDP nach aktiven Devices.
Snippet 2 zeigt die Discovery Message von einem Control Point. Die Devices antworten mit einer
Response wie in Snippet 3 dargestellt.
M-SEARCH * HTTP/1.1
ST: upnp:rootdevice
MX: 3
MAN: "ssdp:discover"
HOST: 239.255.255.250:1900
Snippet 2: Discovery Message von Control Point
HTTP/1.1 200 OK
Location: http://192.168.1.103:1371/
Cache-Control: max-age=1800
Server: UPnP/1.0 DLNADOC/1.50 Kodi
EXT:
BOOTID.UPNP.ORG: 0
CONFIGID.UPNP.ORG: 8165443
USN: uuid:11b12bb8-9d0a-2f44-1e7b-bfaf71b6cd0d::upnp:rootdevice
ST: upnp:rootdevice
Date: Thu, 01 Jan 1970 00:00:24 GMT
Snippet 3: Antwort von Device auf Discovery Message
Phase 2: Description
Zum jetzigen Zeitpunkt hat der Control Point, ausser den Informationen aus der Antwort in Snippet
3Date: Thu, 01 Jan 1970 00:00:24 GMT, keine weiteren Kenntnisse über das Device. Damit er dessen
Funktionalitäten nutzen kann, muss er wissen, welche Services das Device anbietet. Dafür setzt der
Control Point einen HTTP-GET-Request (Snippet 4) auf dem Device ab.
Seite 4
GET / HTTP/1.1
User-Agent: Java/1.8.0_45
Host: 192.168.1.103:1371
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Snippet 4: GET-Request für Device Description Document
Die Antwort ist ein DDD, ein XML-File, das nebst allgemeinen Informationen über das Device auch die
Liste mit verfügbaren Services enthält. Ein Beispiel ist im Snippet 9 im Anhang zu finden.
Phase 3: Control
Da der Control Point nun weiss, welche Services das Device anbietet, kann er Actions auf dem Device
aufrufen. Welche Actions aufgerufen werden können, hängt von den verfügbaren Services ab und
kann in der Servicebeschreibung nachgelesen werden. Für den Aufruf einer Action wird das Simple
Object Access Protocol (SOAP) genutzt.
Phase 4: Eventing
UPnP spezifiziert eine Architektur für einen Benachrichtigungsmechanismus. Ereignisse in UPnP sind
Änderungen von Zustandsvariablen in Services. Welche Zustandsvariablenänderungen gemeldet
werden können, muss in der jeweiligen Spezifikation des Services nachgelesen werden. Grundsätzlich kann sich ein Control Point bei einem Device anmelden (subscribe), um über Zustandsänderungen informiert zu werden und wieder abmelden (unsubscribe), wenn keine Benachrichtigungen mehr
erwünscht sind.
Für die Registrierung bei einem Device muss der Control Point diesem einen Request senden. Der
Request ist wie folgt aufgebaut (Abbildung 2):
Abbildung 2: UPnP Subscribe-Request [5]
Wenn das Device genügend Ressourcen frei hat, sollte es die Subscripition annehmen und eine
Antwort (Abbildung 3) zurück schicken. Die Subscription-ID (SID) wird vom Device generiert und muss
universell eindeutig sein.
Abbildung 3: UPnP Subscribe-Response [10]
Falls die Subscription nicht angenommen werden kann, muss ein Paket mit HTTP Status Code 400
(inkompatible Header-Felder), 412 (Voraussetzungen nicht erfüllt) oder ein 5xx (Aktualisierung nicht
akzeptiert) gesendet werden.
Wenn das Timeout abgelaufen ist, werden keine Notifikationen mehr gesendet. Um Benachrichtigungen über einen längeren Zeitraum zu erhalten, muss die Subscription erneuert werden, bevor das
Timeout abgelaufen ist. Hierfür sendet der Control Point einen Request gemäss Abbildung 4.
Seite 5
Abbildung 4: UPnP Subscription-Renewal-Request [10]
Wenn ein Control Point die Notifikationen nicht mehr erhalten möchte, muss er sich beim Device
abmelden, damit dieses die Ressourcen wieder freigeben kann. Dies macht der Control Point, indem
er einen Unsubscribe-Request absetzt (siehe Abbildung 5)
Abbildung 5: Unsubscribe-Request [10]
Das Device bestätigt mittels einer Antwort mit HTTP-Status-Code 200.
Phase 5: Presentation
Jedes Device hat eine Presentation-URL. Diese kann mit einem Browser aufgerufen werden. Je nach
Device und Implementierung werden auf dieser Seite lediglich Informationen angezeigt oder aber sie
erlaubt gewisse Actions aufzurufen.
2.2
UPnP Audio/Video (AV)
UPnP AV ist eine Erweiterung von UPnP. Das folgende Kapitel orientiert sich an der offiziellen Spezifikation von UPnP AV [11]. Sie definiert die Interaktionen zwischen Control Point und Device zur
Wiedergabe von Medieninhalten, wobei weder das Transportprotokoll, noch das Medienformat eingeschränkt werden. Im Prinzip gibt der Control Point einem Device lediglich Befehle, was es zu tun hat.
Der eigentliche Datenfluss (Stream) ist nicht Bestandteil von UPnP AV. Dieses typische InteraktionsModell ist in Abbildung 6 dargestellt.
Abbildung 6: Interaktions-Modell [11]
Explizit keine Berücksichtigung im Design von UPnP AV hat bidirektionale Kommunikation zwischen
zwei Devices (zum Beispiel Audio- oder Videokonferenz). [11]
Mit UPnP AV sind zwei neue Gerätetypen, der Media Server und der Media Renderer, und einige
Services eingeführt worden.
Ein Media Server stellt Daten im Netzwerk zur Verfügung. Daher sollte er je nach Anwendungsfall die
in der Tabelle 1 aufgelisteten Service implementiert haben.
Seite 6
Service
Beschreibung
Content Directory Service
Bietet eine Action Browse() an, welche einem Control Point die
verfügbaren Ressourcen auflistet.
Connection Manager Service
Die beiden Actions PrepareForConnection() und
ConnectionComplete() sind optional zu implementieren.
Wenn die beiden Actions implementiert sind, können mehrere
(virtuelle) Instanzen eines AV Transport Service unterschieden
werden. Wenn sie nicht implementiert sind, wird nur eine Instanz mit InstanceID=0 verwendet.
AV Transport Service
Ermöglicht dem Control Point den Datenfluss zu steuern. So
können Play(), Stop(), Pause() oder Seek()-Actions aufgerufen werden. Eine detaillierte Erklärung folgt im nächsten
Kapitel.
Tabelle 1: Services eines Media Servers.
Ein Media Renderer spielt Inhalte ab. Er hat neben den beiden Services Connection Manager und AV
Transport noch den Rendering Control Service implementiert (siehe Tabelle 2). Der Connection Manager Service ist jedoch um die Action GetProtocolInfo() erweitert. Diese ermöglicht einem
Control Point die unterstützten Formate und Transportprotokolle abzufragen.
Service
Beschreibung
Rendering Control Service
Stellt Actions zur Verfügung, um die Art der Wiedergabe zu
steuern. So kann die unter anderem die Helligkeit, der Kontrast
und die Lautstärke eingestellt werden.
Tabelle 2: Services eines Media Renderers.
AV Transport Service
Hierbei handelt es sich um eine Gruppe von Actions und Zustandsvariablen zur Steuerung einer
Wiedergabe. Die Zustandsvariable TransportState definiert, ob der Renderer gestoppt oder ob
gerade ein Stream aktiv ist. Je nach Zustand machen einige Actions Sinn und anderer nicht. Beispielsweise macht es keinen Sinn, Pause() aufzurufen, wenn das Device im Zustand STOPPED ist.
Zustandsmaschine
Die Spezifikation schreibt vor, welche Werte die Variable TransportState annehmen darf. Anhand
des aktuellen Zustands des Services und der Action, die darauf ausgeführt werden soll, kann bei
einem Übergang der neue Zustand vorausgesagt werden.
Seite 7
Abbildung 7: Zustandsdiagramm von AV Transport Service [12]
Abbildung 7 zeigt die minimale Zustandsmaschine mit ihren Übergängen. Jede Implementation muss
die Zustände STOPPED, PLAYING und TRANSITIONING unterstützen. Ebenfalls erforderlich sind PAUSED_PLAYBACK, PAUSED_RECORDING und RECORDING, wenn die jeweiligen Actions, um in diesen Zustand zu kommen, ebenfalls implementiert sind. Optional ist der Zustand NO_MEDIA_PRESENT. UPnP
erlaubt je nach Anwendungsfall das Erweitern dieses Diagramms durch zusätzliche Zustandsübergänge. Die Action GetCurrentTransportActions() retourniert eine kommaseparierte Liste mit allen
möglichen Actions, die das Gerät unterstützt. Ein Aufruf einer Action, die nicht in dieser Liste vorhanden ist, wird einen Fehler mit dem Code 701 (Transition nicht möglich) zur Folge haben. Daher sollte
beim Aufruf von erweiterten Actions immer geprüft werden, ob die Action auch tatsächlich existiert.
Actions
In der Tabelle 3 sind die, für dieses Projekt relevanten, Actions von AV Transport Service aufgelistet.
Grundsätzlich nimmt jede Action eine Instanz-ID (InstanceID) als Input-Parameter. Die vollständige
Liste aller Actions kann in der Spezifikation nachgelesen werden. [12]
Action
SetAVTransportURI()
Beschreibung
R
Setzt den Uniform Resource Identifier (URI) zu einer Mediendatei. Die Wiedergabe selbst ist nicht Teil dieser Action,
sondern würde über eine Play()-Action initiiert werden.
Input-Parameter sind die zu setzende URI CurrentURI und
allfällige Meta-Informationen zu dieser URI CurrentURIMetaData. Wobei CurrentURIMetaData auch ein Leerstring sein
darf, wenn das Feature nicht unterstützt oder benötigt wird.
GetMediaInfo()
R
Liefert verschiedene Informationen zur aktuellen Wiedergabe
auf einem Device.
Die Antwort des Devices auf diese Action beinhaltet insgesamt neun Argumente. Unter anderem die Dauer der aktuellen Wiedergabe (MediaDuration).
Seite 8
GetTransportInfo()
R
Retourniert Informationen zum aktuellen Transportstatus.
Rückgabe-Werte sind der aktuelle Transportzustand
CurrentTransportState, der TransportStatus
CurrentTransportStatus, sowie die aktuelle Abspielgeschwindigkeit CurrentSpeed. Mögliche Werte für den
TransportState sind in Abbildung 7 ersichtlich. Der Transport-Status kann die Werte OK, ERROR_OCCURRED oder eine
herstellerdefinierte Erweiterung annehmen.
GetPositionInfo()
R
Abfragen der Position der aktuellen Wiedergabe.
Insgesamt werden acht Argumente zurückgegeben. Eines
dieser acht ist RelTime, also die aktuelle Position im Format
„hh:mm:ss“.
Stop()
R
Versetzt das Device in den Transport-State STOPPED. Eine
laufende Wiedergabe wird gestoppt.
Play()
R
Starten der Wiedergabe auf einem Device. Falls keine Ressource spezifiziert ist, kann ein Fehler mit Error-Code 702
(Keine Medien verfügbar) zurückgegeben werden. Ansonsten
wird die Wiedergabe gestartet.
Nebst der Instanz-ID wird die Abspielgeschwindigkeit Speed
übergeben.
Pause()
O
Pausiert eine Wiedergabe. Wenn anschliessend wieder
Play() ausgeführt wird, so muss die Wiedergabe an exakt
derselben Stelle weiterlaufen, wie sie pausiert wurde. Diese
Action ist erlaubt, wenn der aktuelle Transportzustand
PLAYING ist. In allen anderen Transportzuständen kann ein
Fehler mit Error-Code 701 (Übergang nicht möglich) zurückgegeben werden.
Seek()
R
Ermöglicht das Fortsetzen einer Wiedergabe an einem beliebigen Zeitpunkt.
Input-Parameter sind nebst InstanceID eine Einheit Unit
und ein Ziel Target. Die Einheit ist notwendig, weil das Target in verschiedenen Formaten übergeben werden kann und
das Device wissen muss, wie die Zielposition interpretiert
werden soll.
Mögliche Einheiten sind unter anderem TRACK_NR, REL_COUNT
oder REL_TIME. Bei Letzterem wird das Target im Format
„hh:mm:ss“ übergeben, die ersten beiden nehmen eine positive Ganzzahl entgegen.
Diese Action ist möglich, wenn das Device STOPPED oder
PLAYING ist. Wenn sich das Gerät in einem anderen Transportzustand befindet, wird ein Fehler mit Error-Code 701
zurückgegeben.
Nach dem Start dieser Action wird der Variable
TransportState, während dem Suchen, der Wert
TRANSITIONING zugewiesen und anschliessend auf den
vorherigen zurückgesetzt.
Tabelle 3: Actions des AV Transport Service. R = REQUIRED, O = OPTIONAL
Eventing
Beim AV Transport Service wurde eine zusätzliche Zustandsvariable LastChange eingeführt. Dies ist
die einzige Variable, über dessen Änderungen Subscribers informiert werden.
Seite 9
Sie enthält Informationen über andere Zustandsvariablen in Form von Schlüssel-Wert-Paaren (siehe
Abbildung 8). Somit werden Änderungen in den anderen Zustandsvariablen indirekt über LastChange
notifiziert.
Änderungen in den Zustandsvariablen RelativeTimePosition, AbsoluteTimePosition, RelativeCounterPosition und AbsoluteCounterPosition werden nicht notifiziert. Wenn diese Informationen vom Control Point benötigt werden, beispielsweise um eine graphische Benutzeroberfläche
zu aktualisieren, muss der Wert der Variable in einem geeigneten Intervall beim Device abgefragt
werden.
<?xml version="1.0" encoding="UTF-8"?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<LastChange>
<Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/">
<InstanceID val="0">
<NumberOfTracks val="1" />
<CurrentTrack val="1" />
<CurrentTrackDuration val="02:07:10" />
<CurrentMediaDuration val="02:07:10" />
</InstanceID>
</Event>
</LastChange>
</e:property>
</e:propertyset>
Abbildung 8: Beispiel für LastChange-Event
2.3
DLNA
DLNA steht für Digital Living Network Alliance. Dabei handelt sich um eine Organisation mit mehr als
200 Mitgliedern, wobei es sich bei diesen Mitgliedern um namhafte Hersteller wie Samsung, Sony,
Panasonic oder Intel handelt. Gegründet wurde die Organisation im Jahre 2003 mit dem Ziel, mittels
verbindlichen Richtlinien, die Interoperabilität von Komponenten verschiedener Hersteller im Bereich
Multimedia über das Heim-Netzwerk zu gewährleisten.
Damit die Zusammenarbeit dieser Geräte auch garantiert ist, hat die Allianz ein Zertifikationsprogramm ins Leben gerufen. Jedes Produkt, das die Tests bestanden und das Zertifikat erhalten hat,
wird mit einem DLNA-Logo versehen. Somit sieht der Endkunde auf Anhieb, ob er ein neues Gerät
problemlos in sein vernetztes Heim integrieren kann. [13]
DLNA und UPnP
In der über 900-seitigen DLNA Richtlinie Teil 1-1 geht es um die Architektur und die Protokolle. Kapitel
4.3 beschreibt, dass UPnP für das Auffinden und Kontrollieren von Geräten im Netzwerk genutzt wird
und alle erwarteten Anforderungen erfüllt.
„Device discovery and control enables a device on the home network to discover the presence and
capabilities of other devices on the network and collaborate with these devices in a uniform and consistent manner. The UPnP Device Architecture, version 1.0 (ISO/IEC 29341-1:2011), addresses all of
these needs and simplifies device networking in the home. For this reason, UPnP Device Architecture
is the device discovery and control solution for DLNA devices. Subclause 7.2.5.5.27.6 specifies the
detailed guidelines to enable interoperability between DLNA devices in the digital home.“ [14]
Für die Verteilung von Medieninhalten im Netzwerk wird UPnP AV mit seinem Interaktionsmodell
verwendet.
UPnP AV selber hat keine Einschränkungen bezüglich Medienformaten. DLNA hingegen spezifiziert
sowohl eine Menge an Formaten für jede Kategorie (Video, Audio, Bilder), die als Mindestanforderung
verstanden werden müssen, als auch eine Menge von Formaten, die optional unterstützt werden
können.
Seite 10
Das heisst, grundsätzlich können UPnP-Geräte und DLNA-zertifizierte Geräte im selben Netz betrieben werden. Es gibt aber keine Garantie dafür, dass alle Medieninhalte untereinander geteilt werden
können. Wenn aber nur DLNA-zertifizierte Geräte eingesetzt werden, dann ist die Zusammenarbeit
durch eine gemeinsame Grundausstattung an unterstützten Formaten gewährleistet. [14]
DLNA-Komponenten
DLNA definiert ausserdem verschiedene Rollen für Komponenten, wobei eine Komponente je nach
Funktionalität eine oder zwei Rollen einnehmen kann (Tabelle 4).
UPnP Rolle
Beschreibung
Digital Media Server (DMS)
Stellt Medieninhalte im Netzwerk bereit.
Digital Media Player (DMP)
Kann im Netzwerk bereitgestellte Inhalte suchen
und abspielen.
Digital Media Renderer (DMR)
Wird von einem Controller kontrolliert und spielt
Medien ab.
Digital Media Controller (DMC)
Sucht einerseits im Netzwerk bereitgestellte
Inhalte. Andererseits sucht er im Netzwerk nach
vorhanden Renderer und weist anschliessend
einen Renderer an, eine Ressource wiederzugeben.
Tabelle 4: Komponenten von DLNA und Beschreibung der Rolle.
Seite 11
3
Konzept
3.1
Infrastruktur-Anforderungen
Im Folgenden wird die mögliche Anzahl paralleler Streams auf einer Gigabit-Leitung und einer Harddisk evaluiert. Angenommen wird, dass ein HD-Stream je nach Kodierung und Komprimierung eine
Bitrate zwischen 8 und 12 Mbit/s [15] benötigt, wobei vom Maximum ausgegangen wird.
Media-Streaming stellt besondere Anforderungen an die Netzwerkinfrastruktur. Normaler Netzwerkverkehr verläuft so, dass ein Benutzer eine Webseite aufruft, diese geladen wird und das Netz danach, während dem der Benutzer die Webseite liest, nicht weiter belastet wird. Media-Streaming
hingegen, belastet das Netz konstant, da ständig Daten nachgeladen werden. Ein Gigabit-Netzwerk
hat eine Bandbreite von 1000 Mbit/s. Das heisst, über eine solche Leitung gehen in etwa 83 parallele
Streams (1000 Mbit/s / 12 Mbit/s). Mit üblichen, netzwerktechnischen Massnahmen wie Erhöhung der
Bandbreite durch Einsetzen einer 10-Gibabit-Leitung oder Link Aggregation (Bündeln von mehreren
Leitungen zu einer logischen Leitung) können bessere Werte erzielt werden.
Bei der Harddisk ist vor allem die Lesegeschwindigkeit wichtig. Diese variiert je nach FestplattenModell stark [16]. Auch ist sie abhängig von der gewählten Blockgrösse. Für die Berechnung wird von
einer durchschnittlichen Lesegeschwindigkeit von 150 MB/s ausgegangen. 150 MB/s entsprechen
1200 Mbit/s. Das heisst, es können theoretisch 100 Streams gleichzeitig lesen. In der Praxis ist die
Anzahl Streams aber kleiner, weil andere Systemdienste ebenfalls die Festplatte benutzen. Eine
höhere Performance kann durch den Einsatz von RAIDs erzielt werden.
Zusammenfassend kann man festhalten, dass der erste limitierende Faktor das Netzwerk und der
zweite die Festplatte ist. Je nach Anzahl parallel erwarteter Streams müssen diese Parameter durch
geeignete Massnahmen angepasst werden.
3.2
Use-Cases
3.2.1
Video on Demand
Der Hotelgast kann aus einer Videothek, welche das Hotel zu Verfügung stellt, Filme mieten.
Ablauf:
1. Der Hotelgast ruft mit seinem mobilen Device eine definierte Seite auf, auf der alle Filme aufgelistet sind, die das Hotel für den „Video on Demand“-Service zur Verfügung stellt.
2. Der Hotelgast kann einzelne Filme zu einem definierten Preis mieten.
3. Der Hotelgast kann gemietete Filme abspielen, vor- und zurückspulen, pausieren und stoppen.
3.2.2
Streaming von eigenen Medien
Der Hotelgast kann eigene Inhalte, welche er auf seinem mobilen Device hat, auf dem im Zimmer
vorhandenen Smart-TV abspielen.
Seite 12
3.3
Aufbau
Abbildung 9: Schematischer Aufbau der verschiedenen, miteinander interagierenden Komponenten
Abbildung 9 zeigt die benötigten Komponenten um die definierten Use-Cases umzusetzen, wobei
Tabelle 5 die eigentliche Rolle der einzelnen Geräte im gesamt System erläutert. Tabelle 6 weist den
Komponenten die UPnP-spezifischen Rollen zu.
Komponente
Name
Beschreibung
PMS
Das PMS ist ein Hotelreservierungssystem. Es ermöglicht das
computergestützte Verwalten und Steuern eines Hotels [17].
Property Management System
Zusätzliche Dienstleistungen wie die Benutzung der Minibar,
des Zimmerservices oder auch dem Mieten von Filmen, werden im PMS erfasst und dem Hotelgast in Rechnung gestellt.
Damit die Mietgebühren verrechnet werden können, wird eine
bestehende Schnittstelle genutzt.
CMS
ContentManagementSystem
Ein CMS (Inhaltsverwaltungssystem) ist eine Software zur
gemeinschaftlichen Erstellung, Bearbeitung und Organisation
von Inhalten (Content) [18].
Das CMS ist die Benutzeroberfläche für die Filmverwaltung
seitens des Hotels. Das Hotel kann neue Filme hochladen und
Beschreibungen zu jedem Film erfassen.
Des Weiteren ist es der Zugang für den Hotelgast, der über die
Weboberfläche Filme mieten und abspielen oder auch seine
eigenen Dateien hochladen und wiedergeben kann.
Streaming-Server
Der Streaming-Server ist zuständig für die Bereitstellung der
Filme und die Verwaltung der Streams. Alle Filme, die das
Hotel anbietet, sind auf dem Streaming-Server abgelegt.
Die Hardware des Streaming-Servers muss sehr leistungsfähig
sein. Ansonsten ist nicht gewährleistet, dass der StreamingService auch ohne Einbussen funktioniert.
Smart-TV
Der Smart-TV spielt den angeforderten Inhalt ab. Damit dies
reibungslos funktioniert, muss der Smart-TV den UPnPStandard unterstützen.
Seite 13
Device
Das Device ist das mobile Endgerät (Computer, Tablet, Smartphone) des Gastes. Mittels diesem Gerät wird auf das CMS
zugegriffen und die Wiedergabe gesteuert.
Tabelle 5: Beschreibung der einzelnen Komponenten und deren Aufgabe im Gesamtsystem
Komponente
Name
UPnP Aufgabe
Smart-TV
Media Renderer
Streaming-Server
Control Point
Media Server
Tabelle 6: UPnP Rolle der Komponenten
Der Control Point sendet die eigentlichen Aktionen (Play(), Pause(), Stop()) an die Renderer. Der
Media Server stellt den Renderer die Multimediainhalte zur Verfügung. Der aktuelle Zustand der
Wiedergabe wird auf dem Device des Gastes visualisiert.
3.4
Mögliche Lösungsansätze für direktes Streamen
Um direkt vom mobilen Device auf den Smart-TV streamen zu können, muss eine entsprechende
Anwendung installiert sein. Bei Apple Produkten ist AirPlay standardmässig vorhanden. Andere Betriebssysteme können eine alternative Streaming-Applikation über den App-Store nachinstallieren.
3.4.1
Ansatz: Samsung Applikation und Soft-AP
Für Android-Geräte bietet Samsung eine App. Wenn der Soft Access Point des Smart-TVs aktiviert ist,
können, mittels dieser App, Medien auf dem Fernseher wiedergegeben werden. Da es sich aber um
eine proprietäre Applikation handelt, wurde dieser Ansatz verworfen.
3.4.2
Ansatz: Smart-TV und mobiles Device im selben Netz
Wenn der Smart-TV und die eigenen Geräte der Gäste im selben Netz sind, kann direktes Streaming
sehr einfach umgesetzt werden. Sicherheitstechnisch ist dieser Aufbau aber heikel, da jeder Gast die
Möglichkeit hat, auf andere Smart-TVs zu streamen (siehe Abbildung 10). Diese Lösung genügt nicht
den Anforderungen des Kunden.
Seite 14
Abbildung 10: Keine Garantie der Sicherheit, wenn alle Geräte im selben Netz sind
Icon
Information
Film vom eigenen Gerät auf den Smart-TV streamen.
Versendete Filmpakete
Tabelle 7: Legende zu Ablaufdiagram
3.4.3
Ansatz: Ein Netz pro Zimmer
Eine weitere Möglichkeit ist, dass in jedem Hotelzimmer ein eigener Access Point mit eigenem IP-Netz
installiert wird (Abbildung 11: Eigenes IP-Netz pro Zimmer). Dies garantiert, dass nur die Geräte des
Gastes und der Smart-TV des Zimmers im gleichen Netz sind. Dadurch ist die Sicherheit zwar garantiert, aber die Kosten sind horrend. Pro Zimmer muss ein Access Point installiert und konfiguriert
werden. Auch diese Lösung wurde vom Kunden verworfen.
Seite 15
Abbildung 11: Eigenes IP-Netz pro Zimmer
Icon
Information
Blockierte Filmpakete.
Tabelle 8: Legende zu Ablaufdiagramm
3.4.4
Ansatz: Dynamisches Routing
Befindet sich der Smart-TV und das Gerät des Gastes nicht im gleichen Netz, kann der Zugriff vom
Gerät auf den Smart-TV durch die Firewall kontrolliert werden. Damit die Kommunikation von einem
Netz ins andere Netz funktioniert, muss ein dynamisches Routing implementiert werden. Dessen
Ablauf könnte wie folgt aussehen: das Gerät des Gastes fordert eine DHCP-Adresse beim DHCPServer an (Abbildung 12, Schritt 1). Der DHCP-Server führt Buch, welches Gerät (MAC-Adresse)
welche IP-Adresse zu welcher Zeit (Lease Time) erhalten hat (Abbildung 12, Schritt 2) und wie lange
die IP-Adresse gültig ist. Das Gerät erhält dann die IP vom DHCP-Server (Abbildung 12, Schritt 3).
Nun meldet sich der Gast auf dem CMS-Server mit seinem Login an. Wenn sich der Benutzer einloggt, sendet das CMS eine Meldung an die Firewall-Konfigurationseinheit. Diese fragt beim DHCPServer nach (Abbildung 12, Schritt 6, 7), wie lange die IP- Adresse gültig ist. Hat die FirewallKonfigurationseinheit alle notwendigen Informationen gesammelt, erstellt sie auf dem Router eine
neue Routing Policy, die es dem Gerät mit der bestimmen IP erlaubt, Pakete an den Smart-TV zu
senden und zu empfangen (Abbildung 12, Schritt 8). Wenn die DHCP-Lease-Time abgelaufen ist, wird
das Routing wieder ausgetragen. Die hohe Komplexität würde den Umfang dieses Projektes überschreiten.
Seite 16
Abbildung 12: Realisierung von dynamischem Routing
Icon
Information
Hardware Adresse des Gastgerätes
Film vom eigenen Gerät auf den Smart-TV streamen
Lease Time einer IP-Adresse
Komponente zur dynamischen Konfiguration einer oder mehreren Routern
Routing Policy umkonfigurieren
Anfrage der Lease Time und MAC-Adresse
Seite 17
3.4.5
Fazit zum direkten Streamen
Alle oben beschriebenen Ansätze kommen aus unterschiedlichen Gründen nicht in Frage. Direktes
Streaming wurde daher nicht umgesetzt.
3.5
Definitives Lösungskonzept
Das Endgerät des Gastes muss Konnektivität zum CMS-Server und zum Streaming-Server haben.
Die Filmbeschreibungen werden vom CMS-Server geladen, die REST-Aufrufe werden direkt vom
Device an den Streaming-Server gesendet. Damit die Mieten korrekt verrechnet werden können,
muss der CMS-Server ausserdem mit dem PMS-Server verbunden sein. Streaming-Server und Renderer müssen sich im gleichen IP-Netz befinden (siehe Abbildung 13).
Abbildung 13: Netzwerkdiagramm
3.5.1
Gast checkt ein
Bevor überhaupt ein Gast im PMS erfasst wird, müssen im CMS die Hotelzimmer erfasst werden.
Dies beinhaltet die Zimmernummer und die IP-Adresse des Renderers (siehe Abbildung 14, Schritt 1).
Wird ein Gast erfasst, werden unter anderem sein Name und in welchem Zimmer er nächtigt ins PMS
eingetragen (siehe Abbildung 14, Schritt 2).
Wenn ein neuer Gast im PMS erfasst wird, erhält die SocketApplication auf dem CMS-Server eine
Notifikation und erstellt in der Datenbank des CMS einen neuen Gast (siehe Abbildung 14, Schritt 3).
Zusätzlich löst die SocketApplication einen REST-Aufruf aus, um den neuen Gast auf dem StreamingServer zu erfassen (siehe Abbildung 14, Schritt 4).
Seite 18
Abbildung 14: Ablauf beim Erfassen eines neuen Gastes
Icon
Information
Beispiel
Informationen über den Gast (nicht alle
Informationen sind für das Streaming System relevant)
Vorname: Hans
Name: Muster
Reservationsnummer: 1234
Sprache: de
... (nicht relevant für das Streaming System)
Zimmernummer des vom Gasts belegten
Hotelzimmers
203
Informationen um auf dem CMS den Gast
zu erstellen
Vorname: Hans
Nachname: Muster
Sprache: en
IP-Adresse des Renderers (ip_address)
192.168.1.103
Erstellen eines neuen Benutzerordners
Information zum Erstellen des Benutzerordners (user)
MD5(GuestID) =
827ccb0eea8a706c4c34a16891f84e7b
 Name des Benutzerordners des Gastes
Gast auf dem Streaming-Server erfassen
Um einen Gast auf dem Streaming-Server zu erfassen, müssen die Parameter user und ip_address
beim Aufruf übergeben werden. User wird verwendet um einen Benutzerordner auf dem StreamingServer anzulegen. Alle Inhalte, die der Gast hochlädt, werden in seinem Benutzerordner abgespeichert. Dieser ist im öffentlich erreichbaren Teil des Webservers abgelegt und somit für alle Geräte im
Streaming-Netz zugänglich. Um zu verhindern, dass jedes Gerät auf jeden Benutzerordner zugreifen
kann, wird auf den einzigartigen Wert von user eine Hashfunktion angewendet. Die Hashfunktion
(MD5) erzeugt einen 32 Zeichen langen String, der als Namen des Benutzerordner verwendet wird.
Dieses Vorgehen macht es mühsam, einen Benutzerordner ausfindig zu machen, ohne Kenntnis der
genauen URL zu haben.
Jeder Benutzerordner hat zwei Unterordner. Der Unterordner private beinhaltet Inhalte, die der
Benutzer selbst hochgeladen hat. Der Unterordner rented enthält Softlinks zu den Filmen, die der
Gast gemietet hat. Abbildung 15 visualisiert die Ordnerstruktur.
Seite 19
user
.htacces
private
rented
Abbildung 15: Ordnerstruktur eines neu erfassten Benutzers
Jeder Benutzerordner hat zwei Unterordner. Der Unterordner private beinhaltet Inhalte, die der
Benutzer selbst hoch geladen hat. Der Unterordner rented enthält Verknüpfungen zu den Filmen, die
der Gast gemietet hat. Snippet 5 stellt den Inhalt der .htaccess Datei dar.
# ALLOW USER BY IP
<Limit GET POST>
order deny,allow
deny from all
allow from ipAddress
</Limit>
Snippet 5: Inhalt der „.htaccess“-Datei um Benutzerordner zu schützen
Bei Fehlern
Wenn auf der Seite des Servers ein Fehler beim Erstellen eines Benutzerordners auftritt, so wird dies
nur in den Logfiles dokumentiert. Die Schnittstelle zum PMS (SocketApplication) bietet keine Möglichkeit, Fehler an das PMS weiterzuleiten.
3.5.2
Erfassen von Filmen
Ein Angestellter des Hotels muss die Filme im Backend des CMS erfassen (Abbildung 16, Schritt 1).
Für jede Sprache müssen die Informationen über den Film separat erfasst werden. Bei jedem Film
muss erfasst werden, wie die einzelnen Film-Files heissen (siehe Tabelle 11).
Der Angestellt muss die Filme auch auf den Streaming-Server laden (Abbildung 16, Schritt 2). Die
Filme müssen in dem im Konfigurationsdatei (siehe Tabelle 29) festgelegten Ordner auf dem
Streaming Server kopiert werden. Es gibt einen REST-Service zum Hochladen von Filmen über einen
HTTP-Request. Davon wird aber abgeraten, da es sehr lange dauert, grosse Dateien hoch zu laden.
Abbildung 16: Einfügen von neuen Filmen ins CMS und auf den Streaming-Server
Seite 20
Icon
Parameter
Information
Beispiel
movie_id
Bei allen gleichen Filmen
muss bei der Erfassung der
Name gleich sein. Es ist
der Ordner in dem die
Filme auf dem Streaming
Server hinterlegt sein
müssen.
AmericanSniper
movie_title
American Sniper
movie_cover
movie_description
movie_year
movie_cost
2015
Kosten des Films in einer
definierten Währung.
movie_duration
5
132
movie_rentduration
Anzahl der Stunden, die
ein Film konsumiert werden
kann, nachdem er gemietet
Wurde.
24
movie_filename_de
Dateiname für die deutsche
Fassung.
deu-AmericanSniper_Sky_TypeA.mp4
movie_filename_en
Dateiname für die englische Fassung.
en-AmericanSniper_Sky_TypeA.mp4
movie_filename_fr
Dateiname für die französische Fassung.
fr-AmericanSniper_Sky_TypeA.mp4
movie_filename_es
Dateiname für die spanische Fassung.
es-AmericanSniper_Sky_TypeA.mp4
movie_filename_it
Dateiname für die italienische Fassung.
it-AmericanSniper_Sky_TypeA.mp4
movie_genre
Action
Tabelle 11: Legende für Filmbeschreibung
3.5.3
Video on Demand: Möglichkeiten und Ablauf
Authentifizieren im Netz
Der Gast verbindet sein mobiles Gerät (Device) mit dem öffentlichen WLAN des Hotels (Abbildung 17,
Schritt 1). Ist dies geschehen, wird der Gast auf eine Landing Page (CMS) weitergeleitet, auf der er
sich authentifizieren muss. Wenn sich der Gast erfolgreich authentifiziert hat, sind die Zimmernummer
und somit auch die IP-Adresse des Fernsehers bekannt. Ohne Authentifizierung kann der Gast keine
Filme mieten.
Will nun der Gast einen Film mieten, so muss er auf die „Video on Demand“-Seite auf dem CMS
navigieren (Abbildung 17, Schritt 2).
Seite 21
Abbildung 17: Einloggen und verfügbare Filme anfordern
Icon
Information
Anfragen der verfügbaren Filme.
Verfügbare Filme anzeigen
Auf der „Video on Demand“-Seite werden dem Gast alle zur Verfügung stehenden Filme aufgelistet.
Diese sind im CMS eingepflegt und werden aus der Datenbank des CMS Systems geladen (Abbildung
18, Schritt 3).
Abbildung 18: Anzeigen der verfügbaren Filme
Icon
Information
Verfügbare Filme
Seite 22
Mieten eines Films
Der Gast kann nun einen Film mieten (Abbildung 19, Schritt 4). Einen gemieteten Film hat er in allen
vorhandenen Sprachen zur Verfügung. Der gemietete Film wird dem Gast in Rechnung gestellt, indem
eine Meldung via SocketApplication an den PMS-Server gesendet wird (Abbildung 19, Schritt 5).
Dabei wird noch auf dem Streaming-Server eine REST-Anfrage ausgelöst, dass der Gast einen bestimmten Film gemietet hat (Abbildung 19, Schritt 6). Jeder gemietete Film wird mit einer Verknüpfung
(Soft Link) in seinen Benutzerordner gelinkt. Zusätzlich wird ein Ausleih-Task erzeugt und in die
Datenbank gespeichert. Jeder Ausleih-Task enthält die Information, bis zu welchem Datum ein Film
ausgeliehen ist. Die Datenbank wird periodisch geprüft und die Verknüpfungen fälliger Ausleihen
werden aus dem Benutzerordner entfernt.
Abbildung 19: Mieten eines Films
Icon
Information
Film mieten.
Starten eines Films
Startet der Gast einen Film über das Webinterface (Abbildung 20, Schritt 1), wird ein REST-Aufruf
ausgelöst (Abbildung 20, Schritt 2), dass der Gast einen Film in der englischen Sprachversion auf
seinem Smart-TV anschauen will. Daraufhin registriert sich der Streaming-Server beim Smart-TV als
Listener, um etwaige Stopp-Aktionen durch die Fernbedienung zu erhalten (Abbildung 20, Schritt 3).
Ist dies geschehen, erhält der Smart-TV eine SOAP-Nachricht zum Setzen der Lokalität des Films
(Abbildung 20, Schritt 4) und eine Play-Aktion zum Starten des Films (Abbildung 20, Schritt 5). Nun
beginnt der Smart-TV mit dem Streaming, indem er den Film vom Webserver auf dem StreamingServer herunterlädt und anzeigt (Abbildung 20, Schritt 6).
Seite 23
Abbildung 20: Starten eine gemieteten Films
Icon
Information
Beispiel
Starten eines
Films.
Dateiname des
zu startenden
Films.
AmericanSniper
Webserver-URL
http://192.168.1.2:80/
Control Point
meldet sich beim
Renderer als
Listener an
SUBSCRIBE /AVTransport/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/event.xml HTTP/1.0
Content-Length: 0
HOST: 192.168.1.103
CALLBACK: <http://192.168.1.2:8058/evetSub>
NT: upnp:event
TIMEOUT: infinite
Connection: close
Action zum
Setzten der
wiederzugebenden Datei
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:SetAVTransportURI xmlns:u="urn:schemas-upnporg:service:AVTransport:1">
<InstanceID>0</InstanceID>
<CurrentURI>
http://192.168.1.2:80/users/827ccb0eea8a706c4c34a16891f84e7b/rented
/en-AmericanSniper_Sky_TypeA.mp4
</CurrentURI>
<CurrentURIMetaData></CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>
Seite 24
Play()-Action
zum Starten einer
Wiedergabe
<s:Body>
<u:Play xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<Speed>1</Speed>
</u:Play>
</s:Body>
</s:Envelope
Pausieren
Der Gast kann mittels der Steuerung auf der Weboberfläche den Film pausieren. Die Fortschrittsanzeige läuft dann nicht mehr weiter. Im Hintergrund wird eine REST-Anfrage an den Streaming-Server
(Abbildung 21, Schritt 1) gesendet. Dieser sendet eine SOAP-Nachricht an den Smart-TV, dass der
Film pausiert werden soll (Abbildung 21, Schritt 2).
Abbildung 21: Stoppen eine gemieteten Films
Icon
Information
Beispiel
Aktion zum Pausieren
eines Films.
Pause()-Action
<s:Body>
<u:Pause xmlns:u="urn:schemas-upnporg:service:AVTransport:1">
</u:Pause>
</s:Body>
</s:Envelope>
Spulen
Der Gast kann die Wiedergabe vor- und zurückspulen (Abbildung 23, Schritt 1) indem er den Regler
auf der Fortschrittsanzeige vor und zurück bewegt. Der Wert der Fortschrittsanzeige wird erst beim
Loslassen abgefragt. Der neue Wert und die IP-Adresse des Geräts werden als REST-Anfrage an den
Seite 25
Streaming-Server gesendet (Abbildung 23, Schritt 2). Der Streaming-Server sendet daraufhin einen
Seek-Befehl an den Renderer mit der vom Gast gewählten Position (Abbildung 23, Schritt 3). Daraufhin spult der Fernseher an die gewählte Stelle (Abbildung 23, Schritt 4).
Abbildung 23: Spulen von Filmen
Icon
Information
Beispiel
Spulen eines Films.
IP-Adresse: 192.168.1.103
Zeit: 00:34:00
Seek()-Action mit
Angaben von Einheit
und Ziel
<s:Body>
<u:Seek xmlns:u="urn:schemas-upnporg:service:AVTransport:1">
<Unit>REL_TIME</Unit>
<Target>00:34:00</Target>
</u:Seek>
</s:Body>
</s:Envelope>
Stoppen
Ein Gast kann jederzeit einen Film stoppen über den Stopp-Knopf der Webapplikation (Abbildung 24,
Schritt 1). Auf dem Streaming-Server wird der laufende Film gestoppt und aus der Wiedergabeliste
gelöscht (Abbildung 24, Schritt 2). Der Streaming-Server sendet dem Renderer einen Stopp-Befehl,
woraufhin der Renderer die aktuelle Wiedergabe stoppt. Falls in der Playlist noch weitere Inhalte
gelistet sind, wird der nächste Inhalt in der Liste gestartet. Dem Renderer wird ein Befehl zum Setzen
des neuen Inhaltes (SetAVTransportURI) gesendet (Abbildung 24, Schritt 4) und darauffolgend einen
Start-Befehl (Abbildung 24, Schritt 5). Nun zeigt der Renderer den neuen Inhalt an (Abbildung 24,
Schritt 6).
Seite 26
Abbildung 24: Stoppen eines Films wenn die Playliste noch Streams enthält
Icon
Information
Beispiel
Löschen eines Streams
aus der Wiedergabeliste.
Stoppen eines Films.
IP-Adresse: 192.168.1.103
Stop()-Action
<s:Body>
<u:Stop xmlns:u="urn:schemas-upnporg:service:AVTransport:1">
</u:Stop>
</s:Body>
</s:Envelope>
Befindet sich nach dem Entfernen der aktuellen Wiedergabe kein Stream mehr in der List, so sendet
der Streaming-Server dem Smart-TV einen Unsubscribe-Request um sich als Listener abzumelden
(siehe Abbildung 25, Schritt 5).
Seite 27
Abbildung 25: Stoppen eines Films wenn die Playliste leer ist
Icon
Information
Beispiel
HTTP UNSUBSCRIBE
Paket.
UNSUBSCRIBE /AVTransport/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/event.xml HTTP/1.0
Der Control Point meldet
sich als Listener beim
Renderer ab.
Content-Length: 0
HOST: 192.168.1.103
SID: uuid:ae5361ea-9d1c-0ced-440a-2f2967c9aec4
Connection: close
Stoppen eines Films mit der Fernbedienung
Da sich der Streaming-Server beim Smart-TV als Listener registriert, erhält der Streaming-Server eine
Notifikation falls sich der Zustand des AV Transport Service ändert. Wenn der Gast also mit der Fernbedienung den laufenden Film stoppt (Abbildung 26, Schritt 1), sendet der Smart-TV dem StreamingServer eine Notifikation dass sich der TransportState von PLAYING auf STOPPED geändert hat
(Abbildung 26, Schritt 2). Dies nimmt der Streaming-Server zur Kenntnis und löscht den Stream auf
der ersten Position in der Playliste (Abbildung 26, Schritt 3). Wenn die Playliste nicht leer ist, rutscht
der zweite Stream auf die erste Position. Der Streaming-Server setzt die neue URI auf dem Smart-TV
(Abbildung 26, Schritt 4) und startet die Wiedergabe (Abbildung 26, Schritt 5).
Seite 28
Abbildung 26: Stoppen eines Streams mit der Fernbedienung. Playliste ist nicht leer
Icon
Information
Beispiel
Smart-TV Fernbedienung
Fernbedienungsbefehl zum
Stoppen eines Streams.
LastChangeEventnotifikation
<Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/">
<InstanceID val="0">
<TransportState val="STOPPED" />
<NumberOfTracks val="0" />
<CurrentTrack val="0" />
<CurrentTrackDuration val="00:00:00" />
<CurrentMediaDuration val="00:00:00" />
</InstanceID>
</Event>
Ist die Wiedergabeliste hingegen leer, dann löscht der Streaming-Server den vorhandenen Stream
und schreibt sich als Listener aus (Abbildung 27, Schritt 4).
Seite 29
Abbildung 27: Stoppen eines Streams mit der Fernbedienung. Playliste ist leer
Positionsinfo
Die Kommunikation zwischen dem mobilen Device und dem Streaming-Server funktioniert unidirektional. Das heisst, der Streaming-Server kann das Device nicht kontaktieren. Wenn also der Stream mit
der Fernbedienung gestoppt wird, wird zwar der Streaming-Server benachrichtigt, aber der StreamingServer kann das mobile Device nicht informieren. Aus diesem Grund läuft auf dem Device ein
Scheduler, implementiert in JavaScript, der alle fünf Sekunden die aktuelle Position beim StreamingServer abfragt. (Abbildung 28, Schritt 1 und 2). Innerhalb der fünf Sekunden wird die Zeit interpoliert,
deshalb wird eine Änderung des Zustandes eines Streams auf dem Webinterface erst nach 5 Sekunden angezeigt. Der Streaming-Server selbst sendet die Action GetPositionInfo() an den Smart-TV
zur Bestimmung der aktuellen Position (Abbildung 28, Schritt 3). Der Streaming-Server antwortet mit
der aktuellen Position (Abbildung 28, Schritt 4) und sendet es dem mobilen Device des Gastes weiter
(Abbildung 28, Schritt 5 und 6).
Seite 30
Abbildung 28: Fortschrittsanzeige des Webinterfaces synchronisieren mit dem Stream
Icon
Information
Beispiel
Javascript-Scheduler,
der alle 5 Sekunden
die aktuelle Position
abfragt
REST-Anfrage an den
Streaming-Server zur
aktuellen Position des
Streams.
GetPositionInfo()
als SOAP-Nachricht
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/
">
<s:Body>
<u:GetPositionInfo xmlns:u="urn:schemas-upnporg:service:AVTransport:1">
</u:GetPositionInfo>
</s:Body>
</s:Envelope>
Antwort des Renderers auf
GetPositionInfo()
<s:Envelope
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/
" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetPositionInfoResponse xmlns:u="urn:schemasupnp-org:service:AVTransport:1">
...
<RelTime>00:38:40</RelTime>
...
</u:GetPositionInfoResponse>
</s:Body>
</s:Envelope>
Seite 31
Antwort an das Device
mit der aktuellen
Abspielzeit.
{
postitionLong: 310
postitionString: "00:05:10"
}
Eigene Inhalte hochladen
Der Gast hat die Möglichkeit eigene Inhalte auf den Streaming-Server hochzuladen und diese Inhalte
dann auf den Renderer zu streamen. Es können nur definierte Formate hochgeladen werden. Beim
Upload wird clientseitig aufgrund der Endung entschieden, ob die Datei hochgeladen wird oder nicht
(Abbildung 29, Schritt 1). Wird das Hochladen verwehrt, erhält der Gast eine Meldung, dass der
Dateityp nicht hochgeladen werden darf. Wenn die Endung in Ordnung ist, wir die Datei hochgeladen
(Abbildung 29, Schritt 2). Auf dem Streaming-Server selbst wird der Inhalt der Datei untersucht, um
heraus zu finden, um was für einen Dateityp es sich handelt (Abbildung 29, Schritt 3). Ist der Datentyp
nicht erlaubt, erhält der Gast wiederum eine Meldung und die Datei wird nicht auf die Festplatte geschrieben. Zusätzlich zum Hochladen der Datei, wird deren Name normalisiert. Alle Grossbuchstaben
werden in Kleinbuchstaben umgewandelt und Sonderzeichen aus dem Namen entfernt. Die Normalisierung des Dateinamens verhindert Fehler. Ein möglicher Fehler wäre, dass der Renderer die Datei
nicht finden kann.
Abbildung 29: Hochladen von eigenem Inhalt auf dem Streaming-Server
Icon
Information
Vorgang zur Bestimmung, ob die Datei hochgeladen werden darf. Auf dem StreamingServer wird der Dateiname normalisiert.
Datei, die vom Gast auf den Streaming-Server geladen wird. Kann ein Film, Bild oder
auch Musik sein.
Eigene Inhalte abfragen
Die Inhalte, die ein Gast selbst hoch lädt, werden in seinen privaten Benutzerordner (private) auf
dem Streaming-Server abgespeichert. Wenn ein Benutzer seine hochgeladenen Inhalte anzeigen will,
dann muss er auf die Seite im CMS navigieren, welche seine Dateien anzeigt (Abbildung 30, Schritt
1). Daraufhin wird eine REST-Anfrage an den Streaming-Server gesendet, welche eine Liste mit den
Namen der Dateien im Ordner als Antwort zurück schickt. (Abbildung 31, Schritt 1).
Seite 32
Abbildung 30: Anfrage: Abfragen der eigenen Inhalte
Abbildung 31: Antwort: Abfragen der eigenen Inhalte
Icon
Information
Dateiname.
3.5.4
Gast checkt aus
Wenn ein Gast das Hotel verlässt, wird er im PMS ausgecheckt (Abbildung 32, Schritt 1). Danach
erhält die SocketApplikation auf dem CMS-Server eine Notifikation, dass der Gast ausgecheckt hat.
Die Datenbank auf dem CMS-Server wird daraufhin angepasst. (Abbildung 32, Schritt 2). Zusätzlich
wir auf dem Streaming-Server die REST-Anfrage zum Löschen eines Benutzerordners aufgerufen
(Abbildung 32, Schritt 3). Durch diesen Aufruf werden alle laufenden Streams des Gastes gestoppt
und gelöscht. Dazu werden alle Tasks, zum Überprüfen der Ausleihfrist der Filme für diesen Gast, aus
der Datenbank auf dem Streaming-Server gelöscht. Zum Schluss wird der Benutzerordner des Gastes
entfernt.
Seite 33
Abbildung 32: Gast verlässt das Hotel
Icon
Information
Beispiel
Gast auschecken.
Vorname: Hans
Name: Muster
Sprache: de
... (nicht relevant für das Streaming System)
Information, dass der Gast ausgecheckt hat.
Vorname: Hans
Nachname: Muster
Sprache: de
Löschen der Filme in der Wiedergabeliste.
Löschen aller Ausleih-Task des
Gastes in der Datenbank.
Löschen des Benutzerordners.
Seite 34
4
Streaming-System
Das Streaming-System ist eine verteilte Applikation, die aus zwei Servern und mehreren Komponenten besteht. Die einzelnen Komponenten, betrieben auf den Servern, haben eine klar definierte Aufgabe und einen spezialisierten Einsatzzeck. Dies verlangt, dass die Wahl der Programmiersprachen,
Frameworks und Libraries stark von einzelnen Anforderungen an die Komponenten abhängig ist.
4.1
CMS-Server
Der CMS-Server, das Betriebssystem und die darauf betriebenen Applikationen wurden in einem
vorgängigen Projekt evaluiert und in Betrieb genommen. Daher wird in dieser Arbeit nicht darauf
eingegangen. Tabelle 24 listet die wichtigsten Applikationen und deren Versionen des übernommenen
Testsystems auf.
Applikation
Version
Verantwortung
Apache Server
2.2.22
Bereitstellen der Webseite.
Java 7
1.7.0_79
Ausführen der
Streaming-Applikation
MySQL
5.5.44
Datenbank zur Speicherung von Daten
Wordpress
4.2.1
CMS zum erfassen und
darstellen der Filme.
PHP
5.3.10
SocketApplication
Schnittstelle von CMS
zum PMS.
Tabelle 24: Für den Betrieb des CMS-Servers notwendige Software.
SocketApplication
Die Socket Applikation (im Projekt SocketApplication) wurde von einem Vorgänger Projekt entwickelt
und für diese Arbeit nur erweitert. Die Applikation ist dafür zuständig, dass PMS und CMS auf dem
gleichen Datenstand sind und interagieren können.
Die Erweiterung umfasst jeweils einen REST-Aufruf an den Streaming-Server wenn ein neuer Gast
erfasst wird und wenn ein bestehender Gast ausgecheckt wird.
Gekapselt
wurde
die
Funktionalität
in
der
Klasse
„RESTClient“
im
Package
„ch.fhnw.imvs.hotelplus.restclient“.
Die
Klasse
„DatabaseConnection“
im
Package
„ch.fhnw.ip314.hotelplus.data“ wurde um die zwei Methoden getGuestId() und getGuestIpAddress() erweitert.
Wordpress
Die graphische Benutzerschnittstelle des Streaming Systems wurde in die vorhandene CMS-Lösung
integriert. Zurzeit nutzt hotelplus Wordpress um Hotelangebote den Gästen zur Verfügung zu stellen.
Die Pflege der Filme erfolgt im Wordpress-Administrationsbereich. Das Wordpress-Plugin ACF (Advanced Custom Fields) wurde bereits vom Vorgängerprojekt verwendet und wird auch in diesem
Projekt eingesetzt. Grundsätzlich bietet es einem die Möglichkeit, einfach Felder zu definieren und
anschliessend abzufragen. Verwendet wird ein Repeater-Feld „movies“ mit Unterfelder (bspw.
„movie_title“). Das Repeater-Feld ist ähnlich einer Tabelle, wobei die Unterfelder die Spalten darstellen.
Seite 35
Mit dem Codeausschnitt in Snippet 6 kann auf ein solches Repeater-Feld zugegriffen werden.
<?php if( have_rows('movies') ): ?>
<ul>
<?php while( have_rows('movies') ): the_row(); ?>
<li>movie_title = <?php the_sub_field('movie_title'); ?></li>
<?php endwhile; ?>
</ul>
<?php endif; ?>
Snippet 6: ACF Repeater-Feld Beispiel [19]
Abbildung 33: Erfassen von Filmen in Wordpress-Administrationsbereich (Dateinamen für die französisch, italienische und
spanische Version fehlen aus Platzgründen)
Abbildung 33 zeigt, wie die Filme erfasst werden. Dabei gibt es zwei Punkte, die genau beachtet
werden müssen:
Die Dateinamen der Filme im Wordpress müssen exakt mit denen auf dem Datenspeicher übereinstimmen. Ansonsten wird der Film nicht abgespielt. Jede Sprache hat einen eigenen Dateinamen.
Wenn das Feld leer (also auch ohne Leerzeichen) gelassen wird, wird angenommen, dass es diesen
Film in dieser Sprache nicht gibt.
Mit dem Wordpress-Plugin WPML (Wordpress Multilingual) wird die Webseite für jeden Gast in seiner
bevorzugten Sprache angezeigt. Das Plugin arbeitet so, dass von jeder Seite für jede Sprache eine
Version existiert. Das heisst, das Plugin leitet den Benutzer je nach Sprache auf eine andere Version
der Seite. Für die Pflege der Filmdatenbank müssen daher pro Sprachversion alle Filme erfasst werden. Aus Datensicht bedeutet das, dass beispielsweise ein Film auf der deutschen Seite kein Attribut
mit dem gleichen Film auf der englischen Seite gemeinsam hat. Damit eine Gemeinsamkeit besteht,
wurde das Unterfeld „movie_id“ eingeführt. Dieses muss über alle Sprachversionen eines Films eindeutig sein.
Damit der Client weiss, an welchen Fernseher er seine Inhalte streamen muss, fragt er die aktuelle IPAdresse beim CMS ab. Diese Informationen müssen ebenfalls im Wordpress-Administrationsbereich
gepflegt werden. Dem bereits existierenden Menüpunkt „hotelplus“ wurde ein Untermenü angehängt
(siehe Abbildung 34). Die Aufgabe des Untermenüs ist es, die Zimmernummer mit der jeweilig aktuellen Fernseher-IP-Adresse anzuzeigen und die Möglichkeit zu bieten, diese Informationen zu manipulieren.
Hotelplus hat ein eigenes Wordpress-Design. Der Code für die Streaming-Funktionalität wurde möglichst unabhängig in das vorhandene Theme integriert. Im Endeffekt mussten drei existierende Dateien bearbeiten werden, um die neuen Scripts einzubinden.
Die Darstellungslogik des Players und die Interaktion mit dem Streaming-Server wurden mit Javascript
und jQuery realisiert. Klicks auf die Knöpfe im Player generieren AJAX-Calls an die RESTSchnittstelle des Streaming-Servers.
Seite 36
Abbildung 34: Pflege der Fernseher-IP-Adressen
4.2
Streaming-Server
Als Betriebssystem für den Streaming-Server kann eine beliebige Linuxdistribution verwendet werden.
Das verwendete Testsystem ist ein Ubuntu-Linux (siehe Tabelle 25).
Betriebssystem
Ubuntu
Release
Kernel
14.04.2 LTS
3.16.0-30-generic
Tabelle 25: Betriebssystem des Testsystems
Der Streaming-Server besteht aus einer selbst entwickelten Anwendung und einigen Fremdapplikationen. Tabelle 26 listet alle benötigten Softwarekomponenten auf und beschreibt auch deren Einsatzzweck. Die Version bezieht sich auf das Testsystem.
Applikation
Version
Verantwortung
Apache Server
2.4.7
Bereitstellen der Daten
(Webserver) für die Renderer.
Java 8
1.8.0_45
Ausführen der StreamingApplikation
MySQL
5.5.43
Datenbank zur Speicherung
von Tasks.
StreamingApplikation
Tabelle 26: Verwendete Applikationen um den Dienst zu gewährleisten
Seite 37
4.2.1
Streaming-Applikation
Die Streaming-Applikation wird auf dem Streaming-Server ausgeführt und ist zuständig, dass Filme
gestreamt werden können. Die Applikation ist modular aufgebaut und besteht aus den drei Teilen:
Streaming, REST und Renting (siehe Tabelle 2). Die Streaming-Applikation wurde für Serverbetriebssysteme auf Linux Basis konzipiert und läuft nicht ohne weiteres auf nicht Linux Systemen.
Modul
Package
Verantwortung
REST
ch.fhnw.imvs.hotelplus.rest
Dient als Schnittstelle zu anderen Systemen. Interagiert mit CMS und nimmt
REST-Aufrufe entgegen.
Streaming
ch.fhnw.imvs.hotelplus.upnp
Streaming von Filmen.
Renting
ch.fhnw.imvs.hotelplus.rentingsystem
Erstellen von Benutzerordner.
Erstellen von Verknüpfungen zu gemieteten Filmen.
Löschen von Filmen, deren Mietdauer
abgelaufen ist.
Löschen von Benutzerordern.
Tabelle 27: Zuordnung der Module zu den Packages und deren Verantwortungsbereich
Die Applikation ist in zwei Schichten unterteilt (Abbildung 35). Die erste Schicht ist hauptsächlich dafür
verantwortlich, REST-Anfragen von externen Systemen zu verarbeiten. Dabei ist auch ein minimaler
Teil an Business-Logik in der ersten Schicht vorhanden. Die zweite Schicht besteht aus Renting und
Streaming, wobei diese Teile nur wenig miteinander interagieren.
Abbildung 35: Schichtenarchitektur der Streaming-Applikation
Frameworks und Libraries
Für die Streaming-Applikation wurden die in Tabelle 28 aufgelisteten Libraries und Frameworks verwendet.
Framework / Library
Version
Einsatzzweck
Spring Framework
4.2.0
Rest-Interface.
Stand-Alone Applikation.
Apache Tika
1.9
File-Type-Erkennung von hochgeladenen
Dateien.
Cybergarage
2.1.0
UPnP Library
Java Persistence
API (JPA)
1.7.2
Objektrelationaler Zugriff auf relationale
Datenbank.
Tabelle 28: Verwendete Frameworks und Libraries
Seite 38
Konfiguration der Streaming-Applikation
Die Streaming-Applikation ist parametrisiert und muss dadurch nicht neu kompiliert werden, wenn sich
Einstellungen ändern. Die Tabelle 29 zeigt die veränderbaren Parameter und erklärt deren Bedeutung.
Parameter
Beispiel
Erklärung
rest.serverurl
http://192.168.1.2:80/
Protokoll, URL und Ports zum
Webserver, der den Inhalt für die
Renderer bereit stellt
filecontroller.basepath
/var/www/html
Basispfad zum Webverzeichnis.
filecontroller.movie_directory
/var/www/movies/
Pfad zum Ordner, indem die Filme
bereitgestellt werden.
filecontroller.user_folder_name
users
Name des Basisordners in dem die
Benutzerordner erstellt werden.
filecontroller.user_directory
/var/www/html/users
Pfad zum Basisordner der Benutzerordner.
filecontroller.rented_folder
rented
Name des Ordners, in den dem die
Verknüpfungen zu den gemieteten
Film erstellt werden.
filecontroller.private_folder
private
Name des Ordners, in den dem die
eigenen Dateien des Gastes gespeichert werden.
database.url
localhost:3306/hotelplus_task
Pfad zur Datenbank.
database.user
root
Datenbank-Benutzer.
database.password
hotelplus
Datenbank-Passwort.
filetypes
mp3,mp4,jpeg,mov
Dateitypen, die der Gast hochladen
darf.
renting.maxListElements
3
Maximale Grösse der Playliste.
scheduler.findDevice
60000 1 Minute
Zeitperiode zum Suchen von Renderern im Netzwerk.
scheduler.deleteExpiredTasks
60000 1 Minute
Zeitperiode zum Löschen von abgelaufenen Ausleihen aus der Datenbank.
scheduler.renewNotification
1600000 26 Minuten
Zeitperiode zum Erneuern von
Subscriptions.
Tabelle 29: Parameter zur Konfiguration der Streaming-Applikation
Seite 39
Modul: Rest
Alle
Klassen,
die
die
REST
Schnittstelle
„ch.fhnw.imvs.hotelplus.rest.controller“ gebündelt.
betreffen,
sind
im
Package
Abbildung 36: Klassen des Moduls REST
Das REST-Interface stellt drei Ressourcen (User, Devices, Movie) bereit, die durch REST-Aufrufe
manipuliert werden können. Die Tabelle 30 listet die Ressourcen auf und Referenziert auf die APIDokumentation der REST-Schnittstelle im Anhang.
Ressource
Beschreibung
API Referenz
Users
Aktionen, um den User zu manipulieren.
Anhang 12.1.1 Users
Device
Aktionen, um das Streaming von Medieninhalten zu
manipulieren. Ein Device ist erst manipulierbar, wenn
mindestens ein Stream aktiv ist.
Ahang 12.1.2 Device
Movie
Verwalten der Videothek. Es wird davon abgeraten, Filme
über diese Schnittstelle hochzuladen.
Anhang 12.1.3 Movies
Tabelle 30: REST Ressourcen
Modul: Renting
Das Modul Renting ist zuständig, dass Gäste nur auf ihre eigenen Inhalte Zugriff haben und auch nur
Filme abspielen können, die sie auch gemietet haben. Um dies zu gewährleisten werden verschiedenen Mechanismen eingesetzt. Die zugehörigen Klassen sind in Abbildung 37 ersichtlich.
Seite 40
Abbildung 37: Klassen des Moduls Renting
Datenbank
Jeder Gast hat seinen Benutzerordner. Wenn ein Gast ein Film mietet, wird ein Softlink des gemieteten Films in den Bereich rented erstellt. Zu jedem gemieteten Film wird ein Task in die Datenbank
(Tabelle 31) gespeichert. Dieser beinhaltet, wie lange eine Verknüpfung im Benutzerordner des Gastes bestehen bleibt (wie lang also ein Film gemietet ist).
Zur Speicherung der Daten wird eine relationale Datenbank verwendet (MySQL). Auf die Datenbank
wird über einen objektrelationalen Mapper (Java Persistence API) zugegriffen.
Alle notwendigen Methoden um die Daten zu handhaben, sind in der Klasse „TaskDao“ zu finden. In
der Datenbank werden Objekte der Klasse „Task“ abgelegt.
Feldname
Typ
Beschreibung
Beispiel
id
bigint(20)
Automatisch von der Datenbank generiert (Unique Key).
215
delete_date
datetime
Bis wann der Film gültig ist.
2015-08-11 16:45:00
folder_name
varchar(255)
Ordner.
rented
movie_name
varchar(255)
Filmname.
user_folder
varchar(255)
Benutzerinformation.
827ccb0eea8a706c4c34a16891f84e7b
ip_address
varchar(255)
IP-Adresse des Renderers.
192.168.1.103
Tabelle 31: Datenbankarchitektur
Modul: Streaming
Das Modul Streaming ist für die Interaktion mit den Renderern zuständig. Abbildung 38 zeigt die
involvierten Klassen. Sämtliche Logik für das Streaming wie das Führen der Wiedergabeliste und
Initiieren der Actions wurden hier implementiert. Das Generieren der SOAP-Nachrichten wurde jedoch
durch eine Library übernommen.
Seite 41
Abbildung 38: Klassen des Moduls Streaming
Evaluation der Streaming-Library
Im Vorfeld der Entwicklung wurden einige bestehende Media-Server evaluiert (siehe Tabelle 32 bis
Tabelle 36). Das Ziel war eine existierende Applikation zu finden, die erweitert werden kann. Dazu
muss der Source Code frei verfügbar sein. Ausserdem sollte eine API für die Interaktion vorhanden
sein.
Name
Plex
URL
www.plex.tv
Sprache
C++
Bemerkung
Es existiert eine nicht offizielle API [20], aber der Code ist nicht opensource.
Open-Source
Nein
Tabelle 32: Evaluation Plex
Name
SimpleDLNA
URL
http://nmaier.github.io/simpleDLNA/
Sprache
C#
Bemerkung
Es gibt keine API.
Open-Source
Ja
Open-Source
Nein
Tabelle 33: Evaluation SimpleDLNA
Name
mistserver
URL
www.mistserver.org
Sprache
C++
Bemerkung
Es gibt zwar eine API. Aber der Code ist nicht open-source, daher nicht
erweiterbar.
Tabelle 34: Evaluation mistserver
Seite 42
Name
Universal Media Server (UMS)
URL
http://www.universalmediaserver.com
Sprache
Java
Bemerkung
Universal media server ist die Neuentwicklung von PS3 Media Server.
Dieses Projekt hat keine API.
Open-Source
Ja
Tabelle 35: Evaluation Universal Media Server (UMS)
Name
Serviio
URL
http://www.serviio.org
Sprache
Java
Bemerkung
Serviio hat zwar eine API, diese ist jedoch nur in der kommerziellen Version
verfügbar. Der Code der Basisversion ist open-source.
Open-Source
Nein
Tabelle 36: Evaluation Serviio
Keiner der getesteten Media-Server ist geeignet. Einerseits weil keine Anwendung eine API anbietet
und zugleich open-source ist, andererseits weil die Einarbeitung und Erweiterung einer bestehenden
Applikation zu viel Zeit in Anspruch nehmen würde.
Daher fiel die Entscheidung, dass ein eigenes Produkt entwickelt werden soll. Für den UPnP-Stack
wurde eine geeignete Library gesucht. Die beiden Libraries CyberGarage und Cling wurden evaluiert
und testweise implementiert. Die Tabelle 37 stellt einige Eckdaten der Libraries gegenüber.
Library
Cling
Cybergarage
Webseite
www.4thline.org/projects/cling/
www.cybergarage.org/
Aktuelle Version
2.0.1 (11.06.2014)
2.1.0 (28.07. 2014)
Ersteller
Christian Bauer
Satoshi Konno
Nationalität
Schweiz
Japan
Projekte basierend auf
der Library
BubbleUPnP
Apache Felix
(Generischer UPnP/DLNA Media
Control Point und Renderer für
Android.)
Tabelle 37: Vergleich der Eckdaten der zwei Libraries zum streamen über UPnP
Eine detaillierte Evaluation der beiden Libraries hat sich erübrigt, als Cling und REST testweise zusammen ausgeführt werden sollten. Denn eine Exception brach die Ausführung ab.
org.fourthline.cling.transport.Router
: Unable to initialize network router:
org.fourthline.cling.transport.spi.InitializationException:
Failed to set modified URLStreamHandlerFactory in this environment.
Can't use bundled default client based on HTTPURLConnection, see manual.
: Cause: org.fourthline.cling.transport.spi.InitializationException
: Failed to set modified URLStreamHandlerFactory in this environment. Can't use bundled
default client based on HTTPURLConnection, see manual.
Snippet 7: Geworfene Exception beim Start der Applikation mit Cling und Spring REST
Detaillierte Beschreibung der Probleme mit der Cling Library (siehe Anhang 12.3)
Der Entwickler von Cling hat die Exception aus Snippet 7 beschrieben.
Seite 43
Cling verändert die Klasse URLStreamHandlerFactory und lädt diese in die Java Virtual Machine. Das
Problem ist, dass pro Java Virtual Machine nur eine Klasse des Types URLStreamHandlerFactory
geladen werden darf. Da aber REST die Klasse bereits geladen hat, bevor sie von Cling geladen
werden kann, erzeugt dies den Fehler (Snippet 8). Die vom Entwickler geschriebene URLStreamHandlerFactory Klasse erstellt ein Objekt der HTTPURLConnection, welche um weitere HTTPMethoden wie „NOTIFY“ und „SUBSCRIBE“ erweitert wird. Die Standardklasse HTTPURLConnection
wirft eine Exception, wenn eine Methode andere HTTP Verben als GET, PUT, POST oder DELETE
verwendet.
„<dt><code>org.fourthline.cling.transport.impl.StreamClientImpl</code> (default)</dt>
<dd>
This implementation uses the JDK's <code>HTTPURLConnection</code>, it doesn't require
any additional libraries. Note that Cling has to customize (with an ugly hack, really) the VM's
<code>URLStreamHandlerFactory</code> to support additional HTTP methods such as
<code>NOTIFY</code>, <code>SUBSCRIBE</code>, and <code>UNSUBSCRIBE</code>. The
designers of the JDK do not understand HTTP very well and made this extremely difficult to extend.
Cling's patch only works if no other code in your environment has already set a custom
<code>URLStreamHandlerFactory</code>, you will get an exception on startup if this issue is detected; then you have to switch to another <code>StreamClient</code> implementation. Note that this
implementation
does
<em>NOT
WORK</em>
on
Android,
the
<code>URLStreamHandlerFactory</code> can't be patched on Android!
</dd>“ [21]
Snippet 8: Erklärung des Problems durch Entwickler
Weitere Informationen, wie man das Problem lösen könnte, sind dem Anhang zu entnehmen. Da die
Library von Cybergarage keinen Fehler verursachte, bekam diese den Vorzug.
Seite 44
4.3
Media Renderer
Der Media Renderer ist der Client, welcher die Medieninhalte auf dem Dateiserver holt und abspielt.
Die Aufgabenstellung geht davon aus, dass keine Settop-Box (STB) zwischen Server und Fernseher
geschaltet sein muss, sondern der Fernseher direkt die Daten vom Server streamt. Der für den Testaufbau zur Verfügung gestellte Smart-TV ist ein Samsung Hotel-TV (Modell: HG32EC690DB). Nach
Tests mit verschiedenen UPnP-Servern, Recherche im Internet und Kontaktaufnahme mit dem Samsung-Support (siehe Anhang 12.5) wurde bestätigt, dass dieses Modell UPnP nicht im vollen Umfang
unterstützt. Auch das Handbuch erwähnt weder UPnP noch DLNA [22]. Zwar kann eine Wiedergabe
gestartet und gestoppt werden, alle anderen benötigten Funktionen sind nicht implementiert.
Nach Absprache mit Kunde und Betreuer wurde entschieden, doch eine Settop-Box einzusetzen. Aus
wirtschaftlichen Gründen fiel die Entscheidung auf ein Raspberry Pi 2 (Spezifikation siehe Quelle [23])
mit dem frei verfügbare Mediacenter-Betriebssystem OpenELEC (Open Embedded Linux Entertainment Center Version 5.95.3.6.0) [24]. OpenElec unterstützt UPnP inklusive UPnP AV komplett und
deckt somit die Anforderungen an einen Media Renderer ab.
Da ein Hotelgast auch eigene Inhalte auf den Streaming Server kopieren kann, wurde für den Media
Renderer OpenELEC die gängigsten Mediendateiformate auf die Streaming-Fähigkeit hin getestet.
Dabei wurden möglichst viele, verschiedene Formate verwendet. Tabelle 38 zeigt die Testresultate zu
den getesteten Videoformaten, Tabelle 39 zeigt die Testresultate zu den Musikformaten und Tabelle
40 zeigt die Testresultate zu den getesteten Bildformaten. Ob ein Media Renderer die Formate abspielen kann, ist davon abhängig, ob die Formate dekodiert werden können. Da OpenELEC eine
Linux Distribution ist, ausgelegt auf das Abspielen von Multimediainhalten, sind die gängigsten
Codecs schon vorinstalliert oder können nachinstalliert werden.
Die Dateien des Testdatensatzes wurden mit der Konvertierungssoftware „Free Video Converter“ der
Firma LEAW [25] konvertiert, auf den Streaming-Server geladen und gestartet. Wurde die Datei
abgespielt und konnte gespult, pausiert und gestoppt werden, war der Test erfolgreich.
Videoformate
Wiedergabe möglich
AVI
Audio Video Interleave
MPEG1
Moving Picture Experts Group
MPEG2
MPEG-2 Videodatei (für DVDs genutzt)
MOV
Quicktime Movie
ASF
Advanced Streaming Format
FLV
Flash Video
MP4
MPEG-4 Video
WMV
Windows Media Video
3G2
XviD
freie Implementierung des MPEG-4-Video-Codecs
[26]
TS
Video Transport Stream [27]
VOB
DVD Video Object (MPEG-2 Videodatei)
MKV
Matroska Containerformat
DV
Digital Video
VP8
F4V
Flash Video
Tabelle 38: Getestete Video Codecs und Testresultate.
Seite 45
Audioformat
Wiedergabe möglich
AIFF
MP3
OGG
M4A
MP2
AU
WAV
AC3
MKA
AAC
AMV
Tabelle 39: Getestete Video Codecs und Testresultate.
Bildformat
Wiedergabe möglich
JPG
PNG
GIF
(nicht animiert)
Tabelle 40: Getestete Audio Codecs und Testresultate.
Seite 46
5
Testkonzept
Die Gesamt-Lösung besteht aus mehreren Komponenten. Nebst den neu entwickelten Teilen
Webapplikation und Streaming-Server ist auch der Fernseher Teil des Systems. Sowohl die einzelnen
Komponenten selbst, als auch das Zusammenspiel muss getestet werden.
5.1
Unit-Tests
Als Unit-Testframework wird JUnit (Version 4.12) eingesetzt.
Modul: Rest
Die REST Schnittstelle wurde nicht mit Unit-Tests abgedeckt. Dass die REST Schnittstelle fehlerfrei
funktioniert, hat sich gezeigt, als das CMS Aktionen auslöste und die erwarteten Resultate zurückerhalten hat.
Modul Renting
Die meiste Logik steckt im Modul Renting. Dieses Modul ist auch vollständig mit UNIT-Tests abgedeckt. Die Datenbank zu Speicherung von Task wird mit einer In-Memory Datenbank (H2 Version
1.4.185) simuliert.
Modul: Streaming
Im Streaming-Modul wurden einzelne Komponenten getestet. Die externen Klassen, die von der
Library zur Verfügung gestellt werden, sind für die Tests mit dem Mocking-Framework Mockito (Version 2.0.12-beta) abgebildet.
SocketApplication
Die neu erstellten Funktionen in der SocketApplication sind vollumfänglich durch Testfunktionen
abgedeckt.
5.2
Integrationstests
Die Integration aller Komponenten ist manuell getestet. Im Anhang 12.3 sind alle relevanten Tests
aufgeführt. Diese wurden auch beim Abnahmetest mit dem Kunden durchgeführt und für funktionstüchtig erklärt.
Seite 47
6
Ausblick
6.1
Netzwerk und CMS überarbeiten
Aktuell ist der Streaming-Server aus dem Gäste-Netz erreichbar. Dies ist ein Sicherheitsrisiko. Jeder
Gast hat die Möglichkeit eine REST-Anfrage an den Streaming-Server zu senden. Diese Sicherheitslücke kann mit wenig Aufwand geschlossen werden. Die folgenden Kapitel zeigen die nötigen Schritte
auf.
6.1.1
Netzwerk
Der Streaming-Server darf nur im Streaming-Netz Angeschlossen sein. Der CMS Server muss zusätzlich auch noch im Streaming-Netz sein, damit dieser REST-Anfrage an den Streaming-Server senden
kann.
Abbildung 39: Überarbeitetes Netzwerkdiagramm
6.1.2
CMS
Die REST-Anfragen an den Streaming-Server werden zurzeit mit JavaScript direkt vom Gerät des
Gastes an den Streaming-Server gesendet. Dies muss geändert werden, sodass der Client die Anfragen an Wordpress sendet. Anschliessend muss Wordpress den Aufruf an das REST-Interface der
Streaming-Applikation gemäss Abbildung 40 weiterleiten.
Abbildung 40: Ablauf der überarbeiteten Aufrufreihenfolge
Seite 48
7
Bekannte Fehler
Event-Notifikation wird nicht gemeldet
Wenn der erste Stream für einen Fernseher gestartet wird, so registriert sich der Control Point beim
AV Transport Service des Renderers als Event-Listener. Ab diesem Zeitpunkt wird der StreamingServer über die Änderungen der Zustandsvariable „LastChange“ informiert.
Somit kann der Streaming-Server auch auf Benutzerinteraktionen mittels TV-Fernbedienung reagieren. Sobald der letzte Stream gestoppt wird, wird der Control Point auch wieder auf dem Device als
Listener abgemeldet.
Teilweise werden die Notifikationen aber vom Streaming Server nicht verarbeitet.
Diese Problem konnte reproduziert werden, indem dass der Streaming-Server beendet wurde, ohne
dass er sich bei den Devices abmelden konnte. In dieser Situation hat das Device Listener in seiner
Liste, die nicht mehr erreichbar sind. Wenn der Streaming-Server erneut gestartet wird und der erste
Stream wieder einen Subscribe-Request auslöst, kommen die Notifikationen zwar noch an, jedoch
können sie nicht mehr einem Device zugeordnet werden.
Die Lösung für dieses Problem ist, dass wenn der Streaming-Server neugestartet wird, auch alle
Renderer neu gestartet werden sollten. Nur so kann sichergestellt werden, dass die Listener-Liste
beim Start des Streaming-Servers leer ist.
Hochladen von Filmen
Das Hochladen von Filmen über HTTP ist zu langsam. Es wird empfohlen Secure Copy (SCP) für das
Hochladen zu verwenden.
Seite 49
8
Fazit
Zu Beginn dieser Arbeit wurden existierende Media-Server evaluiert mit dem Ziel, eine existierende
Applikation anpassen zu können. Keiner dieser Media-Server hatte aber eine API und war zugleich
auch frei verfügbar. Deshalb wurde eine eigene Software entwickelt, wobei für die UPnPImplementierung eine Library benutzt wurde.
Die umgesetzte Anwendung entspricht mehrheitlich den Zielsetzungen aus der Einleitung. Hardwareunabhängigkeit ist gegeben. Jedes Gerät, das Medien wiedergeben kann und UPnP-fähig ist, kann
über die Software gesteuert werden. Die Webapplikation wurde durch das „Video on Demand“-Modul
erweitert. Starten, Stoppen und Pausieren sind implementiert. Auch das Wechseln des Medieninhalts
ist möglich. Für die Usability und das Design dienten die marktführenden Streaming-Anbieter als
Orientierung. Jedoch wurden keine Usability- und Akzeptanztests für die Implementierung durchgeführt. Die Robustheit des Systems wird mit Unit-Tests und manuellen Integrationstests sichergestellt.
Aufgrund der fehlenden UPnP-Unterstützung des Hotel-Fernsehers wird aber, entgegen der Anforderung, eine Settop-Box benötigt.
Im Nachhinein wäre die Pflege der Filme anders gestaltet worden. Durch die starke Bindung an
Wordpress und das Plugin „ACF“ kann der Streaming-Server nicht einfach in einem anderen Kontext
benutzt werden. Eine bessere Idee ist die Filmbeschreibungen auf dem Streaming-Server in einer
Datenbank zu verwalten und über die REST-API zugänglich zu machen.
Ein anderer Punkt ist die unidirektionale Kommunikation von Client zu Streaming-Server. Wenn ein
Stream, beispielsweise via Fernbedienung, gestoppt wird, so erfährt dies der Client erst, wenn er die
Positionsinformation mit dem Streaming-Server abgleicht. Ein anderer Ansatz wäre der Einsatz von
Websockets. Dies würde bidirektionale Kommunikation ermöglichen und somit den Zustand des
Clients stets mit dem des Streaming-Servers konsistent halten.
Auch wenn es Verbesserungspotential gibt, die beiden Anwendungsfälle Film mieten und abspielen,
sowie eigene Inhalte wiedergeben, sind implementiert. Der Abnahmetest wurde am 3. August 2015
bei hotelplus vor Ort erfolgreich durchgeführt und die Arbeit wurde vom Kunden akzeptiert.
Seite 50
9
Abkürzungsverzeichnis
Abkürzung
Bedeutung
CDS
CMS
Content Directory Service
Content Management System /
Connection Manager Service
Control Point
Device Description Document
Dynamic Host Configuration Protocol
Digital Living Network Alliance
Digital Media Controller
Digital Media Player
Digital Media Renderer
Digital Media Server
Hypertext Markup Language
Hypertext Transfer Protocol
Internet Gateway Device
Internet Protocol
Java Persistence API
Local Area Network
Media Access Control
Property Management System
Redundan Array of Independent Disks
Representational State Transfer
Subscription Identifier
Simple Object Access Protocol
Simple Service Discovery Protocol
Transmission Control Protocol
UPnP Device Architecture
User Datagram Protocol
Universal Product Code
Universal Plug and Play
Universal Plug and Play Audio / Video
Uniform Resource Identifier
Uniform Resource Locator
Uniform Resource Name
Universally Unique Identifier
Wide Area Network
Extensible Markup Language
CP
DDD
DHCP
DLNA
DMC
DMP
DMR
DMS
HTML
HTTP
IGD
IP
JPA
LAN
MAC
PMS
RAID
REST
SID
SOAP
SSDP
TCP
UDA
UDP
UPC
UPnP
UPnP AV
URI
URL
URN
UUID
WAN
XML
Seite 51
10
Ehrlichkeitserklärung
Hiermit bestätigen die Autoren, diese Arbeit ohne fremde Hilfe und unter Einhaltung der gebotenen
Regeln erstellt zu haben.
Joël Dubois
Ort, Datum Unterschrift
Fabrice Thut
Ort, Datum Unterschrift
Seite 52
11 Literaturverzeichnis
[1] „heise.de,“ [Online]. Available: http://www.heise.de/netze/artikel/Haendler-und-Verbraucher223844.html. [Zugriff am 12 08 2015].
[2] „rfc-base.org,“ [Online]. Available: http://www.rfc-base.org/rfc-3927.html. [Zugriff am 10 08 2015].
[3] R. Spenneberg, „Linux-Magazin,“ 10 08 2015. [Online]. Available: http://www.linuxmagazin.de/Ausgaben/2013/01/Sicherheit.
[4] „upnp.org,“ [Online]. Available: http://upnp.org/about/what-is-upnp/. [Zugriff am 10 08 2015].
[5] „upnp.org,“ [Online]. Available: http://upnp.org/sdcps-and-certification/standards/devicearchitecture-documents/. [Zugriff am 10 08 2015].
[6] „UPnP InternetGatewayDevice,“ [Online]. Available: http://upnp.org/specs/gw/UPnP-gwInternetGatewayDevice-v2-Device.pdf. [Zugriff am 11 08 2015].
[7] „upnp-hacks.org,“ [Online]. Available: http://www.upnp-hacks.org/igd.html. [Zugriff am 11 08
2015].
[8] „upnp.org,“ [Online]. Available:
http://upnp.org/resources/documents/UPnP_UDA_tutorial_July2014.pdf. [Zugriff am 10 08 2015].
[9] „UPnP ConnectionManagerService,“ [Online]. Available: http://www.upnp.org/specs/av/UPnP-avConnectionManager-v3-Service-20101231.pdf. [Zugriff am 10 08 2015].
[10] „UPnP Device Architecture v2.0,“ [Online]. Available: http://upnp.org/specs/arch/UPnP-archDeviceArchitecture-v2.0.pdf. [Zugriff am 10 08 2015].
[11] „UPnP AV Architecture,“ [Online]. Available: http://www.upnp.org/specs/av/UPnP-avAVArchitecture-v2-20101231.pdf. [Zugriff am 10 08 2015].
[12] „UPnP AVTransport v3,“ [Online]. Available: http://www.upnp.org/specs/av/UPnP-av-AVTransportv3-Service-20101231.pdf. [Zugriff am 10 08 2015].
[13] „dlna.org,“ [Online]. Available: http://www.dlna.org/about/organization/. [Zugriff am 10 08 2015].
[14] „DLNA Guidelines Part 1-1,“ [Online]. Available: http://www.dlna.org/guidelines/. [Zugriff am 10 08
2015].
[15] „support.google.com,“ [Online]. Available:
https://support.google.com/youtube/answer/1722171?hl=de. [Zugriff am 11 08 2015].
[16] „tomshardware.com,“ [Online]. Available: http://www.tomshardware.com/charts/enterprise-hddcharts/-01-Read-Throughput-Average-h2benchw-3.16,3373.html. [Zugriff am 11 08 2015].
[17] „hotel-lexikon.wikia.com,“ [Online]. Available: http://hotellexikon.wikia.com/wiki/PMS_Property_Management_System. [Zugriff am 13 08 2015].
[18] „wikipedia,“ [Online]. Available: https://de.wikipedia.org/wiki/Content-Management-System.
[Zugriff am 13 08 2015].
[19] „ACF,“ [Online]. Available: http://www.advancedcustomfields.com/resources/code-examples/.
[Zugriff am 11 08 2015].
[20] „google.com,“ [Online]. Available: https://code.google.com/p/plex-api/w/list. [Zugriff am 12 08
2015].
Seite 53
[21] „Github.com/4thline,“ [Online]. Available:
https://github.com/4thline/cling/blob/206fd06b551c60151e2c785cd8b2aa45a9a0a54b/
core/src/manual/advanced/transports.xhtml. [Zugriff am 11 08 2015].
[22] „samsung.com,“ [Online]. Available:
http://downloadcenter.samsung.com/content/UM/201502/20150209142210516/EC690EU_Install-Guide-00DEU-0128.pdf. [Zugriff am 11 08 2015].
[23] „raspberrypi.org,“ [Online]. Available:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/README.md. [Zugriff am 11 08
2015].
[24] „openelec.tv,“ [Online]. Available: http://openelec.tv/get-openelec. [Zugriff am 11 08 2015].
[25] „leawo.com,“ [Online]. Available: http://www.leawo.com/free-mac-videoconverter/index.html?lang=de_appstore. [Zugriff am 12 08 2015].
[26] „wikipedia,“ [Online]. Available: https://de.wikipedia.org/wiki/Xvid. [Zugriff am 11 08 2015].
[27] „netzwelt.de,“ [Online]. Available: http://www.netzwelt.de/dateierweiterung/ts.html. [Zugriff am 11
08 2015].
[28] „wikipedia,“ [Online]. Available:
https://upload.wikimedia.org/wikipedia/de/0/08/Upnp_architecture.svg. [Zugriff am 10 08 2015].
Seite 54
12 Anhang
12.1 REST-API Beschreibung
Die Beschreibungen der Parameter sind entweder erklärt oder beziehen sich auf die Tabelle 11: Legende für Filmbeschreibung beziehungsweise Tabelle 10.
12.1.1 Users
Basic-Url: https://host/users
URL
Request
Methode
Parameter
GET
Beschreibung
Rückgabewert
Abrufen aller Benutzerordner.
Alle Benutzerordner in einem JSON Array.
[2]
0: "hansbeispiel"
1:
"petermeier"
Basic-Url: https://host/users/{name}/
URL
Request
Methode
POST
DELETE
Parameter
user
Name des zu erstellenden
Benutzerordners
ip_address
IP-Adresse des Renderers im
Zimmer des Gastes
user
Name des zu löschenden
Benutzerordners
ip_address
Zimmer des Gastes
Beschreibung
Rückgabewert
Erstellen eines neuen
Benutzerordners.
Status: 201 Created
Benutzerordner erstellt.
Status: 304 Not Modified
Benutzerordner nicht erstellt.
Löschen eines Benutzerordners.
Status: 410 Gone
Benutzerordner gelöscht.
Status: 304 Not Modified
Benutzerordner wurde nicht gelöscht.
Status: 417 Expectation Failed
Auf dem Server gab es eine Exception.
Seite 55
URL
Request
Methode
private
POST
private
DELETE
private
GET
rent_movie
POST
rent_movie
POST
Parameter
movie_name movie_title
file
movie_filename_
period
movie_rentduration
ip_address
Zimmer des Gastes
movie_name movie_filename_
Beschreibung
Rückgabewert
Hochladen eines eigenen
Medieninhalts auf den
Streaming Server.
Status: 201 Created
Medieninhalt wurde hochgeladen auf den Server und ist verfügbar.
Status: 403 Forbidden
Medieninhalt wurde nicht hochgeladen auf den Server.
Status: 404 Not Found
Exception wurde auf dem Server geworfen.
Löschen eines privaten
Medieninhalts auf dem
Streaming Server.
Auflisten aller Medieninhalte, welcher der User selbst
hochgeladen hat.
folder_name movie_id
period
movie_rentduration
ip_address
IP Renderer
guest_id
user
price
movie_cost
folder_name movie_id
period
movie_rentduration
ip_address
IP Renderer
guest_id
user
price
movie_cost
Mieten eines Films.
Status: 204 No Content
Kein Medieninhalt ausgewählt.
Status: 410 Gone
Medieninhalt wurde gelöscht.
Exception wurde auf dem Server geworfen
Alle Dateinamen, die der Benutzer hochgeladen hat.
Status: 200 Ok
Film gemietet.
Film nicht gemietet.
Mieten eines Films.
Status: 200 Ok
Film gemietet.
Film nicht gemietet.
Seite 56
URL
Request
Methode
play_rented_movie
POST
Parameter
ip_address
IP Renderer
movie
movie_filename
Beschreibung
Rückgabewert
Abspielen eines Films.
Status: 200 Ok
Film wurde gestartet.
media_name movie_titlet
resume_movie
play_private_movie
POST
POST
ip_address
IP Renderer
ip_address
IP Renderer
movie
filename
Medieninhalt nach dem Pausieren wieder starten.
Privaten Medieninhalt starten.
Film wurde nicht gestartet.
Status: 200 Ok
Medieninhalt wurde gestartet.
Medieninhalt wurde nicht gestartet.
Status: 200 Ok
Privater Medieninhalt wurde gestartet.
Privater Medieninhalt wurde nicht gestartet.
Seite 57
12.1.2 Device
Basic-Url: https://host/device/{ipaddress}/
URL
Request
Methode
stop_movie
POST
Parameter
Beschreibung
Rückgabewert
Stoppen eines laufenden Medianinhalts.
Status: 200 Ok
Medieninhalt wurde gestoppt.
Kein Medieninhalt wird abgespielt.
pause_movie
POST
Pausieren eines laufenden Medianinhalts.
Der Renderer ist nicht erreichbar oder ein anderer Fehler ist auf dem Streaming Server
aufgetreten.
Status: 200 Ok
Medieninhalt wurde gestoppt.
mediaduration
GET
Gesamtlänge der laufenden
Wiedergabe.
aufgetreten.
Status: 200 Ok
JSON mit der Dauer des Medieninhaltes.
{
postitionLong: 3910
}
aufgetreten.
Seite 58
URL
Request
Methode
positioninfo
GET
Parameter
Beschreibung
Rückgabewert
Infos, wie viel Sekunden vom
Medieninhalt schon abgespielt
wurden.
Status: 200 Ok
JSON mit aktueller Abspielzeit.
{
postitionLong: 310
}
isactive
GET
Abfrage ob eine Wiedergabe aktiv
ist.
aufgetreten.
Status: 200 Ok
Medieninhaltsdaten als JSON.
{
mediaName: "Blutiger Auftrag - Es gibt kein Entkommen"
fileName: "deu-NOT_SAFE_FOR_WORK_EN_FR_DE_IT_ES_DUB_18974.mp4"
durationDouble: 0
durationString: null
positionInfoString: null
positionInfoDouble: 0
uri: "http://192.168.1.2:80/users/1679091c5a880faf6fb5e6087eb1b2dc/rented/deuNOT_SAFE_FOR_WORK_EN_FR_DE_IT_ES_DUB_18974.mp4"
transportState: "PLAYING"
mode: "RENTED"
}
Kein Medieninhalt läuft.
aufgetreten.
Seite 59
URL
Request
Methode
Parameter
Beschreibung
Rückgabewert
seek
POST
target
z.B.: „hh:mm:ss“
Vor- oder Zurückspulen der
Wiedergabe
Status: 200 Ok
Medieninhalt wurde gespult.
get_all_medias
GET
Alle Medieninhalte, die aktuell auf
dem Device abgespielt bzw. in der
Playlist sind.
aufgetreten.
Status: 200 Ok
Medieninhaltsdaten in einem JSON-Array.
[1]
-0: {
mediaName: "Blutiger Auftrag - Es gibt kein Entkommen"
fileName: "deu-NOT_SAFE_FOR_WORK_EN_FR_DE_IT_ES_DUB_18974.mp4"
durationDouble: 0
durationString: null
positionInfoString: null
positionInfoDouble: 0
uri: "http://192.168.1.2:80/users/1679091c5a880faf6fb5e6087eb1b2dc/rented/deuNOT_SAFE_FOR_WORK_EN_FR_DE_IT_ES_DUB_18974.mp4"
transportState: "PLAYING"
mode: "RENTED"
}
Kein Medieninhalt läuft.
aufgetreten.
Seite 60
12.1.3 Movies
Basic-Url: https://host/movies/
URL
Request Methode
Parameter
Beschreibung
Rückgabewert
POST
movie_name
Hochladen eines Films.
Status: 201 Created
Film wurde hochgeladen auf den Server und ist verfügbar.
file
Status: 403 Forbidden
Film wurde nicht hochgeladen auf den Server.
DELETE
Status: 204 No Content
Kein Film ausgewählt.
Status: 410 Gone
Medieninhalt wurde gelöscht.
Löschen eines Benutzerordners
Film wurde nicht gefunden / nicht vorhanden.
GET
Exception wurde auf dem Server geworfen
Liste der Ordner.
Abrufen aller Filmeordner auf dem Client.
[4]
Seite 61
0:
"AmericanSniper"
1:
"NOT_SAFE_FOR_WORK "
12.2 Device Description Document
Device Description von Raspberry Pi 2
Date: Thu, 01 Jan 1970 00:00:24 GMT
Content-Length: 3342
Content-Type: text/xml; charset="utf-8"
Server: UPnP/1.0 DLNADOC/1.50 Kodi
<?xml version="1.0" encoding="UTF-8"?>
<root configId="4449618" xmlns="urn:schemas-upnp-org:device-1-0" xmlns:dlna="urn:schemasdlna-org:device-1-0">
<specVersion>
<major>1</major>
<minor>1</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName>Kodi (OpenELEC)</friendlyName>
<manufacturer>XBMC Foundation</manufacturer>
<manufacturerURL>http://kodi.tv/</manufacturerURL>
<modelDescription>Kodi - Media Renderer</modelDescription>
<modelName>Kodi</modelName>
<modelNumber>15.0-RC2 Git:0aa930b</modelNumber>
<modelURL>http://kodi.tv/</modelURL>
<UDN>uuid:11b12bb8-9d0a-2f44-1e7b-bfaf71b6cd0d</UDN>
<presentationURL>http://192.168.1.103/</presentationURL>
<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">DMR-1.50</dlna:X_DLNADOC>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<width>256</width>
<height>256</height>
<depth>8</depth>
<url>/icon256x256.png</url>
</icon>
<icon>
<width>120</width>
<height>120</height>
<depth>8</depth>
</icon>
<icon>
<width>48</width>
<height>48</height>
<depth>8</depth>
</icon>
<icon>
<width>32</width>
Seite 62
<height>32</height>
<depth>8</depth>
</icon>
<icon>
<width>16</width>
<height>16</height>
<depth>8</depth>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
<SCPDURL>/AVTransport/11b12bb8-9d0a-2f44-1e7b-bfaf71b6cd0d/scpd.xml</SCPDURL>
<controlURL>/AVTransport/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/control.xml</controlURL>
<eventSubURL>/AVTransport/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/event.xml</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
<SCPDURL>/ConnectionManager/11b12bb8-9d0a-2f44-1e7b-bfaf71b6cd0d/scpd.xml</SCPDURL>
<controlURL>/ConnectionManager/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/control.xml</controlURL>
<eventSubURL>/ConnectionManager/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/event.xml</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
<SCPDURL>/RenderingControl/11b12bb8-9d0a-2f44-1e7b-bfaf71b6cd0d/scpd.xml</SCPDURL>
<controlURL>/RenderingControl/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/control.xml</controlURL>
<eventSubURL>/RenderingControl/11b12bb8-9d0a-2f44-1e7bbfaf71b6cd0d/event.xml</eventSubURL>
</service>
</serviceList>
</device>
</root>
Snippet 9: Device Description Document von UPnP-Device
Seite 63
12.3 Abnahmetests
12.3.1 Backend
Pflege von IP-Adresse zu Zimmer Zuordnungen
Voraussetzung
Der Benutzer ist mittels Admin-Account im „wp-admin“-Bereich
eingeloggt und hat die Seite „TV-to-Room“ geöffnet.
Testfälle
Erwartetes Resulat
Der Benutzer erfasst ein neues
Zimmer mit einer validen IPv4Adresse.
Die Seite wird neu geladen. Ein
Banner mit einer Information
wird sichtbar und der Eintrag ist
in der Tabelle ergänzt.
Reales Resultat
Der Benutzer erfasst ein neues
Zimmer mit einer ungültigen IP4v- Banner weist auf die ungültige
Adresse.
IP-Adresse hin. Der Eintrag ist
nicht in der Tabelle ergänzt.
Der Benutzer bearbeitet ein
existierendes Zimmer. Er gibt
eine valide IPv4-Adresse ein.
Banner mit einer Information
wird sichtbar und der Eintrag ist
in der Tabelle aktualisiert.
Der Benutzer bearbeitet ein
existierendes Zimmer. Er gibt
eine ungültige IPv4-Adresse ein.
Banner weist auf die ungültige
IP-Adresse hin. Der Eintrag ist
nicht in der Tabelle aktualisiert.
Seite 64
Pflege von Film-Einträgen
Voraussetzung
Der Benutzer ist mittels Admin-Account im „wp-admin“-Bereich
eingeloggt und hat im Menüpunkt „Pages“ die Seite „Video on
Demand“ geöffnet.
Testfälle
Erwartetes Resulat
Reales Resultat
Der Benutzer erfasst einen
Der Film-Eintrag wird im Frontneuen Film mit allen erforderliend unter der entsprechenden
chen Angaben gemäss vordefiSprache angezeigt.
niertem Format (Bildgrösse, etc.),
insbesondere muss der Filename
konsistent mit dem Filename auf
dem Datenserver übereinstimmen und die movie_id muss über
alle Einträge eines Films in
verschiedenen Sprachen dieselbe sein.
Der Benutzer erfasst einen
neuen Film mit allen erforderlichen Angaben aber nicht gemäss
vordefiniertem Format (Bildgrösse, etc.) oder falschem Filename.
Der Film-Eintrag wird im Frontend unter der entsprechenden
Sprache angezeigt. Optische
Unschönheiten können aber
auftrete oder der Film wird nicht
abgespielt, da der Pfad nicht
gefunden wird.
12.3.2 Frontend
Allgemeine Voraussetzung für die Benutzung von Video-on-Demand ist, dass Javascript aktiviert ist.
Video on Demand als Guest-Benutzer
Voraussetzung
Der Benutzer ist nicht als Hotelgast authentifiziert sondern ruft die
Landing-Page als Guest-Benutzer auf.
Testfälle
Erwartetes Resulat
Der Gast-Benutzer möchte Video-on-Demand nutzen.
Der Link ist nicht sichtbar, da er
kein Hotelgast ist.
Der Gast-Benutzer gibt den
Permanten-Link direkt ein und
versucht Video-on-Demand zu
nutzen.
Der Benutzer wird wieder auf die
Landing-Page geleitet.
Reales Resultat
Seite 65
Responsivness
Voraussetzung
Der Benutzer ist authentifiziert und hat die Seite Video-onDemand geöffnet.
Testfälle
Erwartetes Resulat
Der Benutzer verändert das
Browserfenster oder benutzt
verschiedene Geräte mit unterschiedlichen Auflösungen.
Wenn das Browserfenster auf
einem Desktop in Vollbild geöffnet ist, so werden 4 FilmEinträge pro Zeile angezeigt. Bei
Browserfenster in Grösse eines
Tablets sind es 2 Einträge und
bei einem Smartphone 1 Eintrag
pro Zeile.
Reales Resultat
Movie-Details
Voraussetzung
Der Benutzer ist authentifiziert und hat die Seite Video-onDemand geöffnet.
Testfälle
Erwartetes Resulat
Reales Resultat
Der Gast möchte mehr Details zu Der Gast klickt auf einen Film,
einem Film erfahren.
ein Popup öffnet sich und zeigt
mehr Informationen an.
Movie mieten
Voraussetzung
Der Benutzer ist authentifiziert und hat die Seite Video-on-Demand
geöffnet. Danach hat er auf einen beliebigen, noch nicht gemieteten Film geklickt und sieht das Popup-Fenster.
Testfälle
Erwartetes Resulat
Der Gast möchte einen Film
mieten. Dafür klickt er auf den
Button "Rent“ und bestätigt dies
anschliessend.
Das Popup schliesst sich wieder
und der Film wird als gemietet
markiert. Die Ausleihe ist im LogFile „info.log“ auf dem
Streamingserver sichtbar.
Reales Resultat
Seite 66
Movie abspielen
Voraussetzung
Der Benutzer ist authentifiziert und hat die Seite Video-onDemand geöffnet. Danach hat er auf einen beliebigen, bereits
gemieteten Film geklickt und sieht das Popup-Fenster.
Testfälle
Erwartetes Resulat
Der Benutzer möchte den Film
abspielen. Der Media-Client ist
eingeschaltet.
Das Popup schliesst sich wieder.
Der Film fängt an zu laufen.
abspielen. Der Media-Client ist
jedoch ausgeschaltet.
Das Popup schliesst sich wieder.
Der Film fängt nicht an zu laufen.
Ein weiteres Popup macht den
Benutzer darauf aufmerksam,
dass geprüft werden muss, ob
der Client eingeschaltet ist und
allfällig die Source korrekt gewählt ist.
an einer bestimmten Position
fortsetzten (Seek). Dafür klickt er
auf dem Zeitstrahl eine beliebige
Position an.
Der Film wird vor – bzw. zurückgespuhlt und je nach vorherigem
Zustand entweder direkt abgespielt oder noch pausiert.
Reales Resultat
Der Film wird pausiert. Nach
kurz unterbrechen und wählt
einem Klick auf Play läuft er an
somit den Pause-Button im
derselben Stelle weiter.
Player. Um den Film weiterlaufen
zu lassen klickt er anschliessend
auf den Play-Button im Player.
Der Benutzer möchte einen Film
beenden. Dafür klickt er auf den
Stop-Button im Player.
Der Film wird beendet. Wenn
vorher bereits Medien abgespielt
wurden, werden diese gesucht
und wie in einem Stack abgespielt.
Seite 67
Eigene Files
Voraussetzung
Der Benutzer ist authentifiziert und hat die Seite Video-onDemand geöffnet. Im Tab-Menü ist der Punkt „Eigene Files“
angewählt.
Testfälle
Erwartetes Resulat
Der Benutzer möchte eine eigene
Datei hochladen. Er wählt eine
Datei mit korrektem Filetyp (Bild,
Video oder Musik).
Der Fortschrittsbalken fängt an
zu laufen. Bei 100% wird der
Fortschrittsbalken ausgeblendet
und die Datei ist bei den Files
sichtbar.
Reales Resultat
Der Benutzer möchte eine eigene Der Benutzer wird mittels Popup
Datei hochladen. Er wählt eine
informiert, dass der Filetyp nicht
Datei mit nicht korrektem Filetyp gültig ist.
(Bild, Video oder Musik).
Der Benutzer möchte einen
Der Upload bricht ab, der Fortaktiven Upload abbrechen. Dafür schrittsbalken wird ausgeblendet.
klickt er auf das Symbol unterhalb
vom Fortschrittsbalken.
Der Benutzer möchte ein eigenes
File abspielen. Dafür klickt er auf
den Button „Play“ vom jeweiligen
File.
Die Media-Datei wird auf dem
Client wiedergegeben sofern
dieser eingeschaltet ist, ansonsten wird ein Popup eingeblendet.
Der Benutzer möchte ein eigenes Die Seite wird neu geladen, das
File löschen. Dafür klickt er beim File ist nicht mehr verfügbar.
jeweiligen File auf das Symobl
„X“ und bestätigt anschliessend
den Löschvorgang.
12.4 Mailverkehr mit Herrn Dr. Dominik Gruntz über Probleme mit Cling Library
12.4.1 Anfrage vom 5 Mai 2015 um 13:57 Uhr.
Guten Tag Herr Gruntz
Wir arbeiten zurzeit an der Thesis.
Ziel ist es, mittels SmartPhone eine REST-API anzusprechen und Dateistreams auf Fernseher oder
andere MediaRenderer zu starten.
Dafür nutzen wir eine Library, die uns den UPnP-Stack abbildet http://4thline.org/projects/cling/
Als Applikationsframework nutzen wir Spring.
Das Problem ist nun, dass Cling beim Starten eine Exception wirft:
: Unable to initialize network router:
org.fourthline.cling.transport.spi.InitializationException:
Failed to set modified URLStreamHandlerFactory in this environment.
Seite 68

Technischer Bericht Bachelor Thesis

Transcription

Similar documents

Die Noachitischen Gebote in drei Religionen

PG483 - Ubiquitous Media Endbericht

Book of Abstracts - JGU Blogs - Johannes Gutenberg