Lecteurs et réserve OTT/DVR

Important

Version bêta 2.1. Ce qui est décrit ici n’existe que dans la version bêta 2.1 : elle s’installe depuis le dépôt bêta et uniquement avec une licence ; la version stable 2.0.2 et la version de démonstration ne l’ont pas. La version bêta est fournie sans garantie, et l’assistance est assurée dans la mesure du possible (Programme de test bêta).

La réserve OTT/DVR protège les spectateurs de la diffusion OTT de deux façons, et c’est le lecteur qui détermine lesquelles lui sont accessibles (Groupes OTT) :

• Bascule pendant la lecture. La playlist maître HLS désigne jusqu’à deux autres nœuds du groupe OTT comme variantes de secours. Un lecteur capable de basculer sur les variantes de secours passe de lui-même sur un autre nœud lorsque son nœud cesse de servir la fenêtre live, et le spectateur ne quitte pas le lecteur (Bascule des spectateurs vers un autre nœud).

• Redirection à l’ouverture. Le nœud répond par une redirection 302 vers un autre nœud du groupe si le spectateur ouvre un flux qui ne fonctionne pas ici, ou demande l’archive d’une période hors de la plage d’archive de ce nœud ; les trous à l’intérieur de la plage, le nœud les sert lui-même. Si la période n’est enregistrée sur aucun nœud, la réponse est 404 (reserve: no recording for this period) (Redirection des spectateurs).

Ce que reçoit le lecteur

Le nœud décide d’après l’en-tête User-Agent du lecteur et le paramètre rsv de l’adresse de la playlist maître s’il lui donne des variantes de secours. Le tableau montre ce que le nœud sert à chaque lecteur. Les réponses du nœud ont été vérifiées pour chaque règle User-Agent. La bascule elle-même vers le nœud de secours n’a été testée que dans Chrome sous Windows (hls.js 1.5, page en HTTP) ; sur les autres lecteurs et appareils, elle n’a pas été testée dans cette version bêta, pas plus que le passage par 302.

Lecteur	Variantes de secours (bascule pendant la lecture)	Redirection 302 (nouveau spectateur, archive)
Safari, iOS, tvOS, Apple TV (AVPlayer)	Oui ; bascule non testée	Oui ; non testé
ExoPlayer et Media3 (Android, Android TV)	Oui ; bascule non testée	Oui ; non testé
Lecteurs de navigateur : hls.js, Shaka Player, Video.js	Oui, si le navigateur envoie les en-têtes Sec-Fetch-Mode ou Sec-Fetch-Dest (navigateurs modernes en HTTPS). Depuis la version 2.1.0.469, également sans eux, par exemple en HTTP : si la requête porte un en-tête Origin ou Referer d’une page du nœud lui-même (voir ci-dessous). Bascule testée dans Chrome sous Windows (hls.js 1.5, en HTTP, sans rsv=1) ; dans les autres navigateurs, non testée	Oui ; non testé
Applications Smart TV à lecteur de navigateur (Tizen, webOS), Chromecast	Si le moteur de navigateur de l’appareil envoie les en-têtes Sec-Fetch et, depuis la version 2.1.0.469, également sans eux, selon la même règle que les navigateurs en HTTP. Non testé	Oui ; non testé
Lecteurs intégrés des Smart TV (AVPlay sous Tizen, lecteur multimédia de webOS)	Non : pas de variantes de secours, sauf avec rsv=1. Non testé	Oui ; non testé
VLC et LibVLC, lecteurs basés sur ffmpeg, mpv, Kodi, GStreamer, ijkplayer, exteplayer	Non, même avec rsv=1 : fonctionnent comme avant	Oui. Pour VLC, l’archive depuis un autre nœud a été testée ; les autres : non testés
Boîtiers décodeurs et lecteurs sans User-Agent	Non, même avec rsv=1 : fonctionnent comme avant	Oui ; non testé
Application propre de l’opérateur	Avec rsv=1 dans l’adresse de la playlist maître ; rsv=0 désactive	Oui

Lecteur de navigateur sans en-têtes Sec-Fetch (depuis la version 2.1.0.469). Les navigateurs n’envoient les en-têtes Sec-Fetch qu’aux adresses HTTPS ; c’est pourquoi, auparavant, un lecteur de navigateur sur une page HTTP ne recevait pas de variantes de secours. Désormais, une requête sans ces en-têtes est considérée comme venant d’un navigateur si son User-Agent contient Mozilla/, s’il ne s’agit ni d’une requête de plage (Range) ni d’un chargement de page, et si elle porte un en-tête Origin ou — pour la page de lecteur servie par le nœud lui-même — Referer avec l’adresse et le port de ce nœud. Testé dans Chrome sous Windows avec hls.js 1.5 : la playlist maître a désigné un secours sans rsv=1, et lors d’une pause de l’entrée du nœud, le lecteur est passé sur un autre nœud. Les autres navigateurs en HTTP n’ont pas été testés.

Le nœud sert la redirection 302 à n’importe quel lecteur, pour HLS, LL-HLS et DASH : c’est une redirection HTTP ordinaire vers l’adresse complète d’un autre nœud, avant le début de la lecture. Les lecteurs suivent généralement les redirections d’eux-mêmes.

