Player und OTT/DVR-Reserve

Wichtig

Betaversion 2.1. Das hier Beschriebene gibt es nur in der Betaversion 2.1: Sie wird aus dem Beta-Repository und nur mit einer Lizenz installiert; die stabile Version 2.0.2 und die Demoversion enthalten es nicht. Die Betaversion wird ohne Gewähr ausgeliefert, Support gibt es nach Möglichkeit (Betatestprogramm).

Die OTT/DVR-Reserve schützt die Zuschauer der OTT-Auslieferung auf zwei Arten, und vom Player hängt ab, welche davon ihm zur Verfügung stehen (OTT-Gruppen):

• Wechsel während der Wiedergabe. Die Master-Playlist von HLS nennt bis zu zwei andere Knoten der OTT-Gruppe als Reservevarianten. Ein Player, der auf Reservevarianten umschalten kann, wechselt selbst auf einen anderen Knoten, wenn sein Knoten kein Live-Fenster mehr ausliefert, und der Zuschauer verlässt den Player nicht (Wechsel der Zuschauer auf einen anderen Knoten).

• Umleitung beim Öffnen. Der Knoten antwortet mit einer Umleitung 302 auf einen anderen Knoten der Gruppe, wenn der Zuschauer einen Stream öffnet, der hier nicht läuft, oder das Archiv für einen Zeitraum außerhalb des Archivbereichs dieses Knotens anfordert; Lücken innerhalb des Bereichs bedient der Knoten selbst. Ist der Zeitraum auf keinem Knoten aufgezeichnet, lautet die Antwort 404 (reserve: no recording for this period) (Umleitung der Zuschauer).

Was der Player erhält

Der Knoten entscheidet anhand des User-Agent-Headers des Players und des Parameters rsv in der Adresse der Master-Playlist, ob er ihm Reservevarianten gibt. Die Tabelle zeigt, was der Knoten jedem Player ausliefert. Die Antworten des Knotens sind für jede User-Agent-Regel geprüft. Das Umschalten auf den Reserveknoten selbst ist nur in Chrome unter Windows geprüft (hls.js 1.5, Seite über HTTP); bei den übrigen Playern und Geräten ist es, wie auch der Wechsel über 302, in dieser Betaversion nicht geprüft.

Player	Reservevarianten (Wechsel während der Wiedergabe)	Umleitung 302 (neuer Zuschauer, Archiv)
Safari, iOS, tvOS, Apple TV (AVPlayer)	Ja; Umschalten nicht geprüft	Ja; nicht geprüft
ExoPlayer und Media3 (Android, Android TV)	Ja; Umschalten nicht geprüft	Ja; nicht geprüft
Browser-Player: hls.js, Shaka Player, Video.js	Ja, wenn der Browser die Header Sec-Fetch-Mode oder Sec-Fetch-Dest sendet (moderne Browser über HTTPS). Seit Version 2.1.0.469 auch ohne sie, zum Beispiel über HTTP: wenn die Anfrage den Header Origin oder Referer einer Seite des Knotens selbst trägt (siehe unten). Umschalten geprüft in Chrome unter Windows (hls.js 1.5, über HTTP, ohne rsv=1); in anderen Browsern nicht geprüft	Ja; nicht geprüft
Smart-TV-Apps mit Browser-Player (Tizen, webOS), Chromecast	Wenn die Browser-Engine des Geräts die Sec-Fetch-Header sendet, und seit Version 2.1.0.469 auch ohne sie, nach derselben Regel wie Browser über HTTP. Nicht geprüft	Ja; nicht geprüft
Integrierte Smart-TV-Player (AVPlay in Tizen, Mediaplayer von webOS)	Nein: Sie erhalten keine Reservevarianten, außer mit rsv=1. Nicht geprüft	Ja; nicht geprüft
VLC und LibVLC, Player auf Basis von ffmpeg, mpv, Kodi, GStreamer, ijkplayer, exteplayer	Nein, auch nicht mit rsv=1: Sie arbeiten wie bisher	Ja. Bei VLC ist das Archiv von einem anderen Knoten geprüft; die übrigen sind nicht geprüft
Set-Top-Boxen und Player ohne User-Agent	Nein, auch nicht mit rsv=1: Sie arbeiten wie bisher	Ja; nicht geprüft
Eigene App des Betreibers	Mit rsv=1 in der Adresse der Master-Playlist; rsv=0 schaltet ab	Ja

Browser-Player ohne Sec-Fetch-Header (seit Version 2.1.0.469). Browser senden die Sec-Fetch-Header nur an HTTPS-Adressen, deshalb erhielt ein Browser-Player auf einer HTTP-Seite bisher keine Reservevarianten. Jetzt gilt eine Anfrage ohne diese Header als Browser-Anfrage, wenn ihr User-Agent Mozilla/ enthält, sie keine Bereichsanfrage (Range) und kein Seitenabruf ist und sie den Header Origin trägt oder — bei einer Player-Seite, die der Knoten selbst ausliefert — Referer mit Adresse und Port dieses Knotens. Geprüft in Chrome unter Windows mit hls.js 1.5: Die Master-Playlist nannte die Reserve ohne rsv=1, und bei einer Pause des Eingangs des Knotens wechselte der Player auf einen anderen Knoten. Andere Browser über HTTP sind nicht geprüft.

Die Umleitung 302 liefert der Knoten jedem Player aus, für HLS, LL-HLS und DASH: Das ist eine gewöhnliche HTTP-Umleitung auf die vollständige Adresse eines anderen Knotens vor Beginn der Wiedergabe. Player folgen Umleitungen in der Regel selbst.

