Current Page: Greybox » Authoring » Course ID: medieninformatik » Modules » Module ID: mmserver » Learning Units » Unit ID: 010intro
Last Modified:Tuesday, 2015-05-05 - 08:09:06
 
Tools: ValidatePreview XML Preview HTML Preview PDF
Alternative: Printable HTML

 

Learning Unit ID: 010intro
Title: Einführung und Grundlagen
Abstract: Eine Infrastruktur, die den interaktiven Transfer multimedialer Inhalte von hoher Qualität für eine Massenpublikum ermöglicht, stellt bezüglich erforderliche Bandbreite und Speicherkapazität Ansprüche, die von heutigen Netzwerken wie das Internet oder dem Kabelfernsehen noch nicht erfüllt werden können. Eine Schlüsselrolle spielen die Multimedia Server mit ihrem speziellen Anforderungsprofil. Für eine Multimedia-on-Demand Umgebung gibt es unterschiedliche Servicetypen, die sich durch den Grad der geboten Interaktivität und ihrer Implementierbarkeit von einander unterscheiden. Um die Effektivität eines Multimedia Servers beurteilen zu können, werden eigene Performancemaße definiert.
 
Status: content final - to do: wie Lu Zipf Version: 2005-10-10
History: 2005-10-10 (Thomas Migl): Abstract hinzugefügt
2005-09-08 (Thomas Migl): LOD1 fertiggestellt, Quellen importiert
2005-09-02 (Thomas Migl): LOD2 fertiggestellt, LOD1 begonnen
2005-07-18 (Thomas Migl): LU angelegt

Author
Author 1: Thomas Migl E-Mail: migl@ims.tuwien.ac.at
Author 2: (empty) E-Mail: (empty)
Author 3: (empty) E-Mail: (empty)
Author 4: (empty) E-Mail: (empty)
Author 5: (empty) E-Mail: (empty)
Organization: Technische Universität Wien; Institut für Softwaretechnik und Interaktive Systeme; Arbeitsgruppe für Interaktive Multimediale Systeme; http://www.ims.tuwien.ac.at/

Content

Einleitung/ Motivation

1

Motivation

  • Ziel ist
    • Infrastruktur zur interaktiven Übertragung von multimedialen Daten
  • Es müssen Besonderheiten multimedialer Daten berücksichtigt werden
    • Multimediale Dateien sind im Durchschnitt sehr groß
    • Sie müssen kontinuierlich präsentiert werden
  • Anforderung an Infrastruktur
    • Übertragung von Video und Audio in hoher Qualität
      • Trotz hoher Datenrate muss kontinuierliche Präsentation gewährleistet bleiben
    • Bewältigung von Echtzeitanwendungen
    • Möglichkeit der Client-seitigen Interaktion
  • Daraus ergeben sich für Netzwerk und Server spezielle Anforderungen
    • Multimediales Netzwerk
      • Hohe Bandbreite
    • Multimediale Server
      • Hoher Datendurchsatz
      • Hohe Speicherkapazität
      • QoS

2

Motivation

Heutige Netzwerke bieten bereits die Möglichkeit, multimediale Daten wie Videos, Audiodaten und Bilder problemlos jedem Enduser zur Verfügung zu stellen. Bei Echtzeitanwendungen kommt es allerdings zu Problemen, da Audio und Videodaten kontinuierlich übertragen werden müssen, um den Clients eine kontinuierliche Wiedergabe bieten zu können. Auch stellt die Bereitstellung und Übertragung von Video und Audio in hoher Qualität und deren interaktive Nutzung bis dato nicht da gewesene Anforderungen an Netzwerkbandbreite, Serverdatendurchsatz und Speicherbedarf, die von heutigen Netzwerken nicht zu meistern sind. Für ein Multimedia-On-Demand System muss daher eine neue Infrastruktur konzipiert werden. Eine wichtige Rolle dabei spielen die darin integrierten Server, die sich wesentlich von herkömmlichen Datenservern unterscheiden.

Überblick Lerneinheit

In dieser Lerneinheit wird einleitend ein Zukunftsszenario einer Multimedia-On-Demand Infrastruktur skizziert und aufgezeigt, auf welchen bereits heute vorhandenen Netzwerken diese aufgebaut sein könnte. Anschließend wird ein Überblick über das Anforderungsprofil eines Multimedia Servers gegeben. Zum Verständnis der für ein Multimedia-On-Demand Netzwerk nötigen Strategien werden die Eigenschaften eines Requests untersucht und die verschiedenen On-Demand-Service-Typen erläutert. Abschließend werden die Maße zur Performancebewertung eines Multimedia Servers vorgestellt.

Zukunftsszenario - Kommunikationsinfrastruktur

1

Zukunftsszenario

Mögliche Infrastruktur zur Verteilung von Multimedialen Inhalten

2

Zukunftsszenario

Die Abbildung zeigt eine mögliche Infrastruktur zur Verteilung multimedialer Inhalte, wie sie in naher Zukunft realisiert sein könnte. Das Herz dieser Infrastruktur ist ein High-speed Netzwerk. Jede Benutzerin und jeder Benutzer kann mittels beliebigem Endgerät ( PC, PDAs, , Workstation am Arbeitsplatz, eine mit dem Fernsehgerät verbundene Set-Top Box) auf die verschiedenen Anwendungen zugreifen. Die gebotenen Anwendungen bieten dabei dem Benutzer ein hohes Maß an Interaktivität: Es sind Funktionen wie schneller Vor- und Rücklauf, Pause, Wiederaufnahme nach Unterbrechung der Wiedergabe (resume-function) Schnellsuche und der Zugriff auf beliebige Stellen möglich. Auch diverse Editierfunktionen (Filtern, Schneiden etc) werden geboten.

