Video Streaming (Beuth Hochschule für Technik Berlin, 2018)

8. Diskussion und Ausblick

8.1. Retrospektive

Eine Transcoding API bedeutet eigentlich die Möglichkeit per Standardmethoden komplexe Einstellungen an diesem Prozess vornehmen zu können. Deswegen heißt die in dieser Arbeit beschriebene Lösung Webvideopublishing API, oder kurz Webencoder API. Zwar wird vorwiegend von einem Transcoder Gebrauch gemacht, doch verfolgt das Programm primär das Ziel, ein Webvideo im allgemeinen, einen adaptiven HLS-Stream im engeren Sinn zu erstellen.

Zunächst wurde der Versuch unternommen, ein Mockup unter node.js zu erstellen. Die asynchrone Datenverarbeitung in Hinsicht auf jeden einzelnen Programmierbefehl war für mich jedoch nicht in einem vernünftigen Zeitraum zu beherrschen. Deswegen habe ich die Umgebung nach mehreren Ansätzen zum LEMP-Stack (Linux-(E)nginx-MySQL-PHP) gewechselt.

Vor dem eigentlichen Beginn des produktiven Arbeitsabschnitts habe ich ein Datenbankschema entwickelt, in dem ich noch vorgesehen habe, dass die drei Typen von Tokens jeweils in den Datenbanktabellen Media und Token verteilt sind, da ich einen Zusammenhang zwischen der Art des Tokens und seiner Verwendung in den jeweiligen Objekten (UPLOAD.TOKEN in Token, MEDIA.TOKEN und WATCH.TOKEN in Media) gesehen habe. Im weiteren Arbeitsabschnitt habe ich festgestellt, dass eigentlich die Relation zwischen den Tokens und den Medien im Vordergrund steht und habe deswegen eine Tabelle für alle Tokens erstellt. Es hat sich ergeben, dass eine relationale Datenbankstruktur im Code viel leichter zu verändern ist. Nachdem ich eigentlich schon mit einen weiteren Arbeitsabschnitt abgeschlossen habe, habe ich den MEDIA.TOKEN-Typ in den Code mit Erfolg eingebaut. Des Weiteren wurde die /media/delete.php-Methode erst gegen Ende des praktischen Teils erstellt und es war ebenfalls überraschend, wie schnell man in einer objektorientierten Programmierweise bestimmte Änderungen vornehmen kann, damit eine weitere Methode Zugriff auf die Datenbestände mit einem minimalen Overhead an Datenbankabfragen bekommt.

Es lag mir vorwiegend daran, eine Webfunktionalität zu entwickeln, die universell einsetzbar ist. Was das jedoch in der Praxis bedeutet, wurde mir bewusst, als ich einen Artikel über Microservices auf dem nginx-Blog gelesen habe⁹⁸. Mein Verständnis einer universellen Anwendung wurde damit konkretisiert und ich habe mich darauf konzentriert, einen VoD-Encoder mit diesem Paradigma zu beschreiben.

Es ist in der Webentwicklung verlockend jegliche möglichen, einbaubaren Funktionen und Interaktionen einer Webanwendung in Betracht zu ziehen und ihren Nutzen für das Endprodukt zu projizieren. Doch gewinnt im Internet heutzutage die Spezialisierung, in der eine zu große Allgemeinheit kontraproduktiv ist. In Hinsicht auf die Konzipierung und den Entwurf der Web-API musste ich auf jegliche Services, die nicht im direkten Fokus der geplanten Funktionalität liegen, verzichten. Es war jedoch für meine Kreativität fördernd, sich aus etlichen Webfunktionen einen klar definierten Abschnitt vorzunehmen und ihn gründlich durchzuführen, statt durch einen chaotischen Entwurf das Ziel zu verfehlen – ein funktionelles und nutzbares Programm zu schaffen.

Eine Funktionalität, die nicht eingespart werden konnte, war die Zugriffskontrolle, da es sich um eine potentiell öffentlich zugängliche Web API handelt. Deswegen wurden Transaktions-schlüssel, ergo Tokens, für den Zugriff auf die REST-Endpunkte entwickelt. Da diese Methode jedoch nicht sicher ist, wurde auf der Online-Demo⁹⁹ zusätzlich ein HTTP Basic Auth– Verfahren via SSL eingerichtet.

