­čçę­čç¬ Video­čÄ×´ŞĆ Microservice­čľą´ŞĆ Konzept­čôł (2018)­čÉ╗

4.3. Streamingkomponenten

Streamingl├Âsungen m├╝ssen die komplette Distributionskette zwischen Anbieter und Zuschauer realisieren:

Content Ôćĺ Encoder

Ôćô

Streaming Server

Ôćô

Decoder Ôćĺ Playout53

Es ist ersichtlich, da├č der Streaming Server die Schnittstelle zwischen der Dom├Ąne des IPTV-Anbieters (Content Ôćĺ Encoder) und der Dom├Ąne des IPTV-Zuschauers (Decoder Ôćĺ Playout) darstellt und er deswegen f├╝r die Kommunikation beider Dom├Ąnen miteinander verantwortlich ist. Der Encoder steht sowohl f├╝r den Medienencoder wie f├╝r die Verschl├╝sselung, sprich die ganze Vorbereitung des Medienassets, die f├╝r den Transport zum User notwendig ist. Ebenso steht der Decoder f├╝r alle Algorithmen, die notwendig sind, um das Medium korrekt zu dekodieren und auf einem Player (Web, Smartphone, SmartTV, etc.) darzustellen.

Streaming Server gibt es, seitdem es die Audio-/Video├╝bertragung per TCP/IP gab. Das ÔÇ×UrprotokollÔÇť ist das Real-time Streaming Protocol (RTP), das grunds├Ątzlich das Live├╝bertragen von Audio-/Videodaten seit den fr├╝hen 1990er Jahren erm├Âglicht und diverse Weiterentwicklungen erlebt hat, wie die RTSP (VCR-Funktionalit├Ąt), RTCP (Datenstromkontrolle) und RSVP (Quality of Service) -Protokolle.

In der j├╝ngeren Internetgeschichte gab es Entwicklungen in drei Richtungen: propri├Ątere Protokolle wie Windows Media, Silverlight, Adobe Flash (RTMP) und Adobe HDS, daneben offene Protokolle, wie das Apple HLS, das WebRTC sowie in der j├╝ngsten Zeit die M├Âglichkeit, audiovisuelle Medien ├╝ber den <video>- bzw. <audio>-Tag direkt in HTML5-Webseiten einzubinden und die Dateien lediglich als HTTP-Download bereitzustellen (analog zum fr├╝heren HTTP Progressive Download).

Es wurden auf der n├Ąchsten Seite drei Beispiele jeweils einer Art von Streaming Servern aufgef├╝hrt. Der erste, Adobe Media Server, ist ein propri├Ąterer Medienserver vom damaligen quasi-Monopolisten auf dem Webvideo-Markt. Der zweite ist eine unabh├Ąngige Entwicklung, die die geschlossenen Protokolle der Hersteller, wie Microsoft und Adobe, am besten imitiert. Das dritte Beispiel ist eine Eigenentwicklung bestehend aus einem hochperformanten Webserver (nginx) und diverser technischer M├Âglichkeiten, einen generischen httpd f├╝r ein hochqualitatives Streamingerlebnis einzurichten, die im praktischen Teil erl├Ąutert werden.

  1. Adobe Media Server ÔÇô Adobe Media Server Family54
  • Hauseigener Flash-basierter Server der Firma Adobe
  • Unterst├╝tzt Flash Video (FLV), HTTP Progressive Download, HTTP Dynamic Streaming (Adobe HDS) und als Kompatibilit├Ątsfeature HTTP Live Streaming (HLS)
  • HLS und HTTP Progressive Download sind unabh├Ąngig vom AMS ÔÇô die beiden anderen Protokolle (Flash und HDS) finden ihre volle Unterst├╝tzung nur in dem Adobe Originalprodukt
  • Wurde eingestellt, da die ganze Flashumgebung bis 2020 ausl├Ąuft
  1. Wowza Streaming Server ÔÇô All-In-One Streamingaggregat
  • Java- und teils Open Source -basierter Server
  • Einer der ersten Streamingserver, die erschwinglich waren (bspw. monatlich mietbare Lizenzpl├Ąne) und die Protokolle der anderen gro├čen Hersteller beherrschte55
  • Die gute Unterst├╝tzung f├╝r das propriet├Ąre Protokoll RTMP machte ihn zu einer echten Alternative in einer damals Flash-dominierten Multimediawelt
  • Fertigt viele Abl├Ąufe in der Mediendistribution automatisch ab
  • Erm├Âglicht eine verh├Ąltnism├Ą├čig intuitive Administration von Medienbest├Ąnden und deren Ver├Âffentlichung sowie Archivierung
  • Sein gro├čer Vorteil, viele verschiedene Protokolle zu beherrschen, schwindet in der Zeit, in der einige wenige Protokolle alle Endger├Ąte abdecken
  • Deswegen liegt der Schwerpunkt von Wowza momentan bei der Automatisierung von Medienabl├Ąufen (bspw. automatische Ver├Âffentlichung in der eigenen Infrastruktur sowie zeitgleich auf Youtube Live, Facebook Live usw.)
  1. nginx
  • nginx ist ein httpd (Hypertext Transfer Protocol Daemon)
  • seine Module ngx_http_mp4_module56 ÔÇô f├╝r HTTP Progressive Download ÔÇô sowie ngx_rtmp_module57 ÔÇô f├╝r on-the-fly Enkapsulierung in HLS und RTMP ÔÇô haben den Webserver schon fr├╝h als Open Source Streaming -Alternative abgehoben58
  • mittlerweile wird der Server bereits mit den vorkonfigurierten MIME Types application/vnd.apple.mpegurl f├╝r HLS-Indexdateien (.m3u8) sowie video/mp2t f├╝r Transport Stream -Dateien (.ts) geliefert und installiert59
  • jegliche Medienabl├Ąufe (Verarbeitung, Ver├Âffentlichung) m├╝ssen manuel programmiert werden
  • zusammen mit FFmpeg (oder einem Transcoder der Wahl) kann nginx (oder ein beliebiger anderer httpd) zu einem vielseitigen Streaming Server umfunktioniert werden