Mögliche Infrastruktur zur Verteilung von Multimedialen Inhalten

Anwendungszenarien

1

Video-On-Demand

Video-On-Demand Service eines Fernsehkabelbetreibers

World Wide Web


Multimedia-On-Demand Service via Internet

 

2

auto

Im Folgenden betrachten wir jene zwei Szenarien, welche sich aus heutiger Sicht in naher Zukunft durchsetzen werden. Das erste Modell ist eine Erweiterung des heutigen Kabelfernsehens. Ausgerüstet mit einer Set-Top Box und Fernbedienung ist es dem Client möglich, individuelle Requests an den Provider zu schicken. Das zweite Szenario nutzt die Infrastruktur des World Wide Web.

Video-On-Demand

Dieses Szenario basiert auf dem Konzept von Kabelfernsehbetreibern und Telefonanbietern. Der Client greift mittels Set-Top Box und Fernbedienung auf multimediale Daten zu. Die Set-Top Box ersetzt hier den Videorekorder, die Fernsteuerung ermöglicht das interaktive Kommunizieren mit dem Multimedia-Server (inklusive den klassischen VCR Funktionen). Der Client kann beliebige Spielfilme, diversen Nachrichten- und Informationssendungen abrufen, in Teleshops einkaufen, netzbasierte Anwendungen nutzen (zum Beispiel online-Spiele) etc.

Video-On-Demand Service eines Fernsehkabelbetreibers

World Wide Web

In diesem Szenario fordert der Client multimediale Inhalte via Internet an. Bei der Konzeption eines konkreten Service-Modells ist zu beachten, dass die möglichen Benutzer-Endgeräte von äußerst unterschiedlicher Komplexität sein können. PDAs zum Beispiel verfügen nur über geringe lokale Pufferspeicher, auch ist dessen Rechenleistung im Vergleich zu PCs sehr gering, was vor allem bei Echtzeitanwendungen (zum Beispiel Dekodierung eines Videostreams) problematisch sein kann.


Multimedia-On-Demand Service via Internet

Multimedia Server Anforderungsprofil

1

Anwendungsanforderungen

  • Zeitsensibilität (Time Sensitivity)
    • Multimediale Daten wie Video und Audio erfordern kontinuierliche Wiedergabe
      • Für Echtzeitanwendungen muss Kontinuität der Datenübertragung Server/Client gewährleistet sein
        • Gebotene Gewährleistung wird als Quality of Service (QoS) bezeichnet
  • Leistungsfähigkeit von Client, Netzwerk und Server
    • Beispiele Anforderung an Infrastruktur
      • Einfache Video-On-Demand Anwendung
        • Kontinuierliche Datenübertragung
        • VCR Steuerungsbefehle
      • Komplexe Anwendungen
        • Zusätzlich Anforderungen
          • Beispiel - Clientseitige Präsentation bestehend aus unterschiedlichen Mediensegmenten, die gleichzeitig geliefert werden müssen

Erfordernisse für den geschäftlichen Einsatz

  • Skalierbarkeit in Bezug auf
    • Datendurchsatz
    • Anzahl der Clients
  • Zuverlässigkeit
    • Multimedia Server muss gegen einen eventuellen Datenausfall gewappnet sein
      • Sicherungstechniken siehe Lerneinheit RAID
  • Dynamische Angleichung an Arbeitslast
    • Geeigneter Strategien müssen System an jeweilige Belastung anpassen
      • Belastung eines Multimedia Systems variiert mit der Zeit
        • Verschiedene Daten werden unterschiedlich oft angefordert

Anforderungen an die Architektur

  • Topologie
    • Topologie eines Multimedia Servers hat einen entscheidenden Einfluss auf dessen Performance
  • Performance der Kosten
    • Bereits ein kleiner Anstieg der Servereffektivität kann eine hohe Reduktion der Kosten bewirken
      • Beispiel effektive Kostenreduktion mittels Caching
        • Caching von populären Videos reduziert teuren Disk Speicherplatz

2

auto

Für Multimedia Servern ergibt sich auf Grund der Besonderheiten der Daten, die sie verwalten, und den zusätzlichen Anforderungen, die sich aus neuen Servicemodellen ergeben, ein speziellen Anforderungsprofil, das sich von jenem konventioneller Server deutlich unterscheidet. Im Folgenden wird ein Überblick über dieses Anforderungsprofil geboten, wobei wir hier unterscheiden in Anforderungen bezüglich Anwendungen, geschäftlicher Einsetzbarkeit und Architektur.

Anwendungsanforderungen

Zeitsensibilität (Time Sensitivity)

Multimediale Daten wie Video und Audio haben gegenüber anderen Daten die Besonderheit, dass sie kontinuierlich, dass heißt sukzessiv und ohne zeitlich aus zu setzen, präsentiert werden müssen. Für Echtzeitanwendungen ist es daher wichtig, dass die Multimedialen Daten vom Server zum Client in einer Weise übertragen werden, die eine störungsfreie Wiedergabe garantiert. Man spricht in diesem Zusammenhang von einem Quality of Service (QoS). Siehe dazu Lerneinheit Multimedia Server-Architektur und Komponenten.

Leistungsfähigkeit von Client, Netzwerk und Server

In einer Multimedia Umgebung werden neben dem Server auch spezielle Anforderungen an die gesamte Infrastruktur gestellt.

