Basculement SRT : résister aux pannes réseau

Le basculement SRT prend tout son sens lors de défaillances où la connexion semble intacte alors que le programme se fige. Débrancher un câble constitue un premier test utile. Un plan d’acceptation crédible couvre également la congestion, la perte silencieuse de paquets, l’interruption du trafic de retour et un chemin principal qui disparaît et réapparaît de manière répétée.

Commencez par définir l’impact sur le spectateur que vous pouvez accepter. Notez la durée maximale d’interruption de l’image, de coupure audio et de temps de rétablissement, puis testez l’ensemble de la chaîne par rapport à ces limites. Le fait qu’un récepteur change d’entrée sélectionnée ne constitue qu’une partie du processus de rétablissement.

Choisissez délibérément le mécanisme de basculement SRT

Le protocole SRT (Secure Reliable Transport) utilise la demande de répétition automatique (ARQ) pour récupérer les paquets manquants par retransmission. La mise en mémoire tampon en mode direct offre un délai de récupération ; les paquets qui ne respectent pas leur délai de livraison peuvent être abandonnés. La documentation des options de socket de la bibliothèque SRT définit ces contrôles. La retransmission dépend toutefois d’un chemin opérationnel entre l’émetteur et le récepteur.

Basculer entre des flux indépendants

Un récepteur peut accepter deux flux SRT, les surveiller et en sélectionner un pour la sortie. Chaque flux peut disposer de son propre encodeur, de sa propre connexion et de sa propre synchronisation. Le récepteur doit décider quand basculer et comment gérer la transition entre ces flux multimédias.

La documentation relative aux entrées du routeur d’AWS MediaConnect fournit un exemple concret : ses entrées SRT prennent en charge le basculement de source, tandis que son option de fusion de paquets s’applique aux autres protocoles répertoriés. Le déclencheur documenté est de 500 millisecondes sans données source. Il s’agit d’un intervalle de détection spécifique au produit, et non d’une garantie du protocole SRT ni d’une promesse concernant l’interruption visible.

Protection des paquets à l’aide de groupes de connexions

Les groupes de connexions SRT coordonnent plusieurs connexions transportant un même flux de données. Le mode broadcast envoie des données en double sur les chemins membres et élimine les doublons à la réception. Le mode main/backup (principal/secours) envoie normalement la charge utile sur un seul chemin, les autres connexions étant disponibles pour prendre le relais.

Le guide de démarrage rapide sur le regroupement de connexions SRT, hébergé dans le dépôt open source de Haivision, documente les exigences spécifiques en matière de compilation et d’application. Vérifiez la prise en charge des groupes aux deux extrémités, la configuration de la bibliothèque installée et qui se charge de reconnecter les membres défaillants. Un appareil étiqueté « compatible SRT » peut n’exposer que des connexions ordinaires.

La redondance en mode broadcast consomme de la bande passante sur chaque chemin. Elle nécessite également de traiter séparément les défaillances de l’émetteur et du récepteur communs aux chemins. Deux versions encodées indépendamment d’un même programme ne peuvent pas être simplement considérées comme des paquets en double au sein d’un groupe.

A. Basculer entre des flux indépendants

Encodeur A

Encodeur B

Flux SRT A

Flux SRT B

Sélectionner un fluxDécodeur / sortie

Le récepteur sélectionne un flux complet. Des flux encodés indépendamment peuvent avoir des horodatages et des séquences de paquets différents ; testez la transition du programme.

B. Dupliquer les paquets avec un groupe SRT broadcast

Un émetteurPaquet P

Chemin APaquet P

Chemin BPaquet P

Éliminer le doublon PUn flux de données

Les mêmes données passent par les deux chemins. Les applications aux deux extrémités doivent prendre en charge les groupes. Chaque chemin transporte la charge utile ; les défaillances des extrémités communes restent à traiter.

Mode broadcast représenté. En mode main/backup, la charge utile emprunte normalement un seul chemin membre. Ces schémas ne présument pas de la prise en charge des groupes par Evrideo.

