Sortie multicast UDP

Adressage

Pour la distribution à l’intérieur d’un bâtiment, utilisez la plage à portée administrative, 239.0.0.0/8. C’est l’équivalent multicast de 10.0.0.0/8 : réservée à l’usage local, jamais routée sur l’Internet public, et attribuable sans consulter de registre. Attribuez un groupe par chaîne et tenez un registre écrit de l’attribution, car une collision entre deux chaînes est la même panne qu’un émetteur en double et se manifeste de la même façon.

N’utilisez pas 224.0.0.0/24. Ce bloc est réservé aux protocoles de contrôle de liaison locale — adjacences de routage, IGMP lui-même et découverte de voisins sur certains équipements. De la vidéo envoyée dans cette plage est remise à chaque équipement du segment et traitée par du code de plan de contrôle qui ne s’attendait pas à 38 Mbps. Castmux avertit lorsqu’une destination tombe dans cette plage plutôt que de la refuser d’emblée, en supposant que vous testez peut-être quelque chose délibérément, mais cet avertissement doit être traité comme une erreur en production.

Les destinations unicast sont acceptées et constituent le bon choix pour une liaison point à point : alimenter une autre tête de réseau via un chemin routé, transmettre une chaîne à un enregistreur ou à un système d’archivage réglementaire, ou tester depuis un ordinateur portable qui n’est pas sur le VLAN des téléviseurs. Une chaîne unicast n’a aucun abonnement IGMP derrière elle ; la diffusion à la demande ne peut donc pas y détecter de spectateurs, et la chaîne doit rester en mode toujours actif.

Plage	Usage
239.0.0.0/8	recommandé Portée administrative. Le bon choix pour la distribution interne à un bâtiment.
224.0.0.0/24	à éviter Réservé aux protocoles de contrôle de liaison locale. Castmux avertit si une chaîne y est dirigée.
Adresse unicast	point à point Accepté. Convient pour une autre tête de réseau ou un enregistreur. Pas de détection des spectateurs : gardez la chaîne en mode toujours actif.

Taille des datagrammes

La charge utile de chaque datagramme fait 1316 octets, soit exactement sept paquets transport de 188 octets. Ce chiffre n’est pas arbitraire, et il vaut la peine de comprendre pourquoi c’est le seul choix raisonnable.

Un paquet transport fait 188 octets et ne peut pas être réparti sur plusieurs datagrammes sans qu’un récepteur doive le réassembler. Sept paquets font 1316 octets, ce qui, avec les 8 octets d’en-tête UDP et les 20 octets d’en-tête IPv4, donne 1344 — largement dans une MTU Ethernet de 1500 octets, avec de la place pour une étiquette VLAN. Huit paquets représenteraient 1504 octets de charge utile et seraient fragmentés.

Envoyer moins de sept paquets par datagramme est légal mais doublement coûteux. Chaque datagramme porte les mêmes 28 octets d’en-tête quel que soit son remplissage ; un flux de datagrammes à moitié pleins dépense donc environ deux fois plus en en-têtes et deux fois plus en traitement par paquet sur l’équipement récepteur, pour la même vidéo. Surtout, certains décodeurs gèrent mal les datagrammes irréguliers : un décodeur qui suppose sept paquets par datagramme, ou qui met en tampon par nombre de datagrammes plutôt que par nombre d’octets, produit des artefacts intermittents qui n’apparaissent que sur certains modèles et sont presque impossibles à reproduire sur un lecteur PC.

Les deux moteurs diffèrent sur ce point. Le moteur pass-through émet des datagrammes complets de 1316 octets 100% du temps. Le moteur de remultiplexage les remplit environ 85% du temps, en envoyant un datagramme court chaque fois que son multiplexeur interne atteint une limite de trame. C’est pourquoi Castmux force explicitement la taille des paquets sur les chaînes HLS plutôt que d’accepter la valeur par défaut du moteur — voir Moteurs de diffusion pour la comparaison complète.

