Prérequis

Appareil de référence

Castmux est développé et mesuré sur une machine volontairement modeste, parce que c’est ce qui tient dans un local technique et fonctionne sans surveillance pendant des années :

Composant	Spécification de référence
CPU	4 cœurs, arm64 ou x86-64
Mémoire	6 Go
Refroidissement	Sans ventilateur
Stockage	Au choix ; en fonctionnement normal, il n'y a aucune activité disque hormis la journalisation
Réseau	Une interface au minimum, deux de préférence

Rien n’est transcodé : il n’y a donc aucun besoin de GPU, et aucun gain à en avoir un. L’absence d’écritures disque soutenues mérite d’être notée par quiconque spécifie le matériel : un appareil fonctionnant sur de la mémoire flash industrielle ne s’use pas sous cette charge.

Coût par chaîne

Les deux moteurs ont des coûts sensiblement différents, et le choix de l’un ou de l’autre modifie la capacité du boîtier d’un facteur d’environ 1,5. Mesures par chaîne :

Mesure	Moteur de remultiplexage	Moteur pass-through
Démarrage à froid (jonction → premier paquet)	~4.4 s	~1.9 s
Datagrammes complets de 1316 octets	85%	100%
CPU par chaîne	~5 % d'un cœur	~15 % d'un cœur
RAM par chaîne	~72 MB	~23 MB
Chaînes sur un boîtier de 2 Go	~16	25+

Les coûts vont en sens inverse, et c’est la raison d’être des deux moteurs. Le moteur pass-through est économe en mémoire et gourmand en CPU ; le moteur de remultiplexage, l’inverse. Sur l’appareil de référence, cela signifie que le moteur de remultiplexage manque de mémoire en premier et que le moteur pass-through manque de CPU en premier — quatre cœurs à 15 % chacun, cela fait un peu plus de 26 chaînes, d’où le chiffre « 25+ ».

Le moteur de remultiplexage ne peut pas être abandonné, bien qu’il coûte plus cher par chaîne. Le moteur pass-through ne sait pas compléter par des paquets nuls pour obtenir un débit constant, et son entrée HLS ne lit que des segments MPEG-TS, pas du fMP4/CMAF — un serveur d’origine CMAF moderne, ou un équipement en aval qui exige du CBR, nécessite donc le moteur de remultiplexage. Voir Moteurs de diffusion pour savoir lequel choisir.

Planification de la capacité

La mémoire est une falaise, pas une pente. C’est le point le plus important de cette page. L’épuisement du CPU se dégrade progressivement — les flux saccadent, vous le remarquez, vous réduisez la charge. L’épuisement de la mémoire ne se dégrade pas du tout : le noyau choisit un processus et le tue, et celui qu’il choisit est généralement une chaîne saine qui n’avait rien à voir avec le problème. Il n’existe aucune zone d’alerte entre « tout va bien » et « une chaîne vient de disparaître ».

Le calcul

Trois étapes :

Mémoire utilisable = mémoire totale − ~300 MB. Cette réserve couvre le système d’exploitation, le runtime de conteneurs et le processus Castmux lui-même, dont aucun n’est un coût par chaîne.
Nombre brut de chaînes = mémoire utilisable ÷ RSS par chaîne pour le moteur choisi.
Gardez 15 % de marge. La RSS par chaîne varie avec le débit de la source et bouge lors des hoquets et reconnexions du serveur d’origine ; ce sont ces 15 % qui absorbent ces variations.

Exemple pour un appareil de 2 Go avec le moteur de remultiplexage :

# usable memory
2048 MB - 300 MB = 1748 MB

# raw count at ~72 MB per channel
1748 / 72 = 24 channels

# minus 15% headroom
24 x 0.85 = 20 channels

Le calcul aboutit à vingt, et vingt est précisément le nombre qui a provoqué un arrêt par OOM sur un vrai boîtier. Le chiffre sûr mesuré est ~16. Quand le calcul et la mesure divergent, fiez-vous à la mesure : la RSS par chaîne du tableau est une moyenne en régime établi, et les chaînes ne sont pas toutes à leur moyenne au même moment.

Considérez le calcul comme un moyen d’écarter les plans manifestement irréalisables, pas comme une autorisation d’aller jusqu’au résultat.

Marge CPU

Avec le moteur pass-through, faites la même division sur les cœurs plutôt que sur la mémoire : quatre cœurs représentent 400 points de pourcentage de CPU, à environ 15 par chaîne. Gardez la même marge de 15 %, et davantage si le boîtier pilote aussi un modulateur DVB-C ou sert des aperçus à plusieurs navigateurs à la fois.

Réseau

Interfaces

Castmux fonctionne sur une seule interface réseau, et pour une petite installation c’est un choix tout à fait raisonnable. Deux interfaces — une pour l’administration, une tournée vers les téléviseurs — sont préférables, pour une raison de diagnostic plutôt que de débit.

Lorsque l’administration et le multicast partagent un même lien, chaque panne devient ambiguë. Une liaison montante saturée rend l’interface web inerte : l’outil qui vous servirait à diagnostiquer le problème est justement celui que le problème a mis hors d’usage. Les séparer permet à l’interface d’administration de continuer à répondre pendant que vous cherchez ce qui ne va pas sur l’autre, et rend les chiffres de trafic du pied de page attribuables : une interface doit afficher un débit multicast régulier, l’autre presque rien.

Couche 2 et routage