Identifiez les points de défaillance communs

Suivez les deux itinéraires en passant par l’hôte de l’encodeur, l’interface réseau, le commutateur d’accès, le pare-feu, la liaison Internet et l’infrastructure de réception. Demandez-vous quelle alimentation électrique, quelle gaine du dernier kilomètre, quel réseau en amont ou quel composant cloud peut interrompre les deux.

Des adresses de destination différentes ne permettent à elles seules de conclure que très peu de choses. Deux interfaces peuvent tout de même utiliser le même routeur. Deux opérateurs peuvent partager une entrée physique. Notez l’indépendance que vous avez vérifiée et les risques communs qui subsistent.

Déterminez séparément si vous avez besoin d’une protection contre une perte de réseau, une défaillance de l’encodeur, une défaillance du récepteur ou la perte d’un site entier. Un chemin réseau dupliqué à partir d’un encodeur couvre un périmètre de défaillance différent de celui de deux chaînes de contribution complètes.

Encodeur communPoint de défaillance commun

Routeur communPoint de défaillance commun

Deux chemins réseau

Circuit A

Circuit B

Récepteur communPoint de défaillance commun

Un circuit peut survivre à une panne réseau. La perte de l’encodeur, du routeur ou du récepteur commun peut interrompre les deux chemins. Vérifiez aussi l’alimentation, les accès physiques et l’infrastructure en amont.

Prévoyez le délai jusqu’au rétablissement du décodage

Mesurez trois intervalles : la détection de la défaillance, l’obtention d’un flux de remplacement exploitable et la restauration de la lecture en aval. Les tampons existants peuvent masquer certaines perturbations, tandis que l’attente d’un point d’accès décodable ou la reconstruction de l’état du programme peuvent les prolonger. Mesurez le résultat au lieu de traiter ces intervalles comme une formule additive universelle.

Enregistrez le temps aller-retour (RTT), la variation du délai, les retransmissions et les pertes non récupérées sous une charge réaliste. Tenez compte de l’itinéraire le plus lent. Une solution de secours doit disposer d’une capacité suffisante pour l’intégralité du programme et le trafic de récupération lorsqu’elle est activée.

Considérez un flux de contribution hypothétique de 12 Mb/s avec un RTT principal de 40 ms et un RTT de secours de 150 ms. Ces chiffres ne suffisent pas à eux seuls à déterminer un paramètre de latence sûr. Injectez les rafales de pertes et la congestion attendues, vérifiez quand les paquets de remplacement arrivent et observez si le récepteur respecte toujours ses délais de diffusion. Répétez l’opération en présence d’un trafic concurrent et lorsque les deux routes sont dégradées.

Les paramètres de reconnexion méritent également d’être examinés. La documentation de l’élément source SRT de GStreamer fait la distinction entre la reconnexion en mode caller et le maintien de l’écoute en mode listener après une déconnexion. La reconnexion automatique n’établit pas un deuxième chemin de programme utilisable. Testez l’application déployée, y compris en cas d’échecs d’authentification et de redémarrages de processus.

1. t0
   Injecter la panne

   Perte de paquets, suppression silencieuse du trafic, image figée ou arrêt d’un processus.

2. t1
   Détecter et sélectionner

   Consignez séparément les horodatages de l’alarme et de la sélection d’entrée.

3. t2
   Obtenir un flux exploitable

   Vérifiez les tables du programme, les horodatages et un point d’accès décodable.

4. t3
   Vérifier la sortie décodée

   Mesurez la reprise de l’image et du son, les sous-titres et la continuité SCTE-35.

5. t4
   Rétablir la protection

   Réparez le chemin défaillant, vérifiez le secours et appliquez la politique de retour convenue.

Jalons indicatifs, sans échelle temporelle. Les étapes peuvent se chevaucher et les tampons masquer les défauts. Mesurez l’interruption visible en sortie ; n’additionnez pas ces étapes pour la prévoir.

