­čçę­čç¬ Video­čÄ×´ŞĆ Microservice­čľą´ŞĆ Konzept­čôł (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 Web84.

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.WortlautMUSSSOLLKANNKommentar
1Webupload von DateienX

Upload zwecks Transkodierung
2cURL-Bibliothek f├╝r Upload v. http/s,ftp URIÔÇśs
X
Automatischer Upload von Mediendateien aus dem Internet
3Integration des aria2-client

XAutomatischer Upload von http/s, ftp, sftp, magnet, usw. -URIÔÇśs
4Transkodierung einer Audio-/Videodatei in ein WebstreamingformatX

Basiskonzept der Arbeit: ÔÇ×Automatisches VideowebpublishingÔÇť.
5Quelldateianalyse mit ffprobeX

Wie hoch ist die Qualit├Ąt der Quelldatei?
6Transkodierung in adaptive Bitraten unter Ber├╝cksichtigung der Ursprungsqualit├ĄtX

Analyse der Ursprungsqualit├Ąt und stufenweise Transkodierung in Profile mit geringerer Qualit├Ąt (vgl. Bitrate) als das Original
7Messung der Ergebnisbitraten der jeweiligen Videoprofile f├╝r die m3u8-MetadateiX

Das HLS-Format und alle seine Profile m├╝ssen durch einen Pseudoclient gestreamt und statistisch gemessen werden
8Messung der Ergebnisaufl├Âsung der jeweiligen Videoprofile
X
Einige Player nutzen zus├Ątzlich die Metainformation ├╝ber die Aufl├Âsung der Profile
94K-Profil f├╝r WebTV
X
Die Originalaufl├Âsung des Videos wird bis zu 2160p transkodiert
10Einstellung des Allow-From-Headers des Medien-Webservers sowie Erstellung einer generischen crossdomain.xmlX

Flash- und HTML5-Player brauchen jeweils verschiedene Webservereinstellungen zum Abspielen des HLS-Streams in einem externen Player aus einer anderen Domain
11Konfiguration der Cache-eigenschaften des Webservers
X
Da der Server statischen Content liefert, empfiehlt sich eine lange Cachelebensdauer
12Verschl├╝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.
13Einbindung eines SessionID-Verfahrens zus├Ątzlich zum AES-Protokoll

XDurch die Verwendung von SessionIDÔÇśs kann festgelegt werden, welcher Computer die freigegebene Mediendatei im Netz abrufen kann
14Laufender Betrieb des API-Servers mit SSLX

Der Webupload der Mediendateien sollte verschl├╝sselt stattfinden
15SSL-Option f├╝r Medienserver
X
Zus├Ątzliche Sicherheit dank SSL-Verschl├╝sselung
16Aktueller Fortschritt des Transkodierungsprozesses

XFFmpeg stellt Statusinformationen ├╝ber einen TCP-Server bereit
17Intel QuickSync Video -Integration

XFFmpeg-Bibliothek sowie Syntax des QSV-Transcoders
18Trennung von Medienserver-Logik und Transcoder-Logik
X
Der Medienserver funktioniert mit Mindesthardwareanforderungen ungest├Ârt vom Transcoder
19Skalierbarkeit des Transcoders

XTranscoder kann auf beliebig viele Maschinen skaliert werden
20Skalierbarkeit des httpd

XDer Medienspeicher kann mit Dateisystemwerkzeugen skaliert, kopiert und optimiert werden
21Skalierbarkeit der Bandbreite

XDie Bandbreite kann durch FTP-Mirrors und einen Geo-Proxy auf viele Server diffus skaliert werden
22Content Delivery Network-Nutzbarkeit und -Integration

XDurch die Verwendung des http/s- Protokolls kann jedes CDN direkt auf die Medien zugreifen
23Webcache-Nutzbarkeit

XWebcaches k├Ânnen HTTP-Pakete zwischenspeichern, je nach Cachekonfiguration des httpd
Tabelle 8: MUSS-SOLL-KANN Kriterien der REST API

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. Der API-Server sollte per default mit SSL betrieben werden, damit die Zeichenfolgen der Authorisierungstokens nicht im Internet als reiner Text verschickt werden.
  15. 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.
  16. FFmpeg h├Ąlt w├Ąhrend seiner Arbeit eine aktuelle Statusinformation ├╝ber einen TCP-Feed (-progress PORTNUMMER85) bereit. Diese Information kann vom master.m3u8-Skript gelesen und dem Enduser als Platzhalter serviert werden, solange die Transkodierung noch nicht abgeschlossen ist.
  17. Intel QuickSync Video86 (kurz: Intel QSV) erm├Âglicht die Ausnutzung des Haswell-Chipsets87 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.
  18. 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.
  19. 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├╝tzt88 und alle Maschinen auf denselben Network Area Storage (NAS) Zugriff haben.
  20. 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.
  21. 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.
  22. 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.
  23. 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.WortlautMUSSSOLLKANNKommentar
1Zugriff auf HTTPS REST-EndpunkteX

Die Programmiersprache muss die Kommunikation ├╝ber HTTPS mit REST-Endpunkten erm├Âglichen
2Eingebauter persistenter Speicher (Datenbank oder Dateisystem) f├╝r TokensX

Die Tokens f├╝r die Freigabe (Abspielen und L├Âschen) einzelner Medien-Assets m├╝ssen vom Webfrontend oder vom Webclient persistent gespeichert werden.
3Upload ├╝ber HTTPS-Multipart UploadX

Der HTTPS-Upload erm├Âglicht das Einf├╝gen eines Medien-Assets
4Anzeige der verf├╝gbaren Medien-Assets (Liste mit Screenshot-Ikonen)X

Optimalerweise sollten die hochge-ladenen Medien-Assets nach dem Playlistprinzip angezeigt werden
5Abspielen eines Assets
X
Das Asset sollte direkt von der Playliste in den Playmodus schalten
6Teilen des Assets (URL) mit anderen (IM, Social Media)

XVon Vorteil ist eine minimale Social Media Funktionalit├Ąt, wie Teilen und OpenGraph Metadaten
7Beschreibung hinzuf├╝gen, Querverweise zu Webseiten oder Social Media Accounts

XEinbindung von Querverweisen in die Beschreibung (bei Autoren, die eigene Musik ver├Âffentlichen, etwa auf Verwertungsseiten, wie iTunes)
8Kommentare, Forum, Benutzerverwaltung, Chat usw.

XZus├Ątzlich zu den reinen Playout-Funktionen kann eine ganze Community entstehen
Tabelle 9: MUSS-SOLL-KANN Kriterien eines Frontends f├╝r die REST API
  1. Der Zugriff auf REST API- Endpunkte erm├Âglicht den Austausch von Tokens. HTTPS verschl├╝sselt diese Zeichenfolgen im Internetverkehr.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Abschlie├čend kann die App serverseitig eine Community verwalten, etwa durch das Einbinden der REST API in ein existierendes Webframework oder eine Groupware.