Streaming Server erhalten ihren Input aus einem Encoder, dessen Inhalt sie fliegend in verschiedene Formate enkapsulieren m├╝ssen, damit er auf verschiedenen Endger├Ąten lesbar ist. Dazu z├Ąhlen neben Desktopprogrammen und Smartphones ebenfalls Set-Top-Boxen, etwa f├╝r IPTV-Empfang an einem analogen Fernseher. Ein Encoder muss den Inhalt an den Streaming Server schicken, damit das Signal weiterverarbeitet werden kann. Im Fall von VoD- Inhalten k├Ânnen die Dateien direkt auf das Dateisystem des Streaming Servers kopiert werden, was der technisch einfachste und verl├Ąsslichste Weg ist60. Im Fall von Live- Inhalten muss es direkt an den Streaming Server geschickt werden, etwa ├╝ber UDP Unicast.

Tabelle 6: Live Streaming im Wowza Streaming Server

Der vielseitige Wowza Streaming Server unterst├╝tzt die beschriebenen Live Input- Formate. Gleichzeitig nutzen viele Live Encoder das RTMP-Format aus geschichtlichen Gr├╝nden, da es n├Ąmlich zur Zeit des Live Streaming Booms das per se Format f├╝r Webvideo war und breite Unterst├╝tzung besitzt61.

4.4. Aktuelle technische L├Âsungen

Momentan k├Ânnen Medienadministratoren von folgenden L├Âsungen bzw. Workflows f├╝r den Betrieb einer selbst├Ąndigen VoD-Site Gebrauch machen:

4.4.1. HTML5-Video

Einige Jahre nach der 2012 ins Leben gerufenen Media Source Extension (MSE) haben sich die Browserhersteller auf eine gemeinsame Schnittmenge der unterst├╝tzten Formate geeinigt.

Um vom <video>-Tag der HTML5-Browser Gebrauch zu machen und das eigene Webvideo zu erstellen, wird lediglich ein Webspace ben├Âtigt. Das Video sollte in diversen Formaten abrufbar sein und kann mit dem <video>-Tag auf die Webseite eingebunden werden62. Dies betrifft jedoch nur fertige Videos zum Abrufen mit lediglich einem Profil bzw. einer Bitrate. Mit diesem Verfahren bleibt das Video stehen, wenn nicht genug Bandbreite zur Verf├╝gung steht, und f├Ąhrt erst nach dem Puffern einer ausreichenden Datenmenge fort63.

4.4.2. Flash ÔÇô Progressive Download