Vérifiez le programme après la commutation

Pour les flux de transport MPEG, comparez l’identité du programme, les identifiants de paquets, les tables de programme, la configuration des codecs et la synchronisation entre les flux. Vérifiez la correspondance des pistes audio et des sous-titres requis. Vérifiez la disponibilité de points d’accès aléatoire permettant de reprendre le décodage et déterminez comment le récepteur gère toute discontinuité des horodatages.

Le rapport technique ETSI TR 101 290 fournit des recommandations de mesure des flux de transport couvrant les tables de programme, les compteurs de continuité et la synchronisation PCR/PTS. Utilisez ces mesures en parallèle avec l’image et le son décodés. Une session SRT établie peut transporter une image figée, un son manquant ou une signalisation de programme endommagée.

Capturez le signal de sortie avant, pendant et après la commutation. Vérifiez l’alignement audio/vidéo, les sous-titres et les marqueurs SCTE-35, y compris lors d’une commutation pendant une pause publicitaire. Lorsqu’un packager et un lecteur de streaming suivent le récepteur, intégrez-les à la répétition : l’expérience de lecture finale constitue le critère d’acceptation.

Simulez des pannes représentatives de la production

Utilisez un circuit de test isolé ou une fenêtre de maintenance approuvée. Convenez d’abord des seuils, désignez un responsable de la restauration et consignez les versions logicielles, les paramètres et les horodatages synchronisés. Ce qui suit est un plan de test technique, et non une affirmation concernant les résultats mesurés chez les clients :

• Injectez des pertes aléatoires, des pertes en rafales, de la gigue et des réordonnancements. Comparez les paquets retransmis avec les pertes non récupérées et les défauts de sortie visibles.
• Éliminez silencieusement le trafic UDP, puis altérez séparément le sens inverse. La détection doit fonctionner sans message de déconnexion explicite.
• Limitez la capacité et augmentez les différences de délai de trajet. Vérifiez que l’itinéraire restant assure le service sous charge.
• Redémarrez les émetteurs et les récepteurs, puis testez des identifiants de secours incorrects. Vérifiez que les alarmes signalent un système de secours inutilisable.
• Rétablissez le système principal à plusieurs reprises. Observez le comportement de basculement et testez une deuxième défaillance après la reprise.
• Gelez l’image source ou supprimez le son tandis que les paquets continuent de circuler. Vérifiez que la surveillance au niveau du programme détecte le problème.

Pour chaque test, enregistrez l’injection de défaut, l’alarme, la sélection de chemin, la sortie utilisable et la redondance rétablie. Conservez les enregistrements de la sortie ainsi que les compteurs réseau. Après une première commutation réussie, un chemin de secours non rétabli laisse le service vulnérable à la panne suivante.

Convenez de la politique de retour au système principal

Précisez si le système revient automatiquement, attend un intervalle de stabilité ou nécessite l’intervention d’un opérateur. Dans l’exemple AWS, une source principale configurée est à nouveau sélectionnée lorsque les données reviennent. D’autres implémentations peuvent différer. Des commutations fréquentes lors d’une reprise instable peuvent interrompre les téléspectateurs à plusieurs reprises ; veillez donc à tester la politique en conditions réelles.

Evrideo Outpost fournit des routes principales et de secours configurables, une visibilité SRT et une surveillance du flux de transport. StreamCheck prend en charge les diagnostics SRT préalables à la diffusion. Utilisez ces fonctionnalités pour recueillir des données de suivi et confirmer le comportement spécifique des récepteurs requis par votre conception, plutôt que de supposer la prise en charge des groupes de paquets ou des transitions sans perte.

Validez le basculement SRT à l’aide d’une matrice de pannes convenue, d’une mesure de la reprise de la diffusion et de la désignation d’un responsable chargé de rétablir la redondance. Contactez Evrideo pour discuter des voies de contribution et des tests d’acceptation pour votre chaîne.