Beispiele Anforderung an Infrastruktur

Für eine einfache Video-On-Demand Anwendung muss einerseits kontinuierliche Datenübertragung gewährleistet sein, andererseits müssen VCR Steuerungsbefehle wie schneller Vor- und Rücklauf ausführbar sein. Bei komplexeren Anwendungen werden zusätzlich Anforderungen gestellt: Es soll zum Beispiel möglich sein, dass auf Clientseite aus unterschiedlichen Mediensegmenten, die gleichzeitig geliefert werden, einen eigene Präsentation zusammenstellen kann.

Erfordernisse für den geschäftlichen Einsatz

Skalierbarkeit

Ein Multimedia-On-Demand Server verwaltet eine große Anzahl an unterschiedlichen multimedialen Dateien, die ihrerseits auch wieder sehr groß sind. Es ergeben sich Datenmengen im TB/PB Bereich. Der Server muss unter Einhaltung des QoS hunderte oder auch tausende Clients gleichzeitig und unabhängig von einander bedienen können. Es ist daher wichtig, dass die Serverarchitektur skalierbar ist, und zwar skalierbar in Bezug auf Datendurchsatz und Anzahl der Clients.

Zuverlässigkeit

Um Kunden nicht unnötig zu vergraulen, muss auch ein Multimedia Server gegen einen eventuellen Datenausfall gewappnet sein. Techniken dazu werden in der Lerneinheit RAID genauer beschrieben.

Dynamische Angleichung an Arbeitslast

Ein Multimedia System wird in der Praxis nicht immer gleich belastet. Es gibt Zeiten, zu denen das System mehr belastet wird als zu anderen. Auch werden bestimmte Daten besonders oft, andere hingegen nur selten angefordert. Es sind daher spezielle Strategien notwendig, die das System an die aktuelle Belastung anpassen können.

Anforderungen an die Architektur

Topologie

Das den Multimedia Serverkomponenten zugrunde liegende Design erwirkt eine spezielle Topologie der Architektur. Die Topologie eines Multimedia Servers hat dabei einen entscheidenden Einfluss auf dessen Performance.

Performance der Kosten

Speziell in large-scale Multimedia Servers, kann ein kleiner Anstieg der Servereffektivität eine hohe Reduktion der Kosten bewirken. Zum Beispiel kann man durch Cachen von populären Videos den Bedarf an teuren Disk Speicherplatz reduzieren.

Eigenschaften eines „Request Arrival Process“

1

Request-Arrival

Multimedia-On-Demand Server Request-Response Modell

  • N... Anzahl der gespeicherten Multimedialen Dateien
  • <math> <semantics>  <mi>k</mi> <annotation encoding='MathType-MTEF'> </annotation> </semantics></math>...ist der Index der entsprechenden Datei
  • <math><semantics><mrow><msub><mi>D</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>...Spielzeitdauer der multimedialen Datei
  • <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>...Maximale Anzahl der Clients, die auf die Datei gleichzeitig zugreifen können

Ortsabhängigkeit (Spatial Locality)

  • Bestimmte Dateien werden öfters angefordert als andere
    • Beispiel elektronischer Videoverleih
      • Neue Filme werden sehr häufig verlangt, alte Filme nur selten
        • Hoher <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Wert für neue Filme
        • Geringere <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werte für alte Filme

Beschreibung der Wahrscheinlichkeitswerte

  • Diagramm der Verteilung der Wahrscheinlichkeitswerte
    • für jedes Video wird ermittelt, wie hoch dessen Aufrufwahrscheinlichkeit ist
    • Dateien werden nach ihren Wahrscheinlichkeitswerten geordnet
      • Links steht das Video mit größter Aufrufwahrscheinlichkeit
      • Rechts steht Video mit geringster Aufrufwahrscheinlichkeit
  • Zipfsches Gesetz
    • Praxis zeigt, dass Verteilung der Wahrscheinlichkeitswerte Zipfschem Gesetz gehorcht
    • Aus Wahrscheinlichkeitswerte ergeben sich optimale <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werte

Anwendungen ohne Spatial Locality

  • Es gibt auch Anwendungen ohne Ortsabhängigkeit
    • Beispiel: Bilddatenbank für Radiologen
      • Patienten-Informationsdatenbank mit Röntgenbilder
        • Aufrufwahrscheinlichkeit der Bilder durch kein statistisches Gesetz berechenbar
        • Keine<math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werte Zuordnung möglich

Praktischer Nutzen

  • Erstellung einer sinnvollen Speicherhierarchie basierend auf Wahrscheinlichkeitsverteilung
    • Multimediale Dateien mit hohen <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werten eher auf schnellen (und auch teuren) Speichersystemen abgelegt
    • Dateien mit geringem <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Wert eher auf einfache, billige Speichersysteme gestellt

Zeitabhängigkeit (Temporal Locality)

  • Zeitabhängigkeit der Aufrufwahrscheinlichkeit einer Multimedialen Datei
    • Beispiel: On Demand Spielfilme
      • Multimediale Datei ist ein populärer Spielfilm
        • In den Abendstunden hohe Aufrufhäufigkeit
        • Untertags geringe Aufrufhäufigkeit

Praktischer Nutzen

  • Kenntnis der Zeitabhängigkeit ist wichtig für die Entscheidung, welches Service- und Netzwerkmodell für einen Server gewählt wird

2

Request-Arrival

Multimedia-On-Demand Server Request-Response Modell

