VIDEO STREAMING

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.