Alle weiteren Features, wie eine Galerieansicht, eine komplette Nutzer- und Rechteverwaltung, Statistik bzw. Web Analytics, Social Media wie Foren und Kommentare, wurden aus diesem Grund bewusst aus dem Entwurf entfernt, um

dem Webmaster, der die Lösung evtl. integrieren wird, keine typische Portallogik zu seinem bestehenden Kommunikationskonzept zu addieren, sowie
den Vorteil des HLS-Protokolls zu nutzen, daß es zustandslos und ohne Datenbank-Backend funktionieren kann und somit einem Integrator eine funktionale Barebonelösung zu liefern.

Als Web Analytics Anwendung eignet sich die kostenlose Matomo-Plattform. Sie kann als Google Analytics- Ersatz auf einem organisationseigenen Server funktionieren und damit zur Einhaltung der Europäischen Datenschutzrichtlinien, sowie anderer Normen zum Datenschutz und zur Datensicherheit¹⁰⁰ beitragen. Mit dieser Plattform sollte die Messung von Zuschauerzahlen und den konsumierten Medien und ihrer Dauer kein technisches Problem sein, da die HLS-Streams direkt auf dem Dateisystem liegen und jeder Zugriff vom HTTP-Server verzeichnet wird. Es gibt auch ein entgeltpflichtiges Plugin „Media Analytics“ für die Motomo Web Analytics Plattform¹⁰¹, das höchstwahrscheinlich viele Standardmessmethoden und die resultierenden Metrics bereits fertig zum Einsatz bietet und mit Standard HTTP-Streamingprotokollen zusammenarbeitet.

Eine weiteres Feature, das ich am Anfang der Implementierung nicht ernst genug genommen habe, ist die Analyse des Originalformats der Quelldatei, die ein Benutzer hochlädt. Mit nur etwas Glück kann sich herausstellen, dass der Originalvideocodec schon HLS-kompatibel ist und dadurch ein Encoding zumindest der höchsten Qualitätsspur, die sich an den geometrischen Parametern der Originalspur orientiert, nicht notwendig ist. Die Neuenkodierung eines bereits in H.264 vorliegenden Films verursacht unnötige Artefakte, sofern die Originaldatei bereits einen HLS-kompatiblen Codec beinhaltet. Bei einer ausreichenden Analyse der Kompatibilität des vorliegenden Codecs nach seinen H.264-Parametern (Auflösung, Profil, Farbsystem, Encoderlevel) kann der Encoder davon ausgehen, dass der Originalcodec der Quelldatei im zukünftigen, höchsten HLS-Profil verwendet werden kann und dadurch die höchste Bitrate in ihrer Originalqualität HLS-enkapsuliert und abgespielt werden kann. Die Analyse der Originalspur muss dafür gründlich getestet werden, um potentielle Falschentscheidungen bei inkompatiblen H.264-Spuren, die durch einen mäßig programmierten Encoder generiert werden können, auszuschließen. Gleichzeitig impliziert eine schlecht kodierte Originalvideospur Konsequenzen für das gesamte Ergebnisvideo, den jedes Profil kann nur so korrekt transkodiert werden, wie es die Qualität der Originalspur ermöglicht.

Deswegen ist es nicht notwendig, in diesem Ablauf jegliche möglichen Defekte zu entdecken, denn ab einer gewissen unteren Qualitätsgrenze kann der Transcoder kein sinnvolles Ergebnis mehr produzieren – unabhängig davon, ob die Originalvideospur beibehalten wird.

8.2. Ausblick

Es wäre von Vorteil, alle in Kapitel 4 Anforderungen besprochenen Unterpunkte zu realisieren. Im Vordergrund steht eine weitere Optimierung der diversen Videoprofile, um ein artefaktfreies TV-Erlebnis zu gewährleisten.

Weiterhin ist die Umsetzung eines kompletten Workflows Encoder → CMS wünschenswert, da dadurch das Projekt die nötige Weblogik erhält, um als autarkes VideoCMS zu funktionieren. Denkbar wäre die Herstellung von Plugins für diverse Content Management Systeme, wie WordPress, Buddypress, Foren und Webshops. Dadurch werden die Medienadministratoren in den echten Genuss einer hochqualitativen und automatischen Streaming Website kommen.