Die Abbildung zeigt das Modell eines Multimedia-On-Demand Servers in einer Multimedia-On-Demand Retrieval Umgebung. Auf unserem Server sind N multimediale Dateien abgelegt. Jede Datei ist mit zwei Attributen versehen (<math> <semantics>  <mi>k</mi> <annotation encoding='MathType-MTEF'> </annotation> </semantics></math> ist der Index der entsprechenden Datei):

  • <math><semantics><mrow><msub><mi>D</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>...Spielzeitdauer der multimedialen Datei
  • <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>...Maximale Anzahl der Clients, die auf die Datei gleichzeitig zugreifen können.

Die Clients senden nun ihre Requests an den Multimedia-On-Demand Server (In unserer Abbildung ist exemplarisch für jeden Request angegeben, welcher Request welche Datei wünscht). Am Multimedia-On-Demand Server wird zu aller erst kontrolliert, welche Clients überhaupt berechtigt sind, auf Dateien des Servers zuzugreifen. Hat Client die Berechtigung, wird ihm vom Server gewünschte Datei zur Verfügung gestellt. Um eine möglichst störungsfreie Performance bieten zu können, ist bereits bei der Planung des Multimedia-On-Demand Servers zu beachten, dass der Request-Arrival Prozess in vielen Anwendungen Orts- und Zeitabhängigkeiten aufweisen kann.

Ortsabhängigkeit (Spatial Locality)

Eine Ortsabhängigkeit des Request-Arrival Prozesses entsteht dadurch, dass bei vielen Anwendungen bestimmte Dateien öfter angefordert werden als andere.

Beispiel Videoverleih

Als Beispiel betrachte man einen elektronischen Videoverleihshop: Man kann annehmen, dass ein momentan in allen Zeitungen gelobter Film von den Clients häufiger verlangt wird, als seine bereits in die Jahre gekommenen Vorgänger. In diesem Fall ist es zweckmäßig, diesem Video einen höheren <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Wert zuzuordnen, weniger gefragten Filmen hingegen geringere <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werte.

Beschreibung der Wahrscheinlichkeitswerte

Zur genauen Berechung der individuellen Wahrscheinlichkeitswerte geht man wie folgt vor: Es wird für jedes Video ermittelt, wie hoch die Wahrscheinlichkeit ist, dass es bei einem Request aufgerufen wird. Die Videodateien werden nun nach ihren Wahrscheinlichkeiten, beginnend mit jenem mit dem höchsten Wahrscheinlichkeitswert, geordnet. Man erhält dadurch ein Diagramm der Verteilung der Wahrscheinlichkeitswerte, wobei Videos mit hoher Aufrufwahrscheinlichkeit auf der linken, Videos mit geringer Aufrufwahrscheinlichkeit auf der rechten Seite des Diagramms aufscheinen.

Zipfsches Gesetz

Die Praxis hat gezeigt, dass sich für viele Anwendungen (darunter auch das Videoverleihshop-Beispiel) die Verteilung der Wahrscheinlichkeiten gut mit dem Zipfschem Gesetz (siehe Lerneinheit Zipfsches Gesetz ) beschreiben und daher vorhersagen lässt. Aus den Wahrscheinlichkeitswerten lassen sich dann leicht die optimalen <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Werte ableiten.

Beispiel Online-Shopping

Als weiteres Beispiel für Spatial Locality sei hier noch Online Shopping erwähnt: Es gibt Shops, die statistisch vorhersehbar (ebenfalls durch das Zipfsche Gesetz gut beschreibbar) mehr Requests erfahren werden als andere. Auch hier kann man diesen Umstand zur Verbesserung der Gesamtperformance nutzen: Höher frequentierten Shops werden höhere <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Werte zugeordnet.

Anwendungen ohne Spatial Locality

Natürlich gibt es auch Anwendungen, wo der Request-Arrival Prozess keine Ortsabhängigkeit aufweist.

Beispiel: Bilddatenbank für Radiologen

In einer Patienten-Informationsdatenbank sind Röntgenbilder abgelegt. Wie oft welches Bild nun angefordert wird, ist absolut beliebig, und kann daher durch kein statistisches Gesetz vorher gesagt werden. Eine sinnvolle individuelle Zuordnung der <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werte ist für diese Anwendung nicht möglich.

Praktischer Nutzen

Mit Hilfe der Wahrscheinlichkeitsverteilung kann für jede Anwendung eine sinnvolle Speicherhierarchie konstruiert werden. Multimediale Dateien mit hohen <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math> -Werten werden auf schnellen (und auch teuren) Speichersystemen abgelegt, Dateien mit geringem <math><semantics><mrow><msub><mi>Q</mi><mi>k</mi></msub></mrow><annotationencoding='MathType-MTEF'></annotation></semantics></math>-Wert hingegen können Kosten sparend auf einfache Speichersysteme gestellt werden.

Zeitabhängigkeit (Temporal Locality)

Eine Zeitabhängigkeit des Request-Arrival Prozesses entsteht bei Anwendungen, wenn bestimmte Dateien zu bestimmten Zeiten auffallend oft, zu anderen Zeiten wiederum nur wenig angefordert werden.

Beispiel: On Demand Spielfilme

Populäre Spielfilme erfahren in den Abendstunden eines Wochenendes mehr Requests als an Wochentagen. Ebenso ist über den Tag betrachtet zu beobachten, dass populäre Spielfilme zwischen 6 Uhr und 9 Uhr abends besonders häufig gewünscht werden, untertags hingegen besteht danach keine große Nachfrage.

Praktischer Nutzen

Die Kenntnis der Zeitabhängigkeit ist wichtig für die Entscheidung, welches Service- und Netzwerkmodell für einen Server gewählt wird.

