--- title: Lecteurs et réserve OTT/DVR url: https://doc2.pstreamer.tv/fr/manual/extras/ott_players.html lang: fr product: Perfect Streamer version: 2.0.2.423 --- # 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](beta.md#extras-beta)). 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](../webui/reserves.md#webui-fleet-reserves-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](../webui/reserves.md#webui-fleet-reserves-ott-failover)). - **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](../webui/reserves.md#webui-fleet-reserves-ott-redirects)). ## 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](../webui/reserves.md#webui-fleet-reserves-ott-failover)). ## 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](../webui/administration.md#webui-http-server)). - **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](../streamer/ott_dvr.md#streamer-ott-modes)) ; 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](../streamer/transcoder.md#streamer-transcoder-encoder)). 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](ott_caching.md#extras-ott-cdn-reserve).