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

5. Anforderungsanalyse

In der Anforderungsanalyse stelle ich zuerst die Abgrenzungskriterien vor, um zu den MUSS-SOLL-KANN Kriterien überzugehen. Die Kriterien sind in Teil 5.2. für den Webencoder konzipiert. Die Anforderungen an eine Benutzerschnittstelle wurden separat im dritten Teil erläutert.

5.1. Abgrenzungskriterien

Bei der vorgestellten Arbeit handelt es sich nicht um:

Ein Skript zum automatischen Einbinden von Videoinhalten in Blogs wie etwa WordPress
Einen sog. Playlistgenerator, der existierende Inhalte auf einer Webseite zusammenfügt
Einen Medienplayer mit vordefiniertem Frontend und besonderen Funktionalitäten, wie bspw. Metadaten für Musik und Filme
Eine komplette Web API zur Gestaltung der Medieninhalte, Verwaltung der Benutzer, statistischen Vermessung der Useraktivität, Foren, Kommentare, Verlinkung, Werbung, etc.

Das vorgestellte Programm macht jedoch von einigen der o.g. Werkzeuge Gebrauch, wie die Erstellung von .m3u-Playlisten der generierten Medieninhalte sowie OpenGraph Metadaten zur menschlich lesbaren Kennzeichnung der Inhalte im Social Web⁸⁴.

5.2. MUSS-SOLL-KANN Analyse – REST API / Transcoder

Die vorgestellte Anforderungsanalyse beschreibt einen API-Server ohne Nutzerinterface. Mittels des http-Protokolls kann die REST API jedoch komfortabel und sicher von einer Smartphone App oder einer AngularJS-Webseite angesteuert werden, deren Beispiel in Teil 5.3. beschrieben wurde.

Nr.	Wortlaut	MUSS	SOLL	KANN	Kommentar
1	Webupload von Dateien	X			Upload zwecks Transkodierung
2	cURL-Bibliothek für Upload v. http/s,ftp URI‘s		X		Automatischer Upload von Mediendateien aus dem Internet
3	Integration des aria2-client			X	Automatischer Upload von http/s, ftp, sftp, magnet, usw. -URI‘s
4	Transkodierung einer Audio-/Videodatei in ein Webstreamingformat	X			Basiskonzept der Arbeit: „Automatisches Videowebpublishing“.
5	Quelldateianalyse mit ffprobe	X			Wie hoch ist die Qualität der Quelldatei?
6	Transkodierung in adaptive Bitraten unter Berücksichtigung der Ursprungsqualität	X			Analyse der Ursprungsqualität und stufenweise Transkodierung in Profile mit geringerer Qualität (vgl. Bitrate) als das Original
7	Messung der Ergebnisbitraten der jeweiligen Videoprofile für die m3u8-Metadatei	X			Das HLS-Format und alle seine Profile müssen durch einen Pseudoclient gestreamt und statistisch gemessen werden
8	Messung der Ergebnisauflösung der jeweiligen Videoprofile		X		Einige Player nutzen zusätzlich die Metainformation über die Auflösung der Profile
9	4K-Profil für WebTV		X		Die Originalauflösung des Videos wird bis zu 2160p transkodiert
10	Einstellung des Allow-From-Headers des Medien-Webservers sowie Erstellung einer generischen crossdomain.xml	X			Flash- und HTML5-Player brauchen jeweils verschiedene Webservereinstellungen zum Abspielen des HLS-Streams in einem externen Player aus einer anderen Domain
11	Konfiguration der Cache-eigenschaften des Webservers		X		Da der Server statischen Content liefert, empfiehlt sich eine lange Cachelebensdauer
12	Verschlüsselung der HLS-Dateien mit AES-256 sowie ein tokenbasierter Abspielmechanismus		X		Abspielmechanismus für eine individuelle, konditionierte Freigabe des Keys in Folge einer Authorisierung des Users.
13	Einbindung eines SessionID-Verfahrens zusätzlich zum AES-Protokoll			X	Durch die Verwendung von SessionID‘s kann festgelegt werden, welcher Computer die freigegebene Mediendatei im Netz abrufen kann
14	Laufender Betrieb des API-Servers mit SSL	X			Der Webupload der Mediendateien sollte verschlüsselt stattfinden
15	SSL-Option für Medienserver		X		Zusätzliche Sicherheit dank SSL-Verschlüsselung
16	Aktueller Fortschritt des Transkodierungsprozesses			X	FFmpeg stellt Statusinformationen über einen TCP-Server bereit
17	Intel QuickSync Video -Integration			X	FFmpeg-Bibliothek sowie Syntax des QSV-Transcoders
18	Trennung von Medienserver-Logik und Transcoder-Logik		X		Der Medienserver funktioniert mit Mindesthardwareanforderungen ungestört vom Transcoder
19	Skalierbarkeit des Transcoders			X	Transcoder kann auf beliebig viele Maschinen skaliert werden
20	Skalierbarkeit des httpd			X	Der Medienspeicher kann mit Dateisystemwerkzeugen skaliert, kopiert und optimiert werden
21	Skalierbarkeit der Bandbreite			X	Die Bandbreite kann durch FTP-Mirrors und einen Geo-Proxy auf viele Server diffus skaliert werden
22	Content Delivery Network-Nutzbarkeit und -Integration			X	Durch die Verwendung des http/s- Protokolls kann jedes CDN direkt auf die Medien zugreifen
23	Webcache-Nutzbarkeit			X	Webcaches können HTTP-Pakete zwischenspeichern, je nach Cachekonfiguration des httpd

