Moteurs de diffusion

Les deux moteurs comparés

	Moteur de remultiplexage	Moteur pass-through
Démarrage à froid, de l'abonnement au 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%
RAM par chaîne	~72 MB	~23 MB
Chaînes sur un appareil de 2 Go	~16	25+
PID et identifiant de service	Réécrits	D'origine, préservés
Pistes audio transmises	Une	Toutes, avec leurs étiquettes de langue ISO-639
Sous-titres et télétexte	Supprimés	Transmis
Perte de paquets côté source	Masquée	Signalée fidèlement
Bourrage à débit constant	Oui	Non
Source HLS fMP4/CMAF	Oui	Non

Lequel choisir

Le moteur pass-through est le moteur par défaut et la bonne réponse dans presque tous les cas. Il consomme environ un tiers de la mémoire, ce qui détermine le nombre de chaînes sur un appareil de 2 Go ; il atteint la première image en à peu près deux fois moins de temps, ce que le spectateur perçoit comme la vitesse de changement de chaîne ; chaque datagramme qu’il envoie fait 1316 octets pleins ; et chaque langue audio de la source arrive au téléviseur avec son étiquette de langue intacte. Il en fait moins, et c’est justement pour cela qu’il le fait mieux.

Choisissez le moteur de remultiplexage lorsque l’une de ces conditions est remplie :

• Le serveur d’origine HLS publie des segments fMP4/CMAF. Le lecteur HLS du moteur pass-through ne gère que les segments MPEG-TS. Ce n’est pas configurable.
• La source est en RTMP. RTMP n’est pas du tout pris en charge par le moteur pass-through.
• Un équipement en aval exige un débit constant sur la sortie UDP. Seul le moteur de remultiplexage peut bourrer le flux jusqu’à un débit fixe. Certains décodeurs anciens et certains modulateurs RF en ont besoin ; la plupart des équipements modernes, non.

Son coût CPU plus élevé est réel mais rarement la contrainte déterminante : sur ces appareils, c’est la mémoire qui s’épuise en premier. Dimensionnez la capacité d’après la RAM.

Pourquoi le moteur de remultiplexage ne transmet qu’une piste audio

Le moteur pass-through ne démultiplexe pas : chaque PID audio de la source — ainsi que la PMT d’origine et ses descripteurs de langue ISO-639 — arrive intact en aval. Un spectateur peut choisir une langue sur le téléviseur parce que le téléviseur voit que ces langues sont présentes.

Le moteur de remultiplexage construit un nouveau transport stream. Sa liste d’arguments copie l’audio sans le réencoder, mais ne définit aucun mappage explicite des flux ; la sélection de flux par défaut s’applique donc : un flux vidéo, un flux audio, tout le reste est écarté. La piste obtenue est celle que la source présente comme sa meilleure candidate, et c’est la seule.

Transporter toutes les pistes audio ne tient qu’à une option, et elle est volontairement désactivée. Elle augmenterait le débit de sortie de chaque chaîne — les pistes audio sont légères, mais un flux en six langues n’est pas gratuit sur un multiplex — et elle modifierait le flux émis de toutes les chaînes déjà en service, ce qu’on ne fait pas globalement sur un appareil mis en service l’an dernier. Une activation facultative par chaîne : prévu.

Aucun moteur ne peut créer ce qui manque à la source

Si le serveur d’origine transporte une seule piste audio, aucun réglage du moteur n’en produira une seconde. C’est aussi pourquoi la protection contre les échelles démultiplexées des profils de résolution est importante : une échelle dont l’audio se trouve hors des variantes vidéo n’a plus aucun audio à transmettre dès qu’une seule variante vidéo est sélectionnée.

Pourquoi le moteur de remultiplexage masque les pertes à la source

Construire un nouveau transport stream implique de réattribuer les compteurs de continuité. Chaque paquet qui quitte l’appareil porte donc une séquence de compteurs correcte et ininterrompue, quoi qu’il soit arrivé. Les trous introduits en amont — par le serveur d’origine, par le chemin Internet, par un encodeur capricieux — deviennent invisibles dès qu’ils le traversent.