Les lecteurs de la liste « Non, même avec rsv=1 » ouvrent toutes les variantes à la suite au démarrage ou lors d’une réponse 404 sur la playlist ; c’est pourquoi le nœud ne leur donne jamais de lignes de secours. Un lecteur absent du tableau et qui ne ressemble pas à un lecteur de navigateur ne reçoit pas non plus de variantes de secours ; ajoutez rsv=1 à l’adresse s’il sait s’en servir, et testez la bascule sur votre lecteur. Le nombre de playlists maîtres que le nœud a servies sans secours à cause du lecteur est indiqué par la ligne « Playlists maîtres sans secours » du bloc « Clé de visionnage OTT » (Bascule des spectateurs vers un autre nœud).

Limites et conseils

• Flux HLS simples uniquement. Dans cette version bêta, seuls reçoivent des variantes de secours les flux simples dont les membres sur les différents nœuds prennent la même source. Les ensembles adaptatifs et le LL-HLS ne savent pas encore basculer pendant la lecture, mais la redirection à l’ouverture fonctionne pour eux.

• DASH. Pour DASH, cette version bêta ne propose que la redirection à l’ouverture.

• Délais d’attente de hls.js. Définissez des délais d’attente courts pour le chargement de la playlist et du segment — environ une durée cible de segment, soit 2 à 3 secondes : le lecteur quitte alors rapidement un nœud figé.

• Schéma de l’adresse. Le nœud de secours doit être joignable par le spectateur avec le même schéma : une page en HTTPS a besoin d’une adresse HTTPS du nœud de secours. Renseignez le « Nom d’hôte » du serveur HTTP de chaque nœud, celui pour lequel son certificat est émis (Serveur HTTP de diffusion).

• Son dans le navigateur. Depuis la version 2.1.0.469, la playlist maître HLS indique le véritable codec audio du flux (Modes de diffusion) ; auparavant, toute chaîne était déclarée en AAC, et une chaîne avec un son MP2 ne se lisait pas dans le navigateur.

  • Tous les lecteurs de navigateur prennent en charge l’AAC.

  • MP2 : hls.js dans Chromium le lit désormais (seul le son a été testé) ; Google Chrome, Edge, Firefox et Safari : non testés. MP3 : non testé.

  • AC-3 et E-AC-3 : hls.js et Shaka dans Chrome et Firefox de bureau n’acceptent pas une telle variante. Safari et Edge sous Windows : non testés.

  • En LL-HLS et en DASH, les segments ne portent que du son AAC ou AC-3 : le son MP2, MP3 ou E-AC-3 en est totalement absent.

  Le plus fiable pour les spectateurs dans un navigateur : une piste AAC dans la chaîne ou un transcodeur.

• VLC et les autres lecteurs sans variantes de secours ne transfèrent pas une lecture en cours vers un autre nœud. Quand l’entrée du nœud s’arrête, VLC lit son tampon jusqu’au bout, s’arrête et ne reçoit 302 vers un autre nœud qu’à une nouvelle ouverture ; lors du test, cela a pris environ 40 à 50 secondes. La redirection vers l’archive d’un autre nœud a été testée dans VLC.

• Vidéo entrelacée dans le navigateur. Les lecteurs de navigateur (hls.js et ses semblables basés sur MSE) décodent de façon peu fiable le H.264 entrelacé avec codage par trames (PAFF, MBAFF) — c’est généralement ainsi que sont diffusées la SD 576i et la HD 1080i de télédiffusion. La lecture s’arrête au bout de quelques secondes avec une erreur de décodage (PIPELINE_ERROR_DECODE) ; ce fut le cas, par exemple, dans Chrome sous Windows avec une chaîne 576i H.264 Main, alors que VLC affichait normalement la même chaîne. Pour les spectateurs dans un navigateur, donnez à la chaîne une copie progressive via un transcodeur avec le paramètre « Deinterlace » (Paramètres de l’encodeur). Les boîtiers décodeurs, les Smart TV et VLC lisent la vidéo entrelacée normalement.

  Une chaîne entrelacée se repère dans les statistiques du flux : dans le champ « Format », la fréquence est suivie de i, par exemple 1920x1080@50i (pour une vidéo entrelacée, c’est la fréquence de trames, le double de la fréquence d’images), et de p pour une vidéo progressive. Lorsque l”« Analyse approfondie » est activée, la ligne « Type de balayage » du bloc « Passeport codec vidéo » indique la même chose : 2 — entrelacé, 1 — progressif. Pour le H.264, l’indicateur i est posé dès que le flux autorise le codage par trames, même si l’encodeur ne code en réalité que des images.

• Erreurs de décodage dans votre propre lecteur. En cas d’erreur de décodage, hls.js 1.5 passe à l’adresse de secours comme lors d’une défaillance du nœud, et l’élément de lecture reste ensuite défectueux. Traitez les erreurs média en appelant hls.recoverMediaError() et, si cela ne suffit pas, hls.swapAudioCodec() puis à nouveau hls.recoverMediaError(), avec une petite limite du nombre de tentatives. Ne comptez pas une telle bascule comme une défaillance du nœud dans vos statistiques.

• Les sous-titres restent sur le nœud d’origine après la bascule.

• Cache et CDN devant les nœuds : 8.1. Réserve OTT/DVR et CDN.