Tabelle 8: MUSS-SOLL-KANN Kriterien der REST API

Der Multipart-Webupload ist die Kernfunktion der API und ermöglicht den effektiven Empfang von bis zu 2GB großen Mediendateien von verschiedenen Programmen, wie Webseiten, Mobile Apps, Shellprogramme wie cURL und lynx.
Die cURL-Bibliothek ermöglicht serverseitig den Download einer vom User bzw. dem Frontend definierten URL. Dies vergrößert die effektive Maximalgröße der Mediendatei bis zu 10GB.
Der aria2-client ermöglicht den Download aller gängigen Medien-URL‘s in der Konsole. Seine Integration erweitert die möglichen Medienquellen und vereinfacht den Download von sehr großen Dateien bzw. Dateimengen. Der bereits verwendete Jobserver kann den aria2-client nach dem Status abfragen und anschließend die Enkodierung in Gang setzen.
Es fehlt im aktuellen Streaming-Universum an einem Open Source Skript, dass die Erstellung eines weboptimierten Streams mit adaptiven Bitraten unterstützt. Die verfügbaren, überwiegend kostenpflichtigen Videoupload-Skripte unterstützen entweder lediglich ein Profil bzw. werden als Software as a Service angeboten.
Ein Videoupload selbst braucht wenige Schritte und kommt ohne Quelldateianalyse, bis auf die automatische Analyse von FFmpeg aus. Um jedoch bspw. zwischen Audio- und Videodatei zu unterscheiden, ist ein Einblick in die Attribute der Mediendatei notwendig.
Der Einblick in die Audio-/Videoparameter gibt gleichzeitig Auskunft über die Qualität der Quelldatei. Dabei wurden als Qualitätsindikatoren die Bitrate bei Audiodateien und die Linienanzahl (360p, 480p, 576p, usw.) bei Videodateien gewählt. Gleichzeitig wurde die Qualitätsabstufung der Audio-/Videoprofile sehr fein gestaltet, damit das Ergebnisvideo möglichst originalgetreu bleibt und gleichzeitig fließend unter verschiedenen Bedingungen abgespielt werden kann.
Damit die Abstufung in verschiedene Qualitätsprofile im HLS-Format vom Player erkannt werden kann, muss eine m3u8-Datei als Index der verschiedenen Profile erstellt werden. Die Metainformation über die Bitrate der jeweiligen Profile ist notwendig, damit der Player die verschiedenen Qualitätsstufen effektiv aufrufen kann.
Eine zusätzliche Metainformation für einen HLS-Player ist die Auflösung eines jeweiligen Videoprofils, die je nach HLS-Implementation ebenfalls vom Player berücksichtigt wird, um kein Profil zu laden, das eine höhere Auflösung besitzt als das Playout-Fenster.
Da die momentan handelsüblichen Rechner und Browser verbunden mit einer schnellen Internetverbindung bereits die technischen Empfangsbedingungen für 4K-Webvideo erfüllen, ist die Maximalauflösung des Transcoders auf 4K gesetzt.
Für den Playout des HLS-Streams durch einen externen Player in einer anderen Webdomain als die Quelldomain des HLS-Streams, müssen bei einem Flash-Player die crossdomain.xml im Webroot vorhanden sein sowie bei HTML5-Playern der «Access-Control-Allow-Origin»-HTTP-Header auf «*» gesetzt sein.
Damit der Medienserver effektiv Gebrauch von Webcaches sowie Browsercaches machen kann, muss er für die MPEG-Transport Stream-Dateien mit dem .ts-Suffix ein sehr hohes Verfallsdatum konfigurieren, was bei wiederholten Aufrufen desselben Streams den Traffic verhältnismässig entlasten und das Datenvolumen des Servers verringern kann.
Der FFmpeg-Transcoder bietet eine eingebaute AES-256 Medienverschlüsselung mittels der openssl-Bibliothek. Bei AES über HTTP werden die verschlüsselten Dateien ebenfalls in Webcaches abgespeichert, was den Server bei wiederholtem Zugriff entlastet und gleichzeitig eine gewisse Sicherheit der Inhalte trotz der Zwischenspeicherung bietet.
Das PHP-Skript master.m3u8, das interaktiv entscheidet, ob der Player die Keyinfo für die Inhalte erhält, kann gleichzeitig über eine SessionID forcieren, dass nur ein einziger Zuschauer gleichzeitig auf den Stream zugreift.
Der API-Server sollte per default mit SSL betrieben werden, damit die Zeichenfolgen der Authorisierungstokens nicht im Internet als reiner Text verschickt werden.
Für eine erhöhte Sicherheit der User kann der Medienserver ebenfalls über HTTPS betrieben werden. Zusammen mit AES-256, das zusätzlich die Inhalte selbst verschlüsselt, ist die Sicherheit höher als mit bloßer Medienverschlüsselung, zu Lasten der Performance.
FFmpeg hält während seiner Arbeit eine aktuelle Statusinformation über einen TCP-Feed (-progress PORTNUMMER⁸⁵) bereit. Diese Information kann vom master.m3u8-Skript gelesen und dem Enduser als Platzhalter serviert werden, solange die Transkodierung noch nicht abgeschlossen ist.
Intel QuickSync Video⁸⁶ (kurz: Intel QSV) ermöglicht die Ausnutzung des Haswell-Chipsets⁸⁷ in moderneren i5- und i7-Prozessoren zum Enkodieren von H.264- sowie H.265-Videos. Dieses Verfahren entlastet die CPU-Kerne erheblich v.A. bei der Transkodierung von H.265- sowie 4K-Inhalten.
Der Transcoder nimmt während seiner Arbeit alle Resourcen des Hosts in Anspruch. Deswegen ist es von Vorteil, die Medieninhalte auf einem gesonderten Webserver zur Verfügung zu stellen, da dieser sonst erhebliche Antwortzeiteinbußen durch einen zum Webserver parallel laufenden Transcodingsprozess erleiden würde.
Durch die Verwendung des Gearman Jobservers und eines Network Area Storage kann die Rechenarbeit der Encodingprozesse – sollten es viele sein – gleichmäßig auf viele seperate Transcoder verteilt werden, da der Gearman Jobserver einen gemeinsamen Jobpool für verteilte Anwendungen unterstützt⁸⁸ und alle Maschinen auf denselben Network Area Storage (NAS) Zugriff haben.
Der Medienspeicher kann bei unverschlüsselten Inhalten lediglich durch einen entsprechend konfigurierten rsync-Aufruf repliziert werden. Bei verschlüsselten Inhalten muss zusätzlich die Token– sowie die Media-Tabelle der Datenbank kopiert werden, um auf die verschlüsselten Inhalte zugreifen zu können.
Die Bandbreite kann durch die Skalierbarkeit sowohl der Encoder– als auch der Webserver-Komponente ebenfalls multipliziert werden. Entweder innerhalb desselben Netzwerkes durch Hinzufügen eines zusätzlichen Webservers oder durch die Spiegelung des Medienspeichers in ein anderes Netzwerk und die Verwendung eines Proxy bzw. Load Balancers.
Content Delivery Networks können zusätzlich zu den eigenen Spiegelservern das Volumen balancieren und in entfernten Weltteilen eine schnelle Ladezeit ermöglichen. Es kann bei unverschlüsselten, statischen Inhalten eine reine HTTP Option bei den meisten Anbietern gebucht werden, wodurch die Kosten im Verhältnis zu anderen CDN Broadcast-Tarifen erheblich sinken.
Bei korrekter Cachekonfiguration des Medienservers kann das Datenvolumen bei vielen wiederholten Aufrufen desselben Inhalts erheblich reduziert werden. Ein klassisches Beispiel ist ein Viralvideo, das unerklärlicherweise plötzlich Verbreitung von epidemischem Ausmaß findet. Durch eine korrekte Cachekonfiguration kann die effektive Zahl der Zuschauer von VoD-Inhalten erhöht werden und damit der Verschwendung von Ressourcen (Datenvolumen) vorgebeugt werden.