Multimedia-On-Demand Service-Typen

1

Pay-Per-View

  • Pay–per-View (PPV) bereits verbreitetes Service
    • Kunde verbunden via Set-Top Box
    • Wählt bestimmte kostenpflichtige Sendung aus
    • Reines Broadcasting-Service
    • Kunde hat keinen Einfluss, wann Sendung gestartet wird
  • Vorteile
    • Geringe erforderliche Bandbreite
    • Einfach zu implementieren
  • Nachteile
    • Zeitabhängigkeit – Client hat keinen Einfluss auf den Startzeitpunkt
    • Keine Interaktivität

Near Video-On-Demand

  • Near Video-On-Demand (NVD) oder Shared Viewing with Constraints (SVC)
    • Erweiterung von Pay-Per-View
    • Client schickt Request an den Multimedia-On-Demand Server
    • Serverseitig Requests in Gruppen zusammengefasst
      • Eine Gruppe enthält Clients, die selbe Datei zu einem ähnlichen Zeitpunkt bestellt haben
      • Jede Gruppe per Sammelsendung (Multicast) bedient
  • Vorteile
    • Relative Zeitunabhängigkeit
      • Hängt davon ab, wie Provider Service gestaltet
    • Bandbreiten schonend
      • Viele Clients werden mit einem einzigen Datenstrom bedient
    • Stabilität gegenüber Zeit- und Ortsabhängigkeit
  • Nachteil
    • Geringer Grad an Interaktivität
      • Einzige Möglichkeit - Client wechselt in andere Gruppe

Beispiel von Near Video-On-Demand



Beispiel für Shared viewing with constraints (SVC)

True Video-On-Demand

  • Jeder Request wird seperat behandelt
  • Vorteile
    • Zeitunabhängigkeit
      • Für jeden Request wird serverseitig eigener Datenstrom ausgespielt
    • Hoher Grad an Interaktivität
  • Nachteil
    • Exorbitante Bandbreiten/Durchsatzwerte
      • Beispiel: Video-On-Demand System für HDTV
        • Es sollen 200 Clients gleichzeitig bedient werden
        • Erforderlicher Datendurchsatz/Bandbreite = 4 Gbps!

Beispiel für True Video-On-Demand Service

Beispiel für True Multimedia-On-Demand Service

2

auto

Ein On-Demand Service-Typ legt fest, wie der Austausch von Daten zwischen Server und Client funktioniert. Je nach Service-Typ wird der Benutzerin ein höherer oder geringerer Grad an Interaktivität geboten. Im Bereich Multimedia-On-Service gibt es drei Service Typen: Pay-Per-View, Near Video-On-Demand, True Video-On-Demand.

Pay-Per-View

Pay–per-View (PPV) ist heute bereits ein weit verbreitetes Service, dass vor allem von Fernsehkabelbetreiber angeboten wird: Der Kunde, ausgerüstet mit einer Set-Top Box, kann sich gegen Bezahlung die vom Sender angebotenen Programme ansehen. Er hat dabei keinen Einfluss, wann ihm das gewünschte Programm zur Verfügung gestellt wird, da es sich ausschließlich um ein Broadcasting Service (Rundfunkdienst) handelt. Analog zu Kabelfernsehstationen kann auch ein Multimedia-On-Demand Server als Quelle von Broadcasting Programme verwendet werden. Auch hier hat der Kunde weder Einfluss auf die Sendezeit, noch stehen ihm interaktive Services wie schneller Vor- und Rücklauf zur Verfügung.

Vorteile

  • Geringe erforderliche Bandbreite – der Server muss immer nur einen einzigen Datenstrom generieren, unabhängig davon, wie viele Clients er gleichzeitig bedienen muss. Der serverseitige Datendurchsatz ist unabhängig von der Anzahl der Clients.
  • Implementierbarkeit - Vorteil von Pay–per-View ist, dass es sehr leicht implementierbar ist.

Nachteile

  • Zeitabhängigkeit – Client hat keinen Einfluss auf den Startzeitpunkt
  • Keine Interaktivität

Near Video-On-Demand

Near Video-On-Demand (NVD) oder Shared Viewing with Constraints (SVC) ist eine Erweiterung von Pay-Per-View. Im Unterschied zu Pay-Per-View kann der Client bei Near Video-On-Demand zu jedem beliebigen Zeitpunkt einen Request an den Multimedia-On-Demand Server schicken. Auf Serverseite werden die Requests aller Clients in Gruppen zusammengefasst. Eine Gruppe enthält dabei alle Clients, die ein und dieselbe Datei zu einem ähnlichen Zeitpunkt bestellt haben. Jede Gruppe wird anschließend ähnlich dem Pay-Per-View -Service per Sammelsendung (Multicast) bedient.

Beispiel von Near Video-On-Demand

Als Beispiel betrachten wir einen Spielfilm mit einer Spielzeit von 2 Stunden. Serverseitig kann nun der Provider beispielsweise festlegen, dass der Film in 12 Teile zu je 10 min aufgeteilt wird. Zu Beginn wird jener Clientgruppe, die sich bis zum Startzeitpunkt formiert hat, der erste Filmabschnitt per Multicasting vorgespielt. Sind diese 10 Minuten vorbei, wechselt die Gruppe auf den folgenden Filmabschnitt. In der Zwischenzeit wurden die neu eingegangenen Requests zu einer neuen Gruppe zusammengefasst, für diese wird jetzt Filmabschnitt 1 gestartet. Nach weiteren 10 Minuten wechselt Gruppe 1 auf Abschnitt 3, Gruppe 2 auf Abschnitt 2 und eine wieder neu entstandene Gruppe auf Abschnitt 1. Die Wartezeit beträgt für den einzelnen Client auf diese Weise im schlechtesten Fall 10 Minuten. Der Server muss so ausgelegt sein, dass er 12 Gruppen gleichzeitig bedienen kann, wobei er für jede Gruppe jeweils nur einen einzigen Datenstrom generieren muss, unabhängig davon, wie viele Clients sich darin befinden.