C’est utile en production, car un analyseur en aval cesse d’alerter sur des défauts sur lesquels il ne peut rien. C’est en revanche franchement trompeur pendant l’investigation d’une panne. Si vous cherchez à établir si un flux amont perd des paquets, passez d’abord la chaîne sur le moteur pass-through, sinon vous mesurerez la qualité de votre propre réparation plutôt que celle du flux.

Le moteur pass-through signale fidèlement les pertes pour la même raison qu’il préserve les PID et l’audio : il ne reconstruit rien.

Les métriques diffèrent selon le moteur

Les images par seconde, la vitesse de lecture et le débit annoncé par l’encodeur sont lus dans la sortie de progression du moteur de remultiplexage lui-même. Le moteur pass-through ne décode jamais la vidéo : il ne connaît pas la fréquence d’images et n’a aucune notion de vitesse de lecture. Ces valeurs n’existent pas pour lui.

Sur une chaîne pass-through, ces tuiles affichent n/a. C’est correct et attendu, ce n’est ni un défaut ni le signe d’une chaîne en mauvaise santé.

Le signal indépendant du moteur est le débit sur le réseau, mesuré par capture de paquets sur l’interface de sortie. C’est la seule mesure de vivacité qui fonctionne de manière identique sur les deux moteurs ; elle mesure ce qui a réellement quitté le port réseau plutôt que ce qu’un processus prétend avoir envoyé, et c’est celle à laquelle se fier. Voir Supervision et métriques.

Ne basez pas une supervision externe sur les images par seconde ou la vitesse de lecture

Tout watchdog, toute règle d’alerte ou tout seuil de tableau de bord construit sur ces valeurs se déclenchera en permanence sur les chaînes pass-through, car ces valeurs sont absentes plutôt que nulles — et une règle qui traite l’absence comme un zéro redémarrera indéfiniment des chaînes parfaitement saines. C’est arrivé plus d’une fois sur le terrain, et dans les deux cas le symptôme ressemblait à un bug de moteur plutôt qu’à un bug de supervision. Conditionnez ces vérifications au moteur utilisé, ou basez-les plutôt sur le débit réseau.

Nommage des services

Avec le moteur pass-through, le nom de la chaîne est écrit dans la SDT du flux sortant ; un téléviseur qui balaie le groupe multicast ou le multiplex DVB-C affiche donc le nom que vous avez configuré plutôt que celui que le serveur d’origine a pu intégrer.

Le moteur de remultiplexage ne transmet pas le nommage des services. Une chaîne sur le moteur de remultiplexage présentera le nom de service issu du remultiplexage, qui n’est généralement pas celui de l’interface Castmux. Si le nom affiché sur le téléviseur compte — et dans un hôtel ou un hôpital, c’est généralement le cas —, c’est une raison de préférer le moteur pass-through.

Choisir le moteur

Il existe deux niveaux :

Valeur globale par défaut

Se règle dans Settings. Elle s’applique à toutes les chaînes qui ne la redéfinissent pas, y compris celles ajoutées ultérieurement.

Remplacement par chaîne

Se règle sur la chaîne. À utiliser pour les exceptions — le serveur d’origine fMP4, le flux RTMP de l’encodeur local, la chaîne dont le modulateur en aval exige un débit constant.

Une chaîne sans remplacement affiche la valeur héritée, signalée comme telle ; on voit donc toujours si le moteur affiché a été choisi pour cette chaîne ou s’il suit le réglage global. Modifier la valeur globale par défaut modifie d’un coup toutes les chaînes qui en héritent ; les chaînes dotées d’un remplacement ne sont pas affectées.

Changer de moteur redémarre la chaîne

Le moteur est choisi au démarrage de la chaîne ; le changement prend donc effet au démarrage suivant, et la chaîne est redémarrée pour l’appliquer. Les spectateurs subissent le délai de démarrage à froid de ce moteur — environ 1.9 s pour le pass-through, environ 4.4 s pour le remultiplexage. Changer la valeur globale par défaut redémarre toutes les chaînes qui en héritent : faites-le pendant une période calme plutôt qu’en soirée.