Die Anforderungsanalyse an eine Beispielapp wird im nächsten Unterkapitel kurz besprochen. Die einzelnen Punkte der Tabelle werden nach ihr einzeln erläutert.

5.3. MUSS-SOLL-KANN Analyse – Frontend / Player

Das Frontend kann durch REST-Methoden mit dem Encoder kommunizieren und hat Zugriff auf alle relevanten Funktionen. Die folgende Tabelle erläutert die Mindestanforderungen an die App (mobile und web), damit der Videoupload-Workflow genutzt werden kann.

Nr.	Wortlaut	MUSS	SOLL	KANN	Kommentar
1	Zugriff auf HTTPS REST-Endpunkte	X			Die Programmiersprache muss die Kommunikation über HTTPS mit REST-Endpunkten ermöglichen
2	Eingebauter persistenter Speicher (Datenbank oder Dateisystem) für Tokens	X			Die Tokens für die Freigabe (Abspielen und Löschen) einzelner Medien-Assets müssen vom Webfrontend oder vom Webclient persistent gespeichert werden.
3	Upload über HTTPS-Multipart Upload	X			Der HTTPS-Upload ermöglicht das Einfügen eines Medien-Assets
4	Anzeige der verfügbaren Medien-Assets (Liste mit Screenshot-Ikonen)	X			Optimalerweise sollten die hochge-ladenen Medien-Assets nach dem Playlistprinzip angezeigt werden
5	Abspielen eines Assets		X		Das Asset sollte direkt von der Playliste in den Playmodus schalten
6	Teilen des Assets (URL) mit anderen (IM, Social Media)			X	Von Vorteil ist eine minimale Social Media Funktionalität, wie Teilen und OpenGraph Metadaten
7	Beschreibung hinzufügen, Querverweise zu Webseiten oder Social Media Accounts			X	Einbindung von Querverweisen in die Beschreibung (bei Autoren, die eigene Musik veröffentlichen, etwa auf Verwertungsseiten, wie iTunes)
8	Kommentare, Forum, Benutzerverwaltung, Chat usw.			X	Zusätzlich zu den reinen Playout-Funktionen kann eine ganze Community entstehen