Des Weiteren wären Medienworkflows, wie die automatische Veröffentlichung des Videos in Social Media, für ein VideoCMS von erheblichem Vorteil. Dies ist auch der Hintergedanke bei der Implementierung des OpenGraph-Protokolls in den Kopfzeilen der Mediendateien.

Ein sicherer Webplayer ist wünschenswert. So ein Playout ist leichter mit der Gesamtlösung zu vertreiben und zu individualisieren, als eine App, die in einem zusätzlichen Framework geschrieben werden muss.

Es ist ebenfalls schwieriger, den Content-Key in einer Webumgebung zu verschachteln, in der theoretisch jeder User und jeder Webclient potentiell Zugriff auf den Schlüssel erlangen könnten. Dennoch ist es den Aufwand wert, eine webbasierte, sichere Lösung zu entwerfen. Im Webclient, der in dieser Arbeit mit der REST API kommuniziert, habe ich vorerst die SSL Übertragung der Logindaten eingebunden.

SSL-Verschlüsselung ist ebenfalls eine Bedingung sine qua non für eine sichere Übertragung des Content-Keys. Der Medienserver besitzt zwei HTTP-Endpunkte, die beide die Legitimität des Aufrufs eines verschlüsselten Medien-Assets überprüfen können. Die beiden Endpunkte sind:

die master.m3u8 im Hauptverzeichnis des Medien-Assets,
die Keyinfo-Datei, die der master.m3u8 beigehängt wird.

Beide Dateien können mit einer Weblogik ausgestattet werden, also Scripts verwendet werden, um die Attribute eines HTTP GET- Aufrufs zu verifizieren. Zu den Attributen, die beide Dateien verifizieren können, gehören:

diverse Felder des HTTP-Headers, die u.a. den Ursprung des Aufrufs dokumentieren. Diese können jedoch durch jeden HTTP-Client, der die Manipulation der Header zulässt, umgangen werden.
CORS-Header (Cross-Origin Resource Sharing), die im Webserver konfiguriert werden, können ebenfalls nicht-legitime Aufrufe von REST-Ressourcen stoppen, doch kann dies ebenfalls durch Manipulation der Header der HTTP-Anfrage umgangen werden.
den WATCH.TOKEN, über den der Webserver das Nutzungsrecht per se kontrolliert, das durch den Medienserver und seine Zuschauerpolitik gewährt wird (basierend auf Beiträgen, Nutzungsrechten in einer Groupware, usw.). Bei einem legitimen Aufruf des Medien-Assets, also keinem Angriff, der in dieser Beschreibung erschwert werden soll, sollte der WATCH.TOKEN die entscheidende Information über die Herausgabe der Keyinfo beinhalten.
ein noch zu erstellendes Public Key System, dass die Originalität des Clients (in diesem Fall der Webbrowser) mittels zusätzlicher, individueller und verschlüsselter Attribute verifiziert. Zu den Attributen, die die Originalität des Clients verifizieren, gehören u.a. die Session-ID, die der Webserver einem eingeloggten User erteilt, sowie die o.g. HTTP-Header, die in der verschlüsselten Nachricht zwecks Verifizierung der Anfrage verbaut sein können.

Diese verschlüsselten Nachrichten können anschließend per HTTP GET- Aufruf sowohl an die master.m3u8 übermittelt werden, sowie wahrscheinlich ebenfalls an die virtuelle Keyinfo-Datei, was noch durch Experimente verifiziert werden muss. Eine HTTP GET- Anfrage kann Zusatzinformationen über die URI übermitteln, die ein HLS-Player zustandslos an die master.m3u8 übermitteln kann, indem die URL, die der Browser aufruft, dynamisch erstellt wird. Wiederum kann die master.m3u8 dieselben oder andere Nachrichten an die Keyinfo-Datei per HTTP GET-Syntax übermitteln.

Die Keyinfo-Datei sollte eine temporäre, virtuelle URI sein, die nach dem Konsum durch den Zuschauer-Aufruf entfernt werden muss. Diese virtuelle Datei sollte ebenfalls nur erstellt werden bzw. abrufbar sein, sofern ein WATCH.TOKEN erfolgreich generiert wurde. Die Keyinfo-Datei sollte optimalerweise auf den Konsum durch diesen expliziten WATCH.TOKEN mittels eines allgemein gültigen Aufrufs warten und die virtuelle URI anschließend entfernt werden, da sie nach einem gültigen Aufruf theoretisch von keinem anderen Ereignis mehr gebraucht wird.

