Profils de résolution

Le problème résolu

Une master playlist liste plusieurs paliers — par exemple 1080p, 720p et 480p — et un lecteur ordinaire choisit entre eux en mesurant son propre débit. Lorsqu’une tête de réseau consomme cette playlist, une telle adaptation n’a aucun sens : le flux part vers un groupe multicast fixe qui dessert un ensemble fixe de téléviseurs, dans la qualité du premier palier qui convient au moteur.

En pratique, c’est l’ordre du serveur d’origine qui décide, et les serveurs d’origine listent leur meilleur palier en premier. Le résultat habituel : un palier 1080p tiré en continu pour alimenter des écrans en définition standard dans les chambres. Ce n’est pas un petit gaspillage : c’est plusieurs fois la bande passante nécessaire pour une image dont personne ne perçoit le bénéfice, multipliée par chaque chaîne de l’appareil, précisément sur les liaisons montantes contraintes où cela fait le plus mal.

Définir un profil de résolution sur la chaîne retire cette décision au serveur d’origine.

Les profils

Profil	Hauteur cible	Également accepté
4k	2160	`uhd`, `2160p`
fullhd	1080	`1080p`
hd	720	`720p`
sd	576	`576p`, `480p`
mobile	360	`360p`, `low`
(vide)	—	Par défaut. La master playlist est transmise au moteur telle quelle.

Vide est la valeur par défaut, et c’est celle de toutes les chaînes préexistantes. C’est important : l’ajout de cette fonction n’a rien changé aux chaînes déjà configurées. Un profil est une option que vous activez chaîne par chaîne, pas un comportement arrivé du jour au lendemain pour réinterpréter vos playlists.

Comment une variante est sélectionnée

La hauteur la plus proche l’emporte. En cas d’égalité, le débit le plus élevé.

Castmux lit la master playlist, relève la RESOLUTION déclarée de chaque variante et choisit celle dont la hauteur est la plus proche de la cible du profil. Si deux variantes sont à égale distance, celle dont la bande passante annoncée est la plus élevée est retenue.

Ce n’est volontairement pas une règle « correspondance exacte ou échec ». Les serveurs d’origine publient l’échelle qu’ils veulent, et le 576p en particulier est rare en pratique — la plupart publient du 480p à la place. Une chaîne qui refuse de démarrer parce que personne ne sert exactement 576 lignes est strictement pire qu’une chaîne qui diffuse du 480p et vous le signale. Ne pas trouver de correspondance parfaite n’est pas une condition d’erreur ; c’est le cas normal.

Le badge de correspondance

L’en-tête de la carte de la chaîne affiche les deux moitiés de la décision : ce que vous avez demandé, et ce que le serveur d’origine proposait réellement.

Badge	Signification
HD	720p a été demandé et un palier 720p existe. Correspondance exacte.
4K (1080p)	4K a été demandé ; le mieux que propose le serveur d'origine est 1080p, et c'est ce qui est diffusé. Affiché en orange.
SD (480p)	576 lignes ont été demandées ; 480p était le palier le plus proche. Affiché en orange.

L’orange est une information, pas une panne. Il indique que le profil n’a pas pu être satisfait exactement et vous dit ce qui a été utilisé à la place. Une chaîne affichant un badge orange fonctionne correctement. Traiter l’orange comme une alarme produit une avalanche de faux positifs sur tout ensemble réaliste de serveurs d’origine, car la plupart des échelles ne coïncident pas exactement avec un jeu fixe de hauteurs de profil.

Lorsqu’une recherche n’a pas pu aboutir du tout, le badge en indique la raison dans son infobulle. C’est le premier endroit où regarder lorsqu’une chaîne ne diffuse pas le palier attendu.

La substitution se fait à chaque démarrage, jamais de façon persistante

La configuration contient toujours l’URL de master playlist que vous avez saisie. Au démarrage d’une chaîne, Castmux résout la variante et transmet cette URL au moteur pour cette exécution uniquement. Rien n’est réécrit.

Nous insistons sur ce point, car écrire l’URL de la variante dans la configuration ressemble à une optimisation évidente et constitue un piège, pour deux raisons distinctes :

Cela figerait la chaîne sur un palier que le serveur d’origine peut retirer. Les échelles changent. Un serveur d’origine qui supprime son palier 480p le mois suivant laisse une chaîne figée récupérer une URL qui renvoie désormais 404, indéfiniment, sans retour possible vers la master playlist à moins qu’un opérateur ne la ressaisisse.
Ce serait impossible à distinguer d’un choix de l’opérateur. Une fois une URL de variante inscrite dans le fichier de configuration, rien n’indique si un humain l’y a placée délibérément ou si le logiciel l’a substituée. Toute tentative ultérieure de nouvelle résolution risquerait d’écraser une décision délibérée.

Résoudre à chaque démarrage coûte une lecture de playlist en cache et permet à la chaîne de suivre l’échelle du serveur d’origine, quelle que soit son évolution.

En cas d’échec, le comportement configuré s’applique