Tabelle 9: MUSS-SOLL-KANN Kriterien eines Frontends für die REST API

Der Zugriff auf REST API- Endpunkte ermöglicht den Austausch von Tokens. HTTPS verschlüsselt diese Zeichenfolgen im Internetverkehr.
Das Frontend muss grundsätzlich über einen eigenen Speicher für die MEDIA.TOKENs verfügen. Ohne diese Tokens schlägt die Verifizierung fehl und das Medien-Asset kann weder gelöscht noch bei verschlüsselten Inhalten abgespielt werden.
Der Multipart Upload ist die verhältnismäßig einfachste Weise, um eine Webupload-Funktionalität zu realisieren. Zusätzlich kann ein dedizierter (s)ftp-client mit einem Web- oder Mobile- Interface sicherere Uploads, das Fortsetzen von fehlgeschlagenen Uploads usw. ermöglichen.
Durch den persistenten MEDIA.TOKEN-Speicher können Playlisten mit Vorschau direkt im Frontend generiert werden, indem die App die Mediendatenbank nach diesen Schlüsseln und den passenden Metadaten abfragt.
Neben dem Abspielen von unverschlüsselten Medieninhalten durch ein einfaches Aufrufen der m3u8-Datei bzw. eines Webplayers, sollte das Frontend ebenfalls das Abrufen eines WATCH.TOKEN‘s sowie demnach das Abspielen von verschlüsselten Inhalten integrieren.
Das OpenGraph Protokoll beschreibt einen Standard für die Metadaten eines Webinhalts. Neben der richtigen Indexierung in Suchmaschinen ist dieses Protokoll gleichzeitig für ein ästhetisches Einbinden in Social Media Seiten sowie in vielen Instant Messenger- Anwendungen verantwortlich, was bei Videoinhalten in Social Media relevant für die Zahl der Aufrufe ist.
Neben Metadaten für externe Anwendungen kann die App eigene Metadaten für den Playout sowohl in Web als auch Mobile verwalten, damit neben dem Video zusätzliche menschlich lesbare Informationen, wie Querverweise auf Verwertungslinks bei Verlegern oder zusätzliche Quellen bei Reportagen, Dokumentationen usw. vorhanden sind.
Abschließend kann die App serverseitig eine Community verwalten, etwa durch das Einbinden der REST API in ein existierendes Webframework oder eine Groupware.