1. Einleitung
1.1. Motivation
Aus pseudohistorischer Perspektive gibt es Live-Streaming seit dem Rolling Stones-Konzert im Jahr 1994 in Dallas/USA1, welches über das Universitätsnetz Mbone2 übertragen wurde. Denn Mbone war schon zu damaliger Zeit landesweit multicastingfähig war, was das Trafficvolumen bei der Live-Übertragung deutlich verringert hat.
Schon an diesem schwülen Freitagabend in Dallas und auf allen RGB-Monitoren, zu denen das Konzert durchdrang, war eine gewisse Tendenz abzusehen. So ähnlich, wie die Rundfunktechnik erst den Telegrafen (Textübertragung), später das Radio (Schallübertragung) und schliesslich das Fernsehen ermöglicht hat, so war es schon in den 1990ern alleine eine Frage der Bandbreite und des sog. “letzte Meile”-Problems, wann Video on Demand und somit Live Streaming so weit flächendeckend verfügbar sein werden, daß die Software- und Hardwareproduzenten entsprechende Lösungen für die Endverbraucher abliefern werden. Die Uhr für den Start des weltweiten Internetfernsehens lief also spätestens seit den 1990er Jahren.
Im Fall von Webstreaming gibt es nicht nur das Problem der „letzten Meile“, sondern auch der „ersten Meile“. Denn ein Anbieter kann nur so viel Content auf seinen Server stellen, wie es seine eigene Uploadgeschwindigkeit zulässt3 – im Gegensatz zur Downloadgeschwindigkeit beim „letzte Meile“-Problem. Bei den schwindelerregenden Datenvolumen von Videos mit adaptiver Bitrate ist das der erste Flaschenhals, den ein Anbieter lösen muß.
Momentan bieten Open-Source-Projekte wie FFmpeg und seine beiden größten Ableger transcode und libav eine sehr hohe Kompatibilität mit Endverbrauchergeräten, wie smarte Fernseher, Smartphones usw. Diese Transkodierer bieten Unterstützung für etliche Formate und machen es möglich, alleine auf Basis von Open Source Software ein für die meisten Player verfügbares Video- und Audioangebot ins Leben zu rufen. Dadurch können ebenfalls kleine Anbieter von der Streamingtechnologie profitieren, ohne an Medienkonzerne wie Youtube als Videopublisher gebunden zu sein.
Durch so eine Emanzipation der kleinen Medienanbieter können bspw. die unzähligen Hörverlage, Plattenfirmen, unabhängige Filmproduzenten, Musiker und Videoblogger ein Werkzeug erhalten, mit dem sie ihre Produktionen ihren Usern in hoher Qualität präsentieren und verwerten können, unabhängig von technischen Vermittlern. Die hier vorgestellte REST API soll eine rapide Integration in einen beliebigen bestehenden Medienworkflow ermöglichen.
1.2. Aufgabenstellung
Das Ziel dieser Masterarbeit ist der Entwurf einer Web-API, die durch einen durchschnittlich versierten Webmaster mittels REST-Methoden in ein beliebiges Webprojekt integriert werden kann. Die API selbst soll einen expliziten Workflow realisieren. Als Input nimmt das Programm eine Audio/Video-Datei und erstellt daraus ein HTTP Live Streaming-Dateisystem mit adaptiver Bitrate (ABR). Eine so ins HLS-Format enkodierte Videodatei kann danach vom User auf einem beliebigen Webserver für seine Zuschauer zum Abruf bereitgestellt werden. Das adaptive Streaming und der damit verbundene unterbrechungsfreie Medienkonsum bei verschiedenen Empfangsbedingungen (ADSL, 3G, LTE, usw.), was mitunter das Hauptmerkmal der großen Anbieter darstellt, soll in diesem Projekt durch den Transcoder FFmpeg und das resultierende HLS-Dateisystem erreicht werden.
Die Arbeitsabschnitte beinhalten:
- die Erstellung eines tokenbasierten Authorisierungsmechanismus,
- Quelldateianalyse mittels des Hilfsprogramms ffprobe
- Konfigurieren der Profile für die Transkodierung von Audio/Video durch Recherche und Trial & Error
- Parametrisierung der FFmpeg-Syntax im Verhältnis zu den adaptiven Bitratenprofilen und der Quelldateianalyse
- Ausführung und Ergebniskontrolle der Transkodierung
- Messung der erstellten HLS-Profile in Hinsicht auf die reelle Bitrate jeder einzelnen Auflösung durch einen simulierten Streamingclient (ffmpeg -re4).
- Tests in verschiedenen HLS-kompatiblen Playern, darunter flowplayer-hlsjs, Safari Browser, VLC Media Player, Google Android Chrome
- asynchrone und dezentrale Organisation der Infrastruktur und des Quellcodes – der Transcoder befindet sich auf einer vom Webserver separierten Maschine und beide kommunizieren beim Abarbeiten des Workflows miteinander unter Verwendung von Events
1.3. Recherchen
Zum theoretischen Teil wurden Recherchen in der Artikeldatenbank der Zentralbibliothek der Technischen Universität Berlin durchgeführt. Es wurden Artikel aus den Themenbereichen HTTP Streaming, Media Commerce, Intellectual Property und Medienverschlüsselungstechniken gewählt.
Der praktische Teil erforderte Recherchen zu geeigneten Softwarekomponenten, wie Jobserver, Transcoder, Struktur des HLS-Formats und schließlich die Performance der entworfenen Lösung.
1.4. Einarbeitung in folgende Techniken
Ein Transcodingmechanismus ist ein rechenintensiver Vorgang und muss damit durch einen Queue-Mechanismus bedient werden. Da die Recherche ergeben hat, dass ein Queue-Mechanismus in diversen Datenbanken, wie MySQL und MongoDB, bei vielen Abrufen ein Performanceproblem an den Tag legt, musste ein geeigneter Jobserver gefunden werden. Der Gearman Jobserver beschreibt auf seiner Homepage, dass diverse Internetgrößen ihn für das Skalieren von Bildern im Hintergrund verwenden5. Desweiteren kann der Jobserver relativ problemlos auf viele Maschinen hochskaliert werden. Ebenso bietet er Remote Function Calls (Aufrufe von Funktionen von anderen Computern) und Bindings für die wichtigsten Websprachen. Da die Originaldokumentation einige fehlende Seiten aufweist, musste die Einarbeitung mittels Trail & Error verbunden mit Googlesuche auf Stack Overflow und themenverwandten Portalen stattfinden.
Damit die API einen Ausgangspunkt für IP-Sicherheit bietet, wurde ein privates Schlüsselsystem (Tokens) konzipiert, das momentan lediglich für die Authorisierung eines Medienuploads verwendet wird, in Zukunft jedoch den Konsum von verschlüsselten Inhalten ermöglichen soll.
Es war weiterhin notwendig sich in die Konfiguration von nginx (Cache, Headers, MIME-Types), in die Grundlagen von regulären Ausdrücken, sowie die Prozessverwaltung und Konsolenausgabe unter Linux (debian) einzuarbeiten.
Die Parametrisierung des FFmpeg-Transcoders erforderte eine Studie der Aufrufsyntax und ebenso diverse Trail & Error Versuche, bis die Jobschleife angefangen hat, problemfrei Mediendateien verschiedenen Ursprungs abzuarbeiten. Die grundlegende Quelldateianalyse sowie die Messung der Bitraten der verschiedenen Ergebnisspuren verlangte eine Analyse der ASCII-Zeichenfolgen, die FFmpeg auswirft, da es sich teilweise um Steuerungsszeichen handelt (Carriage Return). Es war auch notwendig, sich die Grundlagen des bash-Interpreters sowie die Erstellung und Konfiguration von init.d-Daemonen anzueignen. Die Rechte der User und des Dateisystems mussten beachtet werden, um keine Konflikte in der Rechteverwaltung herbeizusteuern.
Schließlich war es das Hauptziel, ein funktionierendes HLS-Dateisystem mit dem Adaptive Bitrate-Merkmal zu erstellen, weswegen ein genaues Studium des Formats und ebenfalls Trail & Error Versuche mit dem Verhalten des HLS-Formats unter diversen Playern durchgeführt werden mussten.