6. Konzept und Entwurf
In diesem Kapitel stellt der Verfasser ein Workflow Diagram der Datenabläufe des Transcoders sowie die Netztopologie einer verteilten (skalierten) Version des Projektes vor. Im letzten Teil wurde die Datenbankstruktur beschrieben.
6.1. Workflow Diagram
Das Workflow Diagram der Serveranwendung wurde auf Illustration 3 auf der nächsten Seite veranschaulicht. Die Überschriften des Diagrams in Illustration 3 bedeuten:
REST-Methoden:
- publish.php – GET-Methode zum generieren eines UPLOAD.TOKEN‘s, der den Userclient erst zu einem Upload berechtigt. Die Bedingung, welcher nach der Server den Token vergibt, muss in das Skript zusätzlich programmiert werden, je nach dem, ob es sich bspw. um ein PayPal-Beitrag oder etwa Nutzerrechte in einer Groupware handelt, die bestimmen, ob der Server dem User einen UPLOAD.TOKEN gewährt
- upload.php – REST-Endpunkt für einen Multipart Upload verbunden mit einem validen UPLOAD.TOKEN. Als Antwort erhält der Client einen MEDIA.TOKEN
- delete.php – GET-Methode zum Löschen des Medieninhaltes mittels des MEDIA.TOKEN‘s
- In Planung: decrypt.php – GET-Methode zum Abrufen eines WATCH.TOKEN‘s für ein verschlüsseltes Medien-Asset mittels des MEDIA.TOKEN‘s
- master.m3u8 – HLS-Stream Hauptdatei, die die URI‘s zu den jeweiligen Bitraten sowie die gemessene Bitrate eines jeden Streams enthält. In Planung: Als HLS-Masterdatei erscheinendes Webscript, das bei verschlüsselten und geschützten Inhalten den Zugriff per WATCH.TOKEN (HTTP GET) und ggf. die Keyinfo an die Indexdateien hängt
Objekte:
- Token – Objekt zum generieren, verifizieren und annullieren von UPLOAD.TOKEN‘s, MEDIA.TOKEN‘s und WATCH.TOKEN‘s
- Xcdr – Objekt zum analysieren und verarbeiten von Audio-/Videodateien
- httpd – Webserver zum Ausspielen der Medien-Assets
Die REST API enthält momentan drei Endpunkte (publish, upload und delete), die um weitere Medienbearbeitungsfunktionen ausgebaut werden können.
Der in rot/gelb abgebildete Rahmen (decrypt.php→WATCH.TOKEN) ist in Planung. Alle anderen abgebildeten Knoten der Anwendung wurden bereits erstellt.
6.2. Skalierung
Die Definition von „VoD-Systemen einer großen Skala“ beläuft sich der Multimedia-Encyclopedia nach auf „Systeme, die es verteilten Anwendern erlauben, interaktiv auf Videodateien auf entfernten Servern zuzugreifen und bestehen aus vier Komponenten: Videoserver, Verzeichnisserver, Proxyserver sowie Clients/Set-Top-Boxen“89.
Dem Paper nach benötigt der Entwurf einer kosteneffektiven Streaminginfrastruktur entweder
- einen Proxyserver, der zur optimalen Auslastung der Bandbreite beiträgt,
- oder eine Multicasting-/Broadcasting-Technologie, um die Bandbreite bei statischen Inhalten einzusparen.
Der Videoserver ist für das eigentliche Streaming der Inhalte zum User verantwortlich. Er entscheidet, ob die Resourcen, wie Bandbreite und Festplattengeschwindigkeit, für einen weiteren Client ausreichend sind.
Die aktuelle Struktur des Projekts ermöglicht den Entwurf einer skalierten Konfiguration derselben. So eine Anwendung kann von verteilten Ressourcepools für die Transkodierung und die Distribution der Inhalte Gebrauch machen, wie auf Abbildung 11 skizziert.
- Die Zahl der physischen Transcoder kann durch die Verwendung eines gemeinsamen Jobpools und Massenspeichers beliebig erweitert werden.
- Der root-Webspeicher unterscheidet sich von den Spiegelservern Webstorage 1..n, indem er gleichzeitig zur Fertigstellung des HLS-Streams beiträgt. Er misst die Ergebnisbitraten der generierten Videoprofile durch einen eingebauten Pseudoclient. Zu diesem Zweck läuft auf dem root-Webserver eine Instanz des Jobservers, der die Messung der Bitraten direkt nach der Transkodierung abfertigt. Diese Komponente ist auf den Spiegelservern zwecklos.
- Bei unverschlüsselten HLS-Streams können die Spiegelserver lediglich durch das rsync Programm repliziert werden, da es sich um einen dateisystembasierten Stream handelt.
- Bei verschlüsselten HLS-Streams ist eine Replizierung der Datenbank notwendig, um eine effektive Zugriffskontrolle sicher zu stellen.