TTL

La valeur par défaut est 16. Le TTL d’un datagramme multicast est décrémenté par chaque routeur qui le transmet ; il borne donc la distance que le trafic peut parcourir.

TTL 1

Le datagramme ne quitte jamais le segment local. Dans un bâtiment unique où l’appareil et les téléviseurs sont sur le même VLAN, c’est généralement la bonne valeur, et c’est un filet de sécurité utile : une erreur de configuration ne peut pas faire fuir de la vidéo sur le reste du réseau.

TTL 16 (défaut)

Permet la transmission à travers quelques sauts de routeur. Choisi par défaut parce qu’il fonctionne aussi bien dans le cas d’un réseau plat que dans celui d’un réseau routé, et parce qu’un flux qui n’arrive pas est une panne plus difficile à diagnostiquer qu’un flux qui va un peu plus loin que nécessaire.

Valeurs plus élevées

Nécessaires uniquement lorsqu’un routeur transmet délibérément du multicast entre VLAN, ce qui suppose que PIM ou un équivalent ait été configuré par le gestionnaire du réseau. Augmenter le TTL ne permet pas à lui seul au multicast de traverser un routeur.

Interface de sortie

Une chaîne peut recevoir une adresse source, à laquelle le moteur liera son socket. C’est utile pour rendre l’adresse source du trafic prévisible, pour les règles de pare-feu et pour identifier de quel appareil provient un flux sur un segment qui en compte plusieurs.

C’est le malentendu le plus coûteux des déploiements multicast. Lier un socket à 192.168.10.5 ne signifie pas que les paquets sortent par la carte réseau qui porte 192.168.10.5. Le noyau consulte toujours la table de routage pour décider de l’interface de sortie, et pour le multicast cette décision dépend de la route de 224.0.0.0/4. Si cette route pointe vers la mauvaise carte réseau, le trafic sort par la mauvaise carte, quelle que soit l’adresse source liée.

Pire, rien dans le processus ne peut le détecter. sendto() vers une destination routée vers un endroit inutile réussit quand même ; chaque compteur de l’interface utilisateur paraît donc sain alors qu’aucun téléviseur ne reçoit rien. Castmux vérifie la table de routage depuis l’extérieur du chemin de diffusion et signale la situation, mais il ne peut pas la corriger.

Voir Dépannage → routage multicast pour lire la table de routage et la corriger, et Installation pour que la correction survive à un redémarrage.

Deux autres points découlent du même fait. Corrigez la plage, 224.0.0.0/4, et non des groupes individuels : une route d’hôte par groupe répare les chaînes que vous avez aujourd’hui et laisse chaque chaîne ajoutée plus tard silencieusement non routable. Et les modifications de route faites avec ip route ne survivent pas à un redémarrage : elles doivent être installées sous forme d’unité exécutée au démarrage.

Débit constant

Certains équipements en aval, et certains décodeurs anciens, se comportent mieux avec un transport stream à débit constant qu’avec un flux qui suit la source. Bourrer en CBR signifie insérer des paquets nuls pour que le débit sur le réseau soit plat, quoi que fasse la vidéo.

Le moteur de remultiplexage sait le faire, car il construit son propre transport stream et peut décider de la part de bourrage. Le moteur pass-through ne le peut pas : il transmet les paquets de la source sans les modifier et n’a aucun mécanisme pour insérer des paquets nuls — c’est la même propriété qui lui fait préserver les PID d’origine et signaler fidèlement les pertes côté source. On ne peut pas avoir les deux.

Sur le chemin DVB-C, la question ne se pose pas. Une porteuse DVB-C est à débit constant par construction et le multiplexeur bourre pour la remplir ; une chaîne destinée à un multiplex n’a donc pas besoin de CBR sur sa sortie UDP.

Un débit constant par chaîne sur la sortie UDP simple, configurable indépendamment du moteur : prévu.