Bei Browsern, die weiterhin die Flash-Umgebung zum Darstellen von Live-Video ben├Âtigen, unterst├╝tzt der Flash-Player seit Version 9 Update 3 (version 9.0r115) den H.264-Codec und somit zumindest den Progressive Download bzw. Pseudo-Streaming von mp4-Video-Dateien64. Die mp4-Dateien m├╝ssen vor dem Upload ge-ÔÇťhintedÔÇť werden, d.h. dass die Hinweise zur Dateistruktur nicht wie ├╝blich am Ende der mp4-Datei untergebracht werden, sondern auf den Anfang verschoben werden, was die Ad-Hoc Erkennung der Videol├Ąnge durch den Webserver bei einem HTTP GET- Aufruf erm├Âglicht und somit den Usern ein sog. Pseudo-Streaming Erlebnis zur Verf├╝gung stellt. F├╝r das Abspielen wird der nginx Server empfohlen, da er ├╝ber sein eingebautes ngx_http_mp4_module die mp4-Dateien f├╝r das Abspielen als Progressive Download indexiert. Das Puffern von Videodaten bei mangelnder Bandbreite verh├Ąlt sich genauso wie beim HTML5-Video.

Die ben├Âtigte minimale Versionsnummer f├╝r die Unterst├╝tzung eines Flash HLS-Players konnte nicht gepr├╝ft werden. Die aktuelle Flash-Version 30.0.0.134 unterst├╝tzt mit Erfolg den Flash HLS-Player flowplayerhls.swf im Firefox ESR Browser.

4.4.3. HTTP Live Streaming

Mit dem hls.js-Plugin des Videoportals DailyMotion kann jeder aktuelle HTML5 Browser das HLS-Format darstellen, das auf den H.264- sowie AAC-Codecs aufbaut65 66.

Abbildung 7: Aufbau eines HLS-Dateisystems


Um von der sog. VCR-Funktionalit├Ąt des Protokolls Gebrauch zu machen, also schnelles Vor- und Zur├╝ckspulen des Videos, reicht lediglich ein HLS-Profil mit einer HLS-Indexdatei (auf der Abbildung die Bitrate-LOW/-MID/-HIGH Profilbeispiele67). Um jedoch die drei Profile miteinander zu einem gemeinsamen HLS/ Adaptive Bitrate- Stream zu verbinden, muss eine m3u8-Masterdatei (auf Abbildung 6 die ÔÇ×.m3u8 PlaylistÔÇť) das Inhaltsverzeichnis aller Profile samt gesch├Ątzter Durchschnittsbitrate beinhalten. Deswegen ist es einfach, diese beiden Versionen der m3u8-Datei zu verwechseln, denn die Index-m3u8 enth├Ąlt lediglich das Inhaltsverzeichnis der Transport Stream-Dateien einer einzelnen Bitrate.

Die Master-m3u8 wiederum enth├Ąlt ein Inhaltsverzeichnis verschiedener Profile (sowie von ÔÇ×ProgrammenÔÇť, wie etwa verschiedene ├ťbersetzungen desselben Podcasts)68.

Das Transport Stream -Format, ein Unterformat des 1995 verabschiedeten MPEG2/H.262-Standards69, beschreibt einen digitalen Broadcast in Echtzeitumgebungen mit niedriger Latenz sowie gro├čer Verlustrate der Pakete, und verf├╝gt deswegen ├╝ber eingebaute Fehlerbehebung und Recovery-Funktionen70.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1828000,NAME="Hi3",RESOLUTION=896x504
chunklist_b1828000_t64NCBoaWdo.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=678000,NAME="Med2",RESOLUTION=512x288 
chunklist_b678000_t64MiBtZWQ=.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=438000,NAME="Lo1",RESOLUTION=384x216 
chunklist_b438000_t64MSBsb3c=.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=128000,NAME="0 audio" 
chunklist_b128000_t64MCBhdWRpbw==.m3u8

Quellcode 1: Master-m3u8 mit diversen Aufl├Âsungen in verschiedenen Bitraten

