Jahrelang gab es zwei grundlegende Modelle für das Internet-Streaming: serverbasierte, proprietäre Technologie wie RTMP oder progressiver Download. Das serverbasierte Streaming ermöglicht die Bereitstellung von Streams mit mehreren Bitraten, die bei Bedarf umgeschaltet werden können, erfordert aber die Lizenzierung teurer Software. Der progressive Download kann über Apache durchgeführt werden, aber der Wechsel der Bitrate erfordert ein Anhalten der Wiedergabe.
Das Aufkommen von HTTP-basierten Streaming-Protokollen wie HLS und Smooth Streaming bedeutete, dass die Streaming-Bereitstellung über Standard-HTTP-Verbindungen unter Verwendung von Standard-Servertechnologie wie Apache möglich war; nahtloses Umschalten der Bitrate wurde alltäglich und die Bereitstellung über CDNs war einfach, da es im Grunde dasselbe war wie die Bereitstellung jeder Datei über HTTP. HTTP-Streaming hat die Bereitstellung von Streaming-Medien geradezu revolutioniert und die Kosten und die Komplexität von qualitativ hochwertigem Streaming erheblich reduziert.
Bei der Entwicklung einer Videoplattform gibt es unzählige Dinge zu beachten. Eine der wichtigsten und oft übersehenen Entscheidungen ist jedoch, wie HTTP-basierte Manifestdateien behandelt werden sollen.
Statische Manifestdateien
Wenn Sie in der physischen Welt ein Video kaufen, sehen Sie sich die Verpackung an, nehmen die Schachtel, gehen zur Kasse, bezahlen, gehen nach Hause und legen das Video in Ihren Player ein.
Die meisten Videoplattformen sind recht ähnlich aufgebaut. Grundsätzlich wird eine Gruppe von Metadaten (die Box) mit einem abspielbaren Medienelement (dem Video) verknüpft. Die meisten Videoplattformen beginnen mit dem Konzept einer einzigen URL, die die Metadaten mit einem einzelnen mp4-Video verbindet. Wenn eine Videoplattform komplexer wird, können mehrere URLs mit den Metadaten verbunden sein, die mehrere Bitraten, Auflösungen oder vielleicht andere Medien mit dem Hauptelement wie Vorschauen oder Sonderfunktionen darstellen.
Komplizierter wird es, wenn man versucht, das physische Modell auf eine Online-Streaming-Welt auszudehnen, die HTTP-basierte Streaming-Protokolle wie HLS umfasst. HLS basiert auf vielen Fragmenten einer Videodatei, die durch eine Textdatei namens Manifest miteinander verbunden sind. Bei der Implementierung von HLS besteht die einfachste Methode darin, einfach eine URL hinzuzufügen, die auf das Manifest oder die m3u8-Datei verweist. Dies hat den Vorteil, dass es extrem einfach ist und im Grunde in das bestehende Modell passt.
Der Nachteil ist, dass HLS nicht wirklich mit einem statischen Medienelement vergleichbar ist. Ein MP4 beispielsweise ist einem Videotrack auf einer DVD sehr ähnlich; es handelt sich um ein einzelnes Video mit einer einzigen Auflösung und Bitrate. Das HLS-Manifest besteht höchstwahrscheinlich aus mehreren Bitraten, Auflösungen und Tausenden von fragmentierten Videostücken. HLS kann so viel mehr als ein MP4, warum sollte es also gleich behandelt werden?
HLS-Wiedergabelisten
Eine HLS-Wiedergabeliste enthält einige Metadaten, die grundlegende Elemente des Streams beschreiben, sowie eine geordnete Reihe von Links zu Fragmenten des Videos. Durch das Herunterladen der einzelnen Fragmente oder Segmente des Videos und deren Wiedergabe nacheinander kann sich der Nutzer scheinbar ein einziges, fortlaufendes Video ansehen.
- EXTM3U
- #EXT-X-PLAYLIST-TYPE:VOD
- #EXT-X-TARGETDURATION:10
- #EXTINF:10,
- datei-0001.ts
- #EXTINF:10,
- datei-0002.ts
- #EXTINF:10,
- datei-0003.ts
- #EXTINF:10,
- datei-0003.ts
- #EXT-X-ENDLIST
Oben sehen Sie eine einfache m3u8-Wiedergabeliste. Sie verweist auf vier Videosegmente. Um diese Daten programmatisch zu generieren, werden nur der Dateiname des ersten Elements, die Zieldauer der Segmente (in diesem Fall 10) und die Gesamtzahl der Segmente benötigt.
HLS-Manifeste
Ein HLS-Manifest ist eine ungeordnete Reihe von Links zu Wiedergabelisten. Es gibt zwei Gründe für das Vorhandensein mehrerer Wiedergabelisten: um verschiedene Bitraten bereitzustellen und um Sicherungswiedergabelisten zu erstellen. Hier ist eine typische Wiedergabeliste, bei der jede der .m3u8-Dateien ein relativer Link zu einer anderen HLS-Wiedergabeliste ist.
- #EXTM3U
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
- datei-2040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
- datei-1540k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
- datei-1040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
- datei-640k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
- datei-440k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
- datei-240k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
- file-64k.m3u8
Die Wiedergabelisten weisen unterschiedliche Bitraten und Auflösungen auf, um eine reibungslose Wiedergabe unabhängig von den Netzwerkbedingungen zu gewährleisten. Zur Erstellung eines Manifests werden lediglich die Bitraten der einzelnen Wiedergabelisten und ihre relativen Pfade benötigt.
Ausfüllen der Lücken
Es gibt viele weitere wichtige Informationen, die eine Online-Videoplattform für jedes kodierte Video-Asset erfassen sollte: Video-Codec, Audio-Codec, Container und Gesamtbitrate sind nur einige davon. Die für ein einzelnes Videoelement gespeicherten Daten sollten für den Betrachter aussagekräftig sein (Beschreibung, Bewertung, Besetzung), für die Plattform aussagekräftig (Dauer, Aufrufe, Engagement) und für Anwendungen aussagekräftig (Format, Auflösung, Bitrate). Anhand dieser Daten kann der Zuschauer entscheiden, was er sehen möchte, das System kann entscheiden, wie es programmiert werden soll, und die Anwendung kann entscheiden, wie die Wiedergabe erfolgen soll.
Durch die Erfassung der Daten, die für die programmatische Erstellung einer Wiedergabeliste, eines Manifests und der Codec-Informationen für jede Wiedergabeliste erforderlich sind, wird ein System möglich, bei dem Manifeste und Wiedergabelisten pro Anfrage erstellt werden.
Beispiel - Die erste Wiedergabeliste
Die HLS-Spezifikation legt fest, dass die Wiedergabeliste, die im Manifest an erster Stelle steht, auch als erste für die Wiedergabe ausgewählt wird. Im Beispiel des vorherigen Abschnitts war der erste Eintrag in der Liste auch der Titel mit der höchsten Qualität. Für Benutzer mit einer schnellen, stabilen Internetverbindung ist das in Ordnung, aber für Personen mit langsameren Verbindungen dauert es einige Zeit, bis die Wiedergabe beginnt.
Es wäre besser, festzustellen, ob das Gerät eine gute Internetverbindung zu haben scheint, und dann die Wiedergabeliste entsprechend anzupassen. Glücklicherweise ist das System mit der dynamischen Manifesterstellung genau dafür eingerichtet.
Für die Zwecke dieser Übung nehmen wir an, dass eine Anfrage für ein Manifest mit einer geordneten Anordnung von Bitraten gestellt wird. Zum Beispiel würde die Anfrage [2040,1540,1040,640,440,240,64] eine Wiedergabeliste zurückgeben, die mit der im vorherigen Abschnitt identisch ist. Unter iOS lässt sich feststellen, ob der Benutzer eine WiFi- oder eine Mobilfunkverbindung nutzt. Da zu jeder Wiedergabeliste Daten wie Bitrate, Auflösung und andere Parameter erfasst wurden, kann eine App auf intelligente Weise entscheiden, wie das Manifest angeordnet werden soll.
So kann zum Beispiel festgelegt werden, dass es am besten ist, mit 800-1200kbps zu beginnen, wenn der Benutzer eine WiFi-Verbindung hat, und mit 200-600kbps, wenn der Benutzer eine Mobilfunkverbindung hat. Bei einer WiFi-Verbindung würde die App ein Array anfordern, das etwa so aussieht: [1040,2040,1540,640,440,240,64]. Würde die App nur eine Mobilfunkverbindung erkennen, würde sie [440,2040,1540,1040,640,240,64] anfordern.
Beispiel - Das Legacy-Gerät
Unter Android ist die Videounterstützung eine Art Blackbox. Jahrelang unterstützte die offizielle Android-Dokumentation nur die Verwendung von 640×480 baseline h.264 mp4 Videos, obwohl bestimmte Modelle 1080p verarbeiten konnten. Im Falle von HLS ist die Unterstützung sogar noch fragmentierter und schwer zu verstehen.
Glücklicherweise wird Android von einer Handvoll bedeutender Geräte dominiert. Mit dynamischen Manifesten kann die App nicht nur die beste Wiedergabeliste für den Anfang auswählen, sondern auch Wiedergabelisten ausschließen, die als inkompatibel eingestuft werden.
Da unsere Medienelemente auch Daten wie Auflösung und Codec-Informationen erfassen, kann die Unterstützung gezielt auf bestimmte Geräte ausgerichtet werden. Eine App könnte beschließen, alle Wiedergabedaten zu senden: [2040,1540,1040,640,440,240,64]. Oder ein älteres Gerät, das nur bis zu 720p unterstützt, könnte die höchste Wiedergabeversion entfernen: [1540,1040,640,440,240,64]. Wenn es sich bei der App um ein Connected TV-Gerät handelt, könnte sie darüber hinaus die niedrigsten Qualitätswiedergaben entfernen: [2040,1540,1040,640].
Dynamisch oder statisch
Die Entscheidung für ein statisches Manifestmodell ist völlig in Ordnung. Es geht zwar etwas Flexibilität verloren, aber gegen Einfachheit ist nichts einzuwenden. Viele Anwendungsfälle, insbesondere in der Welt der nutzergenerierten Inhalte, erfordern nicht die Komplexität der dynamischen Generierung, aber die dynamische Manifestgenerierung öffnet viele Türen für diejenigen, die bereit sind, den Sprung zu wagen.
Die Art und Weise, wie Manifeste behandelt werden, hat einen erheblichen Einfluss auf die langfristige Flexibilität einer Videoplattform und sollte mit dem zuständigen Komprimierer besprochen werden.