Der Javascript-Code, den ich in diesem Beispiel vorgesehen habe, kann ebenfalls Mechanismen enthalten, die die für einen Angreifer relevanten Informationen unkenntlich machen.

Angreifer analysieren als erstes die Kommunikation zwischen ihrem Client und dem angepeilten Webserver, in diesem Fall dem Medienserver. Der Javascript-Code, der im Player verbaut ist, ist das erste Angriffsziel, um seine Funktionsweise nachzuvollziehen und zu lernen, sie zu imitieren. Bei einem erfolgreichen, bösartigen Nachbau der Funktionsweise des Einstiegscodes, kann ein Angreifer, solange er unbemerkt bleibt, weiter in die interne Logik des Servers vorrücken, diese ebenfalls experimentell mittels der imitierten XHR-Aufrufe des Webclients analysieren usw. Schließlich kommt der Angreifer, sofern die eingebauten Schutzmechanismen ihn nicht effektiv verzweifeln lassen, zum Ziel, also der Einsicht in die Schlüsseldatei eines Medien-Assets im Klartext. Falls der Angreifer die Prozedur, die er dazu entwickelt hat, zu einem Automatismus umbauen kann, ist quasi der gesamte Medienbestand an ihn ausgeliefert.

Der Keyserver kann ebenfalls einen Alarm-Trigger besitzen, der typische Reverse Engineering- Ansätze erkennt und den Angreifer gewähren lässt, um ihn mit angeblichen Fortschritten in ein Labyrinth zu locken, in dem ihm widersprüchliche und falsche Informationen, inklusive frei erfundener Content-Keys, als Köder präsentiert werden, die ihn immer wieder zum selben Ausgangspunkt führen.

Zum Einen können XHR-Anfragen mittels eines Base64 Kodierers verpackt werden, was die ‚on-the-fly‘-Erkennung der Informationen in den Header erschwert¹⁰².

Des Weiteren kann der gesamte Javascript-Code mit einem sog. Obfuscator unkenntlich gemacht werden. Der unter https://www.obfuscator.io/ beschriebene Quellcode-Kodierer behauptet, gegen existierende Dekodierer z.T. immun zu sein. Es ist diskutabel, ob dieses Verfahren effektiv ist. Es ist jedoch funktional und solche Verfahren erschweren i.d.R. nur einer gewissen Randgruppe, und nicht allen möglichen Teilnehmern, den illegalen Zugriff auf geschützte Daten. Deswegen ist es nicht abwegig, den Javascript-Code, der direkt im Player verbaut ist, und der als Einstiegsdatenflow für den Aufruf der Keyinfo dient, mit einem Obfuscator unkenntlich und damit die Analyse des Codes, der als erster über den Zugriff eines Zuschauers auf einen geschützten Bereich entscheidet, und ihn an weitere Sicherheitschecks leitet oder sofort abweist, deutlich erschweren.

Weitere Methoden zur sicheren Übertragung eines Content-Keys in einer webbasierten Umgebung müssen noch erdacht und erprobt werden. Diese Denkansätze können ein Anstoß sein, sie sind aber bei Weitem nicht komplett und bieten keine fertige Lösung.

Eine zusätzliche Komponente, die dem Projekt hinzugefügt werden kann, ist eine Beispiel-App für die Betriebssysteme Android sowie iOS. So eine App sollte nach den in dieser Arbeit beschriebenen Anforderungskriterien erstellt werden. Weitere Funktionen, wie etwa Web Analytics und Social Media, kann ein versierter Webentwickler selbst hinzufügen.

Auch die in diesem Teil beschriebenen Techniken zur sicheren Übertragung eines Content-Keys lassen sich auf viele Frameworks zur App-Entwicklung übertragen oder direkt anwenden. Neben Android Studio und Xcode gibt es zahlreiche andere Frameworks zur mobilen App- und Desktop-Entwicklung, die ebenfalls die erstellten HLS-Streams integrieren können, denn i.d.R. wird die HLS Unterstützung vom Betriebssystem gestellt und muss vom App Framework lediglich eingebunden werden. Ebenso verhält es sich mit der Übermittlung von Informationen über einen HTTP GET- Aufruf. Solche Aufrufe werden von jedem HTTP-Client standardmäßig verarbeitet, was auch der Fall bei einem HLS-Player ist, der von einen HTTP-Client als Transportschicht Gebrauch macht.