Player aus der Liste „Nein, auch nicht mit rsv=1“ öffnen beim Start oder bei einer 404-Antwort auf die Playlist alle Varianten nacheinander, deshalb gibt der Knoten ihnen nie Reservezeilen. Ein Player, der nicht in der Tabelle steht und nicht wie ein Browser-Player aussieht, erhält ebenfalls keine Reservevarianten; fügen Sie rsv=1 zur Adresse hinzu, wenn er sie nutzen kann, und prüfen Sie den Wechsel mit Ihrem Player. Wie viele Master-Playlists der Knoten wegen des Players ohne Reserve ausgeliefert hat, zeigt die Zeile „Master-Playlists ohne Absicherung“ des Blocks „OTT-Ansichtsschlüssel“ (Wechsel der Zuschauer auf einen anderen Knoten).

Einschränkungen und Hinweise

• Nur einzelne HLS-Streams. In dieser Betaversion erhalten nur einzelne Streams Reservevarianten, deren Mitglieder auf verschiedenen Knoten dieselbe Quelle beziehen. Adaptive Bundles und LL-HLS können während der Wiedergabe noch nicht wechseln, die Umleitung beim Öffnen funktioniert bei ihnen aber.

• DASH. Für DASH gibt es in dieser Betaversion nur die Umleitung beim Öffnen.

• Timeouts von hls.js. Legen Sie kurze Ladetimeouts für Playlist und Segment fest — etwa eine Zielsegmentdauer, 2–3 Sekunden: Dann verlässt der Player einen hängenden Knoten schnell.

• Adressschema. Der Reserveknoten muss für den Zuschauer über dasselbe Schema erreichbar sein: Eine Seite über HTTPS braucht eine HTTPS-Adresse des Reserveknotens. Legen Sie für den HTTP-Server jedes Knotens den „Hostname“ fest, auf den sein Zertifikat ausgestellt ist (Streaming-HTTP-Server).

• Ton im Browser. Seit Version 2.1.0.469 nennt die HLS-Master-Playlist den tatsächlichen Audiocodec des Streams (Auslieferungsmodi); bisher wurde jeder Kanal als AAC angekündigt, und ein Kanal mit MP2-Ton spielte im Browser nicht.

  • AAC unterstützen alle Browser-Player.

  • MP2: hls.js in Chromium spielt es jetzt ab (nur der Ton geprüft); Google Chrome, Edge, Firefox und Safari — nicht geprüft. MP3 — nicht geprüft.

  • AC-3 und E-AC-3: hls.js und Shaka in Desktop-Chrome und -Firefox nehmen eine solche Variante nicht an. Safari und Edge unter Windows — nicht geprüft.

  • In LL-HLS und DASH tragen die Segmente nur Ton in AAC oder AC-3: Ton in MP2, MP3 oder E-AC-3 gibt es dort überhaupt nicht.

  Am zuverlässigsten für Browser-Zuschauer ist eine AAC-Tonspur im Kanal oder ein Transcoder.

• VLC und andere Player ohne Reservevarianten übertragen eine laufende Wiedergabe nicht auf einen anderen Knoten. Hält der Eingang des Knotens an, spielt VLC seinen Puffer zu Ende, hält an und erhält erst beim erneuten Öffnen eine 302 auf einen anderen Knoten; im Test dauerte das etwa 40–50 Sekunden. Die Umleitung zum Archiv eines anderen Knotens ist in VLC geprüft.

• Zeilensprungvideo im Browser. Browser-Player (hls.js und ähnliche auf MSE-Basis) dekodieren Zeilensprung-H.264 mit Halbbildcodierung (PAFF, MBAFF) unzuverlässig — so kommen in der Regel die Rundfunkformate SD 576i und HD 1080i. Die Wiedergabe bricht nach einigen Sekunden mit einem Dekodierfehler (PIPELINE_ERROR_DECODE) ab; so war es zum Beispiel in Chrome unter Windows mit einem Kanal 576i H.264 Main, während VLC denselben Kanal normal zeigte. Geben Sie dem Kanal für Zuschauer im Browser eine progressive Kopie über einen Transcoder mit der Einstellung „Deinterlace“ (Einstellungen des Encoders). Set-Top-Boxen, Smart-TVs und VLC geben Zeilensprungvideo wie gewohnt wieder.

  Einen Zeilensprungkanal erkennt man in der Stream-Statistik: Im Feld „Format“ steht nach der Frequenz ein i, zum Beispiel 1920x1080@50i (bei Zeilensprungvideo ist das die Halbbildfrequenz, doppelt so hoch wie die Bildfrequenz), bei progressivem Video ein p. Bei eingeschalteter „Tiefenanalyse“ zeigt dasselbe die Zeile „Scan-Typ“ des Blocks „Video-Codec-Steckbrief“: 2 — Zeilensprung, 1 — progressiv. Bei H.264 wird das Merkmal i gesetzt, wenn der Stream Halbbildcodierung zulässt, auch wenn der Encoder tatsächlich nur Vollbilder codiert.

• Dekodierfehler im eigenen Player. hls.js 1.5 wechselt bei einem Dekodierfehler auf die Reserveadresse wie bei einem Knotenausfall, das Wiedergabeelement bleibt danach aber defekt. Behandeln Sie Medienfehler mit dem Aufruf hls.recoverMediaError() und, wenn das nicht hilft, mit hls.swapAudioCodec() und erneut hls.recoverMediaError(), mit einer kleinen Begrenzung der Zahl der Versuche. Zählen Sie einen solchen Wechsel in Ihrer Statistik nicht als Knotenausfall.

• Untertitel bleiben nach dem Wechsel auf dem ursprünglichen Knoten.

• Cache und CDN vor den Knoten: 8.1. OTT/DVR-Reserve und CDN.