Nommage des services

Un téléviseur ou un décodeur qui balaie un groupe multicast affiche le nom que le transport stream déclare dans sa Service Description Table. Avec le moteur pass-through, Castmux écrit le nom de la chaîne dans la SDT : le nom saisi dans l’interface web est donc celui qui apparaît à l’écran.

Le moteur de remultiplexage n’écrit pas de SDT. Les chaînes sur ce moteur apparaîtront sous le nom qu’invente l’équipement récepteur, généralement l’adresse du groupe ou un intitulé générique. Si le nom à l’écran compte et que la source le permet, utilisez le moteur pass-through.

Émetteurs en double

Deux processus qui envoient vers le même groupe et le même port produisent un flux qui est l’entrelacement des deux. Les compteurs de continuité se contredisent, les PID entrent en collision, et le résultat à l’écran est une pixelisation et des coupures audio intermittentes.

Cette panne est particulièrement coûteuse à diagnostiquer, car les deux émetteurs paraissent parfaitement sains. Chacun produit un flux valide au bon débit ; les métriques de chacun sont au vert. Le débit mesuré sur le réseau est à peu près le double de ce qu’il devrait être, c’est le seul indice, et il est facile de l’attribuer à autre chose.

Castmux recherche donc d’autres émetteurs sur l’adresse et le port de destination avant de démarrer une chaîne, et signale la situation plutôt que de démarrer par-dessus. La cause classique n’est pas deux chaînes Castmux — l’interface utilisateur l’empêche — mais un ancien service resté actif à côté d’un nouveau déploiement : un ancien logiciel de diffusion désactivé mais pas arrêté, ou une unité systemd qu’une entrée cron redémarre chaque nuit.

Auditeurs factices

Lorsque rien sur le réseau n’a rejoint un groupe multicast, aucun récepteur n’exerce de contre-pression et, avec certaines combinaisons de noyau et de pilote, le tampon d’envoi du socket peut déborder au lieu de simplement écarter les données. Le symptôme : des erreurs d’envoi intermittentes sur une chaîne que personne ne regarde.

Castmux peut maintenir un consommateur local pour chaque groupe, qui le rejoint, lit le trafic et l’écarte. Cela maintient un abonnement au groupe et un comportement de tampon cohérents, qu’il y ait ou non de vrais spectateurs. C’est activé par défaut et ne coûte presque rien ; aucune raison de le désactiver, sauf si vous mesurez quelque chose et voulez que le groupe soit réellement sans abonné.

Notez l’interaction avec la diffusion à la demande : l’auditeur factice n’est volontairement pas compté comme spectateur. Sinon, aucune chaîne à la demande ne s’arrêterait jamais.

Vérifier la sortie

Trois vérifications, par ordre croissant de ce qu’elles prouvent.

D’abord, lisez le groupe depuis une machine du même segment :

# ffplay, on a host in the same VLAN as the appliance
ffplay udp://@239.10.0.1:1234

# The @ is required. Without it ffplay listens on a unicast socket
# and never joins the group, so you will see nothing and blame the encoder.

Dans VLC, utilisez Média → Ouvrir un flux réseau (Media → Open Network Stream) et saisissez la même URL :

udp://@239.10.0.1:1234

Ensuite, utilisez l’aperçu dans le navigateur de l’interface web. Il confirme que la source arrive et est correctement préparée, mais il ne prouve rien sur le chemin multicast, car l’aperçu ne l’emprunte pas.

Enfin, et c’est le plus utile, lisez la tuile de débit UDP sur la fiche de la chaîne. Ce chiffre est mesuré par capture de paquets sur l’interface, directement sur le réseau, et non rapporté par le moteur. C’est donc le seul signal qui ne dépend pas de la sincérité du moteur sur son propre état, et c’est la même mesure pour les deux moteurs. Une chaîne dont le moteur prétend tourner mais dont le débit UDP est nul n’est pas à l’antenne.