Beispiel für Shared viewing with constraints (SVC)

Vorteile

  • Relative Zeitunabhängigkeit - Gegenüber dem Pay-Per-View Service bietet Near Video-On-Demand den entscheidenden Vorteil, dass der Client zu jedem beliebigen Zeitpunkt seinen Request senden kann, und er die gewünschten Multimedialen Daten in akzeptabler Zeit auch zur Verfügung gestellt bekommt.
  • Bandbreiten schonend – Da die Clients in Mulitcastgruppen zusammengeschlossen werden, muss Server jeweils nur einen Datenstrom pro Filmabschnitt generieren. Der für ein gutes Near Video-On-Demand Service benötigte Datendurchsatz ist somit im Vergleich zu einem True Multimedia-On-Demand Service wesentlich geringer.
  • Stabilität gegenüber Zeit- und Ortsabhängigkeit – dadurch, dass die Clients in Gruppen zusammengefasst werden, können die Request-Arrival Prozess Eigenschaften „Orts- und Zeitabhängigkeit“ gut abgefedert werden

Nachteil

Geringer Grad an Interaktivität – Near Video-On-Demand lässt nur wenig Spielraum für Interaktivität. Ein kleinwenig Interaktivität kann man allerdings bieten, wenn man den Clients gestattet, die Multicast Gruppe zu wechseln, während der Film bereits empfangen wird. So kann sich der Client bestimmte Filmabschnitte wiederholen lassen oder auch überspringen.

True Video-On-Demand

Bei True Video-On-Demand werden die einzelnen Requests immer unabhängig voneinander behandelt. Selbst wenn zwei Clients praktisch zur selben Zeit denselben Request schicken, liefert ihnen der True Video-On-Demand Server zwei von einander unabhängige Datenströme. Das True Video-On-Demand Service bietet so einerseits ein Maximum an Interaktivität, andererseits verbraucht es auf verschwenderische Weise hohe Bandbreiten. Der Einsatz eines reinen True Video-On-Demand Service macht überall dort Sinn, wo ein hoher Grad an Interaktivität notwendig ist.

Beispiel für True Video-On-Demand Service

Beispiel für True Multimedia-On-Demand Service

Obere Abbildung zeigt ein True Video-On-Demand Service Modell. Als Beispiel ist die Abarbeitung von drei Requests eingezeichnet. Der Server generiert für jeden Request einen eignen Datenstrom, ganz unbeeinflusst davon, dass Request 1 und Request 2 dasselbe Video (Video X) fast zur gleichen Zeit anfordern.

Vorteile

  • Zeitunabhängigkeit – Jeder Request wird völlig unabhängig von anderen bearbeitet. Der Client startet durch seinen Request unmittelbar den Datenstrom.
  • Hoher Grad an Interaktivität – Client hat interaktive Möglichkeiten wie schneller Vor- und Rücklauf, Stop, Pause etc

Nachteil

  • Exorbitante Bandbreiten/Durchsatzwerte – Da die Clients unabhängig von einander bedient werden sollen, muss der True Video-On-Demand Server auch für jeden Client einen eigenen Datenstrom generieren. Jeder zusätzliche Client erhöht somit direkt den Datendurchsatz am Server, der so exorbitante Ausmaße annehmen kann.

Beispiel: Video-On-Demand System für HDTV

Man betrachte wieder einen elektronischen Videoverleihshop, der Spielfilme in HDTV Qualität anbietet. Für einen Datenstrom (MPEG-2 kodiert) muss man durchschnittlich mit 20Mbps Datenrate rechnen. Sollen nun 200 Clients gleichzeitig bedient werden, ergibt sich serverseitig ein benötigter Datendurchsatz von 4 Gbps!

Video-On-Demand – Fallstudien

1

Video-On-Demand für zu Hause

  • Fallstudie „Bell Atlantic Trial“
      • Studie untersucht Verhalten von Kunden in einer Video-On-Demand Umgebung im privaten Bereich
  • Aufbau der Studie „Bell Atlantic Trial“
    • 1000 Haushalte via Set-Top Box mit Multimedia-Server verbunden
    • Auswahlmöglichkeit
      • Bestellung von kostenpflichtigen Videos aus einer Liste von 700 Titel
      • Liste wird monatlich aktualisiert
    • Interaktion per Fernbedienung
      • Bestellfunktion
      • VCR Befehl
  • Ergebnisse
    • Ein Haushalt bestellte durchschnittlich 3,6 Videos im Monat
    • Request-Verteilung
      • Neue Spielfilme am meisten bestellt (57%), gefolgt von Kinderfilmen und Sonderangeboten
    • VCR Steuerungsfunktionen als sehr wichtig eingestuft
  • Schlussfolgerungen
    • Bestimmte Filme werden überproportional oft bestellt
      • Near Video-On-Demand Service ökonomisch sinnvoll
    • Service muss VCR Steuerungsfunktionen bieten

Video-On-Demand im Lehrbetrieb