Es ist derselbe Protokollstandard wie im digitalen Rundfunk (DVB). Dank seiner universellen Eigenschaften wird er bis heute mit modernen Codecs im Broadcast genutzt, also l├Ąngst nicht mehr mit dem MPEG-2 Videocodec, mit dem er urspr├╝nglich zusammen verabschiedet wurde. Im hier behandelten Fall hat die Firma Apple Inc. diesen Standard f├╝r das HTTP Live Streaming verwendet71. Die ts-Dateien ├Ąhneln also von ihrer Struktur her den Datenpaketen, die ├╝ber die Fernsehantenne bzw. ├╝ber die Satellitensch├╝ssel vom DVB-Decoder empfangen werden. Sie beinhalten ebenfalls Informationen ├╝ber verschiedene PID (Programm-IDÔÇśs) sowie eine separate Video- und Audiospur. Sie werden der Zeitkodierung entsprechend vom Player im Hintergrund eine nach der anderen vom Webserver abgerufen, gepuffert und dargestellt. Bei Live-Events erfolgt durch die Pufferung der Informationen in den ts-Dateien (von einigen Sekunden) eine diesbez├╝gliche Versp├Ątung in der tats├Ąchlichen Emission im Player des Users.

Als Video- und Audiocodecs f├╝r das HLS-Format hat Apple Inc. H.264 (alias MPEG-4 AVC Part 4 alias MPEG-4 Part 10) als Videocodec sowie MPEG Advanced Audio Coding (AAC) als Audiocodec bestimmt72. Das war eine aus heutiger Sicht vern├╝nftige Entscheidung, denn schon 2010 war abzusehen, dass H.264 der erste seit MPEG-1 von der Industrie breitfl├Ąchig akzeptierte und in vielen tausenden Projekten umgesetzte Codec sein wird. Die Broadcast-Industrie wechselt ebenfalls seit dieser Zeit von MPEG-2 zu H.264, wo die Ressourcen eine Modernisierung der Infrastruktur erlauben73.

HTTP Live Streaming ist also im Grunde die Bezeichnung f├╝r ein Mediendateisystem mit folgenden Eigenschaften:

Abbildung 8: HLS-Dateisystem mit zwei PID
  • Es werden des weiteren verschiedene PID (bspw. ├ťbersetzungen) unterst├╝tzt.
  • Das HTTP Live Streaming -Protokoll kann die einzelnen ts-Dateien mit AES-128, AES-192 oder AES-256 verschl├╝sseln und den Key an authorisierte Clients herausgeben.

Das so aufgebaute Dateisystem kann etwa eine Struktur wie auf Abbildung 8 haben. Der Beispiel-Stream bietet zwei Programme (PID in der MPEG Nomenklatur, i.d.R. dasselbe Programm in verschiedenen Sprachversionen): ÔÇ×EnglishÔÇť und ÔÇ×FrenchÔÇť sowie jeweils 3 Bitraten ÔÇ×360pÔÇť, ÔÇ×720pÔÇť sowie ÔÇ×1080pÔÇť.

Ein so erstelltes Dateisystem bietet viele f├╝r die QoE (Quality of user Experience) wichtige Funktionen.

  1. Die Bitrate passt sich automatisch den Gegebenheiten des Players an, ergo der ├ťbertragungsgeschwindigkeit sowie der Bildschirmgr├Â├če.
  2. Der User kann zwischen diversen Versionen der Hauptspur w├Ąhlen, wie etwa ├ťbersetzungen in verschiedenen Sprachen.

Ein gro├čes Medienprojekt mit vielen Hundert Videos im HLS-Format w├╝rde also immens viel Speicherplatz brauchen, um die Inhalte auch in anspruchsvollen Aufl├Âsungen anzubieten. Der Film Big Buck Bunny (ca. 15 Minuten) hat nach der Transkodierung der FHD-Version zu 10 Profilen mit dem in dieser Arbeit entworfenen HLS-Transcoder 2,5GB gewogen. Die Originaldatei war dabei knapp 600MB gro├č. Eine verh├Ąltnism├Ą├čig (im Vergleich zu einem kommerziellen Medienanbieter) kleine Webvideo-Seite mit bspw. bis zu 100 FHD-Trainingsvideos ├á 15 Minuten dagegen w├╝rde ihren Zweck erf├╝llen und der erforderliche Speicherplatz w├╝rde sich in Grenzen halten (100 x ~2,5GB = ~250GB). Audioproduzenten (bspw. Podcasts und Do-It-Yourself Musiker) dagegen m├╝ssen sich um diese Gr├Â├čenordnungen keine Sorgen machen, denn Audio-Streams brauchen unverh├Ąltnism├Ą├čig weniger Speicherplatz sogar bei sehr hoher Aufl├Âsung.