Der dieser Arbeit beigefügte und in ihr integrierte Flowplayer war noch zu den Zeiten der Beliebtheit von Flash Streaming Verfahren, wie dem RTMP-Protokoll und Progressive Download, beim Einbinden der Videoinhalte in Webseiten sehr verbreitet, da auch eine kostenlose Version zur Verfügung steht und seit jeher dutzende eingebaute Funktionen für Web Analytics und Branding beinhaltet waren.

Dennoch ist es mit dem Advent der Media Source Extension und der direkten Interpretation von Streaming Media durch Browser und Betriebssysteme erstrebenswert, auf 3rd Party-Player zu verzichten und eine eigene Playoutlösung zu programmieren. Die Transportschicht von HLS-Streams wird vom hls.js-Plugin verlässlich bedient. Weiterhin kann der Browser die empfangenen MPEG-TS Dateien direkt darstellen. Deswegen ist der Entwurf eines auf die persönlichen Bedürfnisse bzw. das Kommunikationskonzept zugeschnittenen Players ein wichtiger Baustein einer integrierten VoD-Lösung. Der Player bietet die Möglichkeit, die Verwertung der Medien direkt zu kontrollieren, das Zuschauerverhalten zu analysieren und schließlich, Player und Anwendungen zu entwerfen, die auf vertikale Märkte zugeschnitten sind, wie Unterhaltungsmusik, klassische Musik, Sportsendungen, Reiseziele, TV Opern, Reality TV und alle anderen Sparten, die sich in einem integren und logisch verbundenen Angebot zusammenfügen lassen. Dadurch können Webplayer sowie Mobile Player für nahezu jeden Anwendungsfall entstehen, den man sich erdenken kann. Auf diese Weise kann sowohl ein Musiktheaterfestival wie ein beliebiger Fussballklub seine eigene App mit einem mehr oder minder aufwendigem Apparat an Vermarktungs- und Verwertungsalgorithmen und seiner eigenen und individuellen Videonarration erstellen.

Auf der Überholspur zur Webvideovermarktung gab es wenige Versuche, aus den begangenen Fehlern bei der Markteinführung von Breitbandvideo über Telefonkabel und andere moderne Übertragungsmedien zu lernen. Das Erkenntnispotenzial liegt nicht nur darin, diese Fehler nicht zu wiederholen. Es kann auch positive Informationen über erprobte Methoden liefern, wie ein neues Medium effektiv auf den Markt zu bringen sei. Des Weiteren verbergen sich in den Fallstudien von Unternehmungen, die gescheitert sind, wertvolle Informationen, welche Faktoren zu ihrer Niederlage geführt haben könnten und wie sie bei einer Marktneueinführung vermieden werden können. Ein gutes Beispiel ist nicht jede neue Extrafunktionalität für den Stein der Weisen zu halten. France Telecom hat eine „neue“ Dienstleistung überprüft, die Webseiten wie auch TV-Programme mit Gerüchen ergänzt hat. Eine ähnliche Technologie „Smell-o-Vision“ wurde in den 1950ern in den Kinos in den U.S.A. eingeführt, um die TV-Zuschauer wieder in die Kinos, mit dem Versprechen eines tieferen Erlebnisses, zu locken. Die Zuschauer fanden den Effekt jedoch wenig reizvoll¹⁰³.

Ähnlich verhält es sich mit den Inhalten. Eine McLuhan zugeschriebene Äußerung lautet, dass Menschen dazu tendieren, neue Medien mit alten Medien zu füllen. Die ersten TV-Programme waren visualisierte Radioprogramme. Die ersten Radioprogramme haben dramatische Elemente aus der Gutenberggalaxie entliehen. Es würde ebenso lange dauern, die Charakteristik eines komplett neuen Mediums nachzuvollziehen, um darauf zugeschnittene Unterhaltungserlebnisse liefern zu können¹⁰⁴.