Aufbau der Studie „Universität Ottawa“

  • Fallstudie der Universität Ottawa
    • Studie untersucht praktischen Nutzen von begleitenden Videomaterial für Vorlesung
  • Aufbau der Studie
    • 40 Videos mit einer Gesamtlänge von 32 Stunden
      • Inhalte ergänzen Vorlesung
    • Studenten mussten folgende Anweisungen befolgen
      • Konsumation eines Videos pro Woche
        • Videoinhalt muss zu dem in dieser Woche vorgetragenem Vorlesungsstoff passen
      • Vorbereitung von zwei Präsentationen mit Hilfe des Videomaterials
  • Ergebnisse
    • Große Mehrheit bewertet begleitendes Videomaterial als sehr positiv
    • 69% der Testpersonen - VCR Steuerungsfunktionensehr wichtig
    • 65% der Testpersonen - Intensive Nutzung der VCR Steuerungsfunktionen
    • 58% der Testpersonen - Wunsch nach effektiveren Browsing-Tools

2

Video-On-Demand für zu Hause

Aufbau der Studie „Bell Atlantic Trial“

Bell Atlantic Trial ist eine Fallstudie, die das Verhalten von Kunden in einer Video-On-Demand Umgebung im privaten Bereich untersuchte. Dazu wurden in Fairfax (eine Stadt im Bundesstaat Virginia) 1000 Haushalte mit einem Multimedia-Server verbunden. Jeder Haushalt wurde mit einer Set-Top Box ausgestattet. Zur Interaktion mit dem System stand eine Fernbedienung zur Verfügung, die via Set-Top Box den Datenaustausch zwischen Client und Multimedia Server ermöglichte. Die Kunden konnten nun Videos aus einer monatlich aktualisierten Liste von 700 Titeln auswählen und kostenpflichtig bestellen. Neben der Bestellfunktion hatte die Fernbedienung auch die Aufgabe einer Videorekorderfernbedienung (Schneller Vor- und Rücklauf, Pause, Resume).

Ergebnisse

  • Ein Haushalt bestellte durchschnittlich 3,6 Videos im Monat
  • Es wurden neue Spielfilme am meisten bestellt (57% aller Bestellungen), gefolgt von Kinderfilmen und Sonderangeboten.
  • Ein großer Teil der Testpersonen betrachteten die VCR Steuerungsfunktionen als sehr wichtig.

Schlussfolgerungen

Aus der Erkenntnis, dass bestimmte Filme überproportional oft bestellt werden, scheint es ökonomisch sinnvoll, solche Filme mittels Near Video-On-Demand Service an die Clients zu verteilen. Allerdings minimieren sich dann die Möglichkeiten der VCR Steuerungsfunktionen.

Video-On-Demand im Lehrbetrieb

Aufbau der Studie „Universität Ottawa“

Diese Fallstudie wurde an der Universität Ottawa durchgeführt. Es sollte untersucht werden, wie man geeignetes Videomaterial für eine Vorlesung effektiv nutzen kann. Dazu standen insgesamt 40 Videos mit einer Gesamtlänge von 32 Stunden zur Verfügung. Die Studenten wurden aufgefordert, sich pro Woche ein Video anzuschauen, welches die Inhalte, die in der Vorlesung behandelt wurden, ergänzen sollte. Weiters mussten sie selbst zwei Präsentationen mit Hilfe des Videomaterials vorbereiten. Am Ende der Untersuchung wurden die Studenten über ihre Erfahrungen mit dem System befragt.

Ergebnisse

  • Eine große Mehrheit der Studenten empfand das zusätzliche Video-On-Demand Angebot als positive Bereicherung sowohl als Ergänzung der Inhalte aus der Vorlesung wie auch für die Vorbereitung ihrer eigenen Präsentation
  • 69% der Testpersonen bewerteten das Vorhandensein von VCR Steuerungsfunktionen als sehr wichtig
  • 65% gaben an, die VCR Steuerfunktionen intensiv genutzt zu haben
  • 58 % wünschten sich zusätzliche Tools, mit deren Hilfe ein schnelleres Auffinden und Abrufen von bestimmten Videosegmenten möglich ist.

Maße zur Bewertung der Performance eines Multimedia-On-Demand Servers

1

auto

  • Gleichzeitigkeit (concurrency)
    • Anzahl der gleichzeitig bedienbaren Clients
    • Hoher Gleichzeitigkeitswert minimiert Notwendigkeit von redundanten Kopien
  • Zugriffs- und Operationswartezeit
    • Zugriffswartezeit
      • Zeit zwischen Absenden von Request und Start der Dateiübertragung
        • Hauptsächlich vom Service Modell abhängig
        • Netzwerkverzögerungen nur wenig Einfluss
      • Zugriffswartezeit sollte nur wenige Sekunden betragen
    • Operationswartezeit (Operation Latency)
      • Zeitverzögerung bei interaktiven Operationen
      • Für brauchbare Interaktivität darf Operationswartezeit nur Bruchteil einer Sekunde betragen
  • Speicherkapazität und Netzwerkdatendurchsatz per Dollar
    • Kosteneffektivität eines Multimedia-On-Demand Servers
      • Verhältnis von benötigter Speicherkapazität, Datendurchsatz und Kosten
      • Wert soll möglichst klein sein
      • Beispiele für Speicherkapazität und Datendurchsatz
        • Speicherkapazität
          • Ein durchschnittlich großes Institut an einer Universität
          • Alle Vorlesungen eines Semesters stehen als MPEG Videostreams zur Verfügung
          • Erforderlicher Speicherbedarf im Terabit-Bereich
        • Datendurchsatz
          • Server mit Videos in HDTV – Qualität
          • Gleichzeitigkeit soll 1000 betragen
          • Erforderlicher Datendurchsatz - 20 Gbps (=20480 Megabits pro Sekunde)
  • Skalierbarkeit
    • In Bezug auf Maß der Gleichzeitigkeit
  • Erweiterbarkeit
    • Flexibilität gegenüber unterschiedlichen Anwendungsszenarien und verschiedenen Service Modellen