Les téléviseurs doivent se trouver sur le même segment de couche 2 que l’appareil. Par défaut, le multicast ne traverse pas un routeur ; pour y parvenir, il faut PIM sur les routeurs intermédiaires et un IGMP snooping configuré de façon cohérente sur tout le chemin, ce qui relève de l’ingénierie réseau et sort du périmètre de ce produit.

Sur l’appareil lui-même, 224.0.0.0/4 doit pointer vers l’interface tournée vers les téléviseurs. Ce point est détaillé dans Installation → routage multicast, et mérite d’être lu avant de commander le matériel, car c’est l’exigence que l’on découvre en dernier.

Liaison montante et démarrage échelonné

La liaison montante qui transporte les flux sources doit soutenir la somme des débits de toutes les chaînes, avec de la marge. La marge compte davantage que la moyenne, à cause de ce qui se passe au démarrage.

Au démarrage de Castmux, chaque chaîne permanente veut démarrer en même temps. Chacune ouvre une connexion vers son serveur d’origine et récupère les segments aussi vite qu’il les sert, pour remplir son tampon. Huit chaînes qui font cela simultanément sur une liaison de 100 Mbit n’obtiennent pas chacune un huitième du lien pour démarrer lentement — elles expirent toutes, échouent toutes et réessaient toutes, ce qui reproduit la même rafale.

Castmux échelonne donc le démarrage des chaînes, avec un intervalle par défaut de 3 secondes entre elles. Le prix à payer : un redémarrage complet de vingt chaînes prend environ une minute. L’avantage : il aboutit. Ne réduisez pas l’intervalle pour que les redémarrages paraissent plus rapides ; sur une liaison montante contrainte, c’est exactement le changement qui fait réapparaître la panne.

Matériel DVB-C

Nécessaire uniquement si vous souhaitez une sortie RF sur le réseau coaxial. Deux éléments sont requis :

Un emplacement PCIe libre, ce qui exclut la plupart des boîtiers compacts sans ventilateur et explique généralement qu’une installation DVB-C nécessite un châssis différent d’une installation IP seule.
Une carte modulateur DVB-C prise en charge. La sortie DVB-C a été développée et mesurée sur des cartes TBS ; le matériel de référence est la TBS 5862.

Pour une installation IP seule, rien de tout cela ne s’applique. Voir Multiplexage DVB-C pour les cartes prises en charge et la configuration.

Logiciel

Un hôte Linux doté d’un runtime de conteneurs. Castmux est livré sous le nom castmux/castmux:latest et se compose d’un unique processus Go dans l’image.

L’image est construite sur Debian trixie. Ce n’est pas un choix arbitraire : les moteurs ont besoin de versions récentes de FFmpeg et TSDuck, et les versions plus anciennes de Debian les plafonnent toutes deux à des versions aux limitations connues. Alpine n’est pas une option — il n’existe aucun paquet TSDuck pour musl, le moteur pass-through ne peut donc tout simplement pas y être construit. Si vous êtes habitué aux images de la taille d’Alpine, attendez-vous à ce que celle-ci soit plus volumineuse ; voilà pourquoi.

La distribution de l’hôte importe peu, pourvu qu’elle puisse exécuter le conteneur avec le réseau hôte et les deux capacités décrites dans Installation.

Accès Internet

L’appareil a besoin d’un accès Internet sortant pour diffuser. Chaque appareil vérifie sa licence auprès du serveur de licences Castmux. Tant que sa première connexion n’a pas abouti et que l’appareil n’a pas été approuvé, il ne diffuse rien du tout. C’est vrai même lorsque toutes les sources sont sur le réseau local. Un appareil installé sur un segment sans route vers Internet n’est jamais à l’antenne.

L’accès sortant sert à quatre choses :

Usage	Destination	Nécessaire pour
Vérification de licence	`iptvauth.alteox.app`, HTTPS (TCP 443)	Obligatoire. Enrôlement, approbation et vérifications régulières. L'appareil reçoit aussi par ce biais les chaînes fournies par la licence — voir Chaînes fournies par la licence.
Télémétrie	`otel.alteox.app`, OTLP sur gRPC (TCP 4317)	Pas nécessaire pour diffuser. Les métriques et événements de chaque chaîne y sont envoyés — voir Supervision. S'il est injoignable, l'export échoue et rien d'autre n'est affecté.
Sources hébergées sur Internet	Vos serveurs d'origine	Uniquement si vos sources s'y trouvent. C'est une propriété de vos chaînes, pas du produit.
Mises à jour	Le registre de conteneurs	Uniquement lorsque vous choisissez de mettre à jour. Rien ne déclenche de mise à jour automatiquement.

Perte de la connexion

Un appareil qui s’est déjà connecté continue de diffuser pendant une coupure. Il fonctionne sur la dernière licence reçue tant qu’elle est valide, actuellement environ deux jours, et se reconnecte dès que le serveur est joignable. Une coupure plus courte que cela se traverse sans que personne ait à se déplacer sur site. Une coupure plus longue coupe toutes les chaînes à l’expiration de la licence en cache. Les réglages des chaînes sont conservés, et elles reviennent d’elles-mêmes dès qu’une vérification aboutit.

Le panneau License de la page Settings affiche l’état actuel et, si la diffusion est bloquée, la raison. Il indique aussi l’heure de la dernière vérification, la date de renouvellement de la licence et le code d’appareil que le support vous demandera. Recheck licence & channels lance immédiatement une vérification au lieu d’attendre la prochaine tentative.