La résolution de profil se trouve sur le chemin de diffusion : elle se replie donc sur le comportement configuré plutôt que sur un écran noir. Dans tous les cas suivants, l’URL configurée reste inchangée, la raison est journalisée et la chaîne démarre :

Le serveur d’origine est injoignable ou la récupération dépasse le délai.
L’URL s’avère être une media playlist, pas une master — il n’y a pas d’échelle parmi laquelle choisir.
La master ne comporte aucun attribut RESOLUTION, aucune hauteur ne peut donc être comparée.
La playlist est malformée d’une manière qui empêche de lire les variantes.

Dans chaque cas, la chaîne diffuse exactement comme elle l’aurait fait sans profil. La raison n’est pas passée sous silence : elle est journalisée et reprise dans l’infobulle du badge, pour que vous puissiez voir depuis le tableau de bord pourquoi un profil n’est pas appliqué.

Les recherches ne bloquent jamais l’affichage d’une page

Les résultats sont mis en cache — environ dix minutes en cas de succès, une minute après une erreur — et rafraîchis en arrière-plan. L’affichage d’une page ou la réponse à une interrogation d’état lit le cache et planifie un rafraîchissement si l’entrée est périmée ; elle n’attend jamais. Le seul endroit qui attend une recherche en direct est un démarrage complètement à froid du moteur, où il n’y a de toute façon rien à diffuser.

La raison est arithmétique. Vingt-cinq chaînes, chacune avec un délai de récupération de huit secondes, à chaque chargement de page et à chaque interrogation : c’est une interface qui se fige pendant des minutes dès qu’un serveur d’origine est lent — et les serveurs d’origine sont lents précisément quand un opérateur essaie de consulter le tableau de bord. La durée de cache plus courte après une erreur existe pour qu’un serveur d’origine temporairement défaillant soit réessayé rapidement au lieu d’être écarté pendant dix minutes.

Deux garde-fous à connaître

Tous deux existent parce que l’implémentation naïve met à l’antenne une chaîne défectueuse tout en signalant un succès.

Les rendus audio seul sont ignorés

De nombreuses échelles incluent un rendu audio seul. Il ne comporte pas d’attribut RESOLUTION ; sa hauteur vaut donc zéro, et une comparaison naïve de hauteur la plus proche avec la cible de 360 du profil mobile le fait gagner face à tous les vrais paliers vidéo. La chaîne démarre alors, se déclare saine, produit des paquets et met à l’antenne une playlist sans vidéo.

Les variantes sans attribut RESOLUTION sont donc entièrement exclues de la sélection.

Une échelle démultiplexée est refusée

Si la master déclare de l’audio avec #EXT-X-MEDIA:TYPE=AUDIO et que cette déclaration possède son propre URI=, l’audio ne se trouve pas dans les segments vidéo. C’est un rendu séparé que le client est censé récupérer en parallèle de la vidéo et combiner lui-même.

Sélectionner une variante vidéo dans une telle échelle donnerait au moteur une playlist contenant de la vidéo et rien d’autre. Résultat : de la vidéo muette à l’antenne — une chaîne parfaite sur tous les indicateurs, mais sans son.

Castmux refuse donc. Une chaîne dont la master annonce une échelle audio démultiplexée conserve son URL master, la gestion audio propre à la master continue de s’appliquer, et le badge en indique la raison. Il n’existe pas de contournement partiel : un moteur qui reçoit une seule URL ne peut pas réassembler deux rendus, et l’y contraindre exige une seconde entrée et un mappage explicite des flux, ce qui change entièrement la structure de la chaîne.

HLS uniquement

Les profils de résolution s’appliquent aux sources HLS et à rien d’autre. SRT et RTMP livrent un encodage unique et fixe, sans échelle parmi laquelle choisir : il n’y a donc rien à rechercher.

Il ne s’agit pas simplement d’un « réglage ignoré ». Aucune requête HTTP n’est émise pour une chaîne non HLS. La distinction compte, car lorsqu’elle est mal gérée le mode de défaillance est désagréable et discret : une requête HTTP GET envoyée vers une URL srt:// à chaque affichage de page et à chaque interrogation d’état, pour chaque chaîne SRT de l’appareil, ce qui produit de la latence et du bruit dans les journaux qui semblent venir de nulle part.

Exemple détaillé

Un serveur d’origine publie cette échelle :

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5200000,RESOLUTION=1920x1080
v1080.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
v720.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
v480.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=96000,CODECS="mp4a.40.2"
audio.m3u8

La chaîne est réglée sur resolution_profile: sd, dont la cible est 576 lignes.

Le rendu audio seul est écarté en premier : il n’a pas d’attribut RESOLUTION. Sans cette étape, il obtiendrait une hauteur de zéro et l’emporterait d’office avec le profil mobile.
Les distances à 576 sont calculées pour les variantes restantes : 1080p est à 504, 720p à 144, 480p à 96.
480p est le plus proche : v480.m3u8 est donc transmis au moteur pour cette exécution. La configuration contient toujours l’URL master.

L’en-tête de la carte affiche SD (480p) en orange : 576 a été demandé, 480p était ce que le serveur d’origine proposait de plus proche, et la chaîne le diffuse correctement.