2

auto

Um unterschiedliche Speicher Server Architekturen qualitativ miteinander vergleichen zu können, definiert man die im Folgenden beschriebenen Performance Maße.

Gleichzeitigkeit (concurrency)

Ein Multimedia-On-Demand Server muss viele Clients gleichzeitig störungsfrei bedienen können, egal ob sich diese verschiedene oder gleiche (in der Regel zeitversetzte) multimediale Inhalte senden lassen. Das Maß der „Gleichzeitigkeit“ gibt dabei die Maximalanzahl der möglichen Clients an. Beträgt zum Beispiel bei einem Video-On-Demand Server die Gleichzeitigkeit 1000, können 1000 Clients gleichzeitig bedient werden, selbst wenn sich alle tausend ein und dasselbe Video mit jeweils unterschiedlichem Zeitversatz ansehen. Ein hoher Gleichzeitigkeitswert minimiert die Notwendigkeit von mehreren Kopien eines Dokuments und reduziert somit die Speicherkosten.

Zugriffs- und Operationswartezeit

Zugriffswartezeit (Access Latency)

Als Zugriffswartezeit versteht man jene Zeit auf Clientseite, die zwischen Absenden eines Requests und dem Eintreffen des gewünschten multimedialen Dokuments vergeht. Sie ist hauptsächlich vom Service Modell abhängig, durch das umliegende Netzwerk verursachte Verzögerungen haben nur wenig Einfluss. Für eine befriedigende Performance sollte die Zugriffswartezeit nur wenige Sekunden betragen.

Operationswartezeit (Operation Latency)

Als Operationswartezeit wird jene Zeit definiert, die benötigt wird, um interaktive Operationen wie schneller Vor- und Rücklauf, Pause, Stopp etc. auszuführen. Soll ein hoher Grad an Interaktivität geboten werden, darf die Operationswartezeit nur ein Bruchteil einer Sekunde betragen.

Speicherkapazität und Netzwerkdatendurchsatz per Dollar

Definition des Maßes

Dieses Maß beschreibt die Kosteneffektivität eines Multimedia-On-Demand Servers. Es werden dabei die beiden Werte „benötigte Speicherkapazität“ und „benötigter Datendurchsatz“ im Verhältnis zu den Kosten betrachtet. Um ein erschwingliches Multimedia-On-Demand Service bieten zu können, soll dieser Wert möglichst kein sein.

Beispiele für Speicherkapazität und Datendurchsatz

An Hand von zwei Beispielen soll veranschaulicht werden, welche Dimensionen die Werte „Speicherkapazität“ und „benötigter Datendurchsatz“ für einen Multimedia-On-Demand Server im praktischen Einsatz annehmen.

Speicherkapazität

Ein durchschnittlich großes Institut an einer Universität will seinen Studenten alle Vorlesungen eines Semesters als MPEG Videostreams zur Verfügung stellen. In diesem Fall muss man mit einem Speicherbedarf im Terabit-Bereich rechnen.

Datendurchsatz

Man betrachte einen Server, der den Clients Spielfilme in HDTV – Qualität zur Verfügung stellen soll. Sollen 1000 Clients gleichzeitig bedient werden, ist ein Datendurchsatz im Ausmaß von 20 Gbps (=20480 Megabits pro Sekunde) notwendig.

Skalierbarkeit

Die Server Architektur sollte so beschaffen sein, dass im Bedarfsfalle zum Beispiel eine ursprünglich für 100 Clients konzipierte Architektur ohne hohen Aufwand auf 1000 Clients erweitert werden kann.

Erweiterbarkeit

Das Maß der Erweiterbarkeit gibt an, wie flexibel eine Serverarchitektur mit unterschiedliche Anwendungsszenarien und verschiedenen Service Modellen arbeiten kann.


Notes

Akronyme

AOD – Audio on Demand

DV – Dedicated Viewing (dedicated: fest zugeordnet)

GB – Gigabit (1024 Megabits)

Gb – Gigabyte (1024 Megabytes)

Gbps – Gigabit per second

HDTV – High Definition Television

MPEG-2 – Moving Pictures Encoding Group 2: Von der ISO erarbeiteter Standard, der die digitale Kodierung von Video-/Audiodaten beschreibt, um diese für den digitalen Rundfunk nutzen und in hoher Qualität speichern zu können.

MOD – Multimedia-On-Demand

NVD – Near Video on Demand

PB – Petabyte (1024 Terabytes)

PDA – Personal Digital Assistant

Pb – Petabit (1024 terabits)

PPV – Pay-Per-View

QoS – Quality of Service

SVC – Shared Viewing with Constraints

TB - Terabytes (1,024 Gigabytes)

Tb – Terabit (1,024 Gigabits)

TMOD – True-Multimedia-On-Demand

VCR – Videocassette Rekorder

VOD - Video-On-Demand

VR – Virtual Reality

Glossar

Broadcasting – Ausstrahlung (von mutlimedialen Inhalten)

Datendurchsatz - Die Datenmenge, die pro Zeiteinheit verarbeitet wird

Multicast - Sammelsendung