Basculement de flux vidéo : guide complet pour un streaming sans interruption

Qu’est-ce que le basculement de flux vidéo ?

Le basculement de flux vidéo est le processus automatique qui consiste à passer d’une source vidéo défaillante ou dégradée à une source de secours sans interrompre le flux de sortie. Lorsqu’une entrée principale tombe (que ce soit à cause d’une panne d’encodeur, d’une coupure réseau ou d’une dégradation du signal), le système de basculement détecte le problème et redirige une source de secours vers la sortie.

Pour les spectateurs, l’objectif est l’invisibilité. Un basculement correctement implémenté doit être imperceptible : pas de frames noires, pas d’indicateur de chargement, pas d’interruption. Le flux continue simplement comme si rien ne s’était passé.

Le basculement n’est pas optionnel pour la diffusion professionnelle. Chaque production en direct qui compte : couverture sportive, journaux télévisés, événements d’entreprise, chaînes 24h/24 — repose sur une forme de protection par basculement. La question n’est pas de savoir si vous en avez besoin, mais comment le mettre en oeuvre correctement. Pour des conseils tactiques concrets, consultez notre guide des bonnes pratiques de basculement vidéo.

Pourquoi le basculement est plus important que jamais

L’économie du streaming en direct a changé. Il y a dix ans, un flux interrompu était un désagrément. Aujourd’hui, c’est une perte financière directe :

• Les revenus publicitaires s’évaporent dès que les spectateurs quittent un flux défaillant
• Les algorithmes des plateformes pénalisent les chaînes qui ont des problèmes de fiabilité, réduisant leur visibilité future
• Les SLA contractuels dans le broadcast sportif et d’entreprise comportent des pénalités financières pour les temps d’arrêt
• La réputation de marque subit un coup qu’aucun post-mortem ne peut pleinement réparer

Le passage au transport IP (abandonnant les circuits SDI dédiés) a augmenté à la fois les opportunités et les risques. Les réseaux IP sont moins chers et plus flexibles, mais ils introduisent des modes de défaillance que les circuits dédiés n’avaient jamais : perte de paquets, changements de routage, congestion et crashs d’équipements. Le basculement est le mécanisme qui rend le transport IP suffisamment fiable pour la diffusion critique.

Types de basculement : veille active, tiède et froide

Tous les basculements ne se valent pas. Les trois approches standard diffèrent en termes de réactivité, de coût et de vitesse de commutation.

Veille active (Hot Standby)

Dans une configuration de veille active, la source de secours est pleinement active et synchronisée avec la source principale. Les deux sources reçoivent, décodent et mettent en buffer simultanément. Lorsque la principale tombe en panne, le basculement est instantané car la source de secours est déjà en fonctionnement.

Caractéristiques :

• Temps de basculement : moins de 50 ms (failover total avec détection : moins de 200 ms)
• Coût en ressources : 2 fois la bande passante d’ingestion et le traitement
• Fiabilité : maximale : la source de secours est vérifiée en direct avant d’être sollicitée
• Cas d’usage : diffusions critiques où toute interruption est inacceptable

La veille active est ce que Vajracast implémente par défaut. Chaque entrée dans une chaîne de basculement est activement surveillée et pré-bufferisée, de sorte que le basculement s’effectue dans le temps nécessaire pour rediriger un pointeur interne et non dans le temps nécessaire pour établir une nouvelle connexion.

Veille tiède (Warm Standby)

En veille tiède, la source de secours est connectée mais pas pleinement active. La connexion est établie et périodiquement validée, mais le système ne décode pas continuellement le flux complet. Lors du basculement, il y a une brève période d’initialisation.

Caractéristiques :

• Temps de basculement : 500 ms à 2 secondes
• Coût en ressources : inférieur à la veille active (surcoût de connexion uniquement)
• Fiabilité : bonne, mais avec une transition visible
• Cas d’usage : flux secondaires, flux non critiques, déploiements sensibles aux coûts

Veille froide (Cold Standby)

La veille froide signifie que la source de secours est configurée mais non connectée. En cas de défaillance de la source principale, le système initie une nouvelle connexion de zéro : résolution DNS, handshake TCP/UDP, négociation du flux et mise en buffer.

Caractéristiques :

• Temps de basculement : 2 à 10+ secondes
• Coût en ressources : minimal jusqu’au déclenchement du basculement
• Fiabilité : la plus faible : le chemin de secours n’est pas testé avant d’être sollicité
• Cas d’usage : reprise après sinistre, quand un certain temps d’arrêt est acceptable

Pour la diffusion professionnelle, la veille active est la seule option qui répond aux attentes du public. La veille froide convient mieux à l’infrastructure de second plan (par exemple, le basculement d’un serveur d’enregistrement) où quelques secondes de coupure sont tolérables.

Comment Vajracast implémente le basculement

Vajracast a été conçu avec le basculement comme composant architectural fondamental, et non comme une fonctionnalité ajoutée après coup sur un moteur de routage. Voici comment cela fonctionne en interne.

Chaînes de priorité

Chaque route dans Vajracast peut avoir plusieurs entrées organisées en chaîne de priorité. L’entrée avec la plus haute priorité est la source préférée. Si elle tombe en panne, le système bascule automatiquement vers l’entrée suivante dans la chaîne.

Priorité 1 : SRT Listener (encodeur principal) ← actif
Priorité 2 : SRT Caller (encodeur de secours)  ← veille active
Priorité 3 : RTMP (encodeur cloud)              ← veille active
Priorité 4 : HTTP/TS (mire/fallback)            ← veille active

Le nombre d’entrées dans une chaîne est illimité. Chaque entrée est surveillée indépendamment, et le système sélectionne toujours l’entrée saine ayant la plus haute priorité.

Surveillance de santé

Vajracast évalue en continu la santé de chaque entrée à l’aide de multiples signaux :

• État de connexion: la source est-elle connectée et livre-t-elle des données ?
• Analyse du débit: le débit est-il dans la plage attendue, ou est-il passé sous un seuil configurable ?
• Taux de perte de paquets: pour les entrées SRT, la perte dépasse-t-elle la capacité de récupération ?
• Compteurs de continuité: les compteurs de continuité MPEG-TS s’incrémentent-ils correctement, ou y a-t-il des lacunes ?
• Détection de timeout: les données ont-elles complètement cessé d’arriver ?

Chaque signal de santé possède un seuil configurable et une fenêtre d’hystérésis. Cela empêche les faux basculements causés par des micro-coupures réseau. Par exemple, vous pouvez configurer : « basculer si la perte de paquets dépasse 15 % pendant plus de 300 ms en continu ».

Basculement en moins de 200 ms

Lorsqu’une condition de basculement est détectée, le changement s’effectue en trois phases :

1. Détection (configurable, typiquement 50-100 ms) — les métriques de santé franchissent le seuil pendant la durée configurée
2. Décision (moins de 1 ms) — le moteur de routage sélectionne la prochaine entrée saine dans la chaîne de priorité
3. Commutation (moins de 1 ms) — le pointeur de flux interne redirige vers les données pré-bufferisées de l’entrée de secours

Parce que les entrées de secours sont déjà ingérées, décodées et mises en buffer en veille active, le basculement réel est une opération de pointeur. Il n’y a pas de négociation de connexion, pas de délai de buffering, pas d’initialisation de codec. La sortie continue avec les données de la source de secours dès le paquet suivant.

Temps total de basculement : moins de 200 ms dans le pire des cas, typiquement moins de 100 ms. A 30 fps, cela représente 3 à 6 frames — imperceptible pour les spectateurs.

Stratégie de sélection du failover

Quand un failover se déclenche, quelle entrée de secours prend la main ? En mode quality, Vajracast propose deux stratégies (configurables par route) :

• Best Score (par défaut) : bascule vers l’entrée à la meilleure qualité courante — celle qui a le meilleur score composite sur silence, erreurs de compteur de continuité, bitrate et jitter. À utiliser quand vos entrées ont des qualités différentes et que vous voulez toujours la meilleure disponible.
• Round-robin : descend la liste vers l’entrée suivante qui reçoit encore du signal, dans l’ordre de priorité (retour en haut de la liste après être arrivé en bas). Saute les entrées mortes. À utiliser quand les entrées sont équivalentes et que vous voulez un ordre déterministe.

En mode simple, il n’y a pas de choix de stratégie — c’est un round-robin implicite sur les entrées connectées. Le réglage de stratégie ne compte qu’en mode quality.

Failback automatique (optionnel)

Le failover gère la chute. Le failback gère le retour : quand une entrée de priorité supérieure récupère, Vajracast peut remonter la liste vers elle automatiquement. C’est opt-in par route (checkbox OFF par défaut dans la modal Failover Settings). Sans activation, après un failover vous restez sur le secours jusqu’à ce qu’un opérateur bascule manuellement. Une fois activé, le système remonte vers l’entrée fonctionnelle la plus haute sans aucune action.

Le failback n’est pas un simple « je rebascule dès le premier paquet ». Cette approche est un piège : un lien qui flap revient 2 secondes, déclenche le failback, retombe, déclenche le failover, boucle. Le résultat est pire qu’un signal resté sur le secours. Le moteur de failback de Vajracast est construit autour de ce problème.

Évaluation state-driven. Un timer de 5 secondes tourne en permanence sur chaque route avec failback activé. À chaque tick, il relit l’état de toutes les entrées. Si une entrée de priorité plus haute que l’actif est saine, le compteur de stabilité démarre.

Fenêtre de stabilité (par défaut 3 secondes, configurable). Le candidat doit rester sain sur des ticks consécutifs avant le switch :

• Tick 1 : candidat sain → cleanChecks = 1
• Tick 2 : candidat toujours sain → cleanChecks = 2
• Tick 3 : candidat toujours sain → cleanChecks = 3 → switch
• Un seul tick mauvais à n’importe quel moment → cleanChecks = 0, reset complet

Le reset est volontairement strict. Un seul hoquet efface toute la progression. C’est ce qui rend le système immunisé au flapping.

Toujours par priorité. Contrairement au failover (qui peut utiliser les stratégies round-robin ou best-score), le failback se déplace toujours par ordre de priorité — c’est « rentrer à la maison sur le primaire », pas « choisir le meilleur disponible ». Si vous tournez sur l’entrée #3 et que #2 récupère, le failback bascule vers #2. Si #1 récupère ensuite, un autre cycle de failback bascule vers #1. Le système remonte toujours vers l’entrée saine de plus haute priorité.

Cooldown (par défaut 7 secondes, configurable). Immédiatement après un failback réussi, toute évaluation est suspendue. Cela évite une race condition où un compteur de stabilité sur une autre entrée candidate pourrait déclencher un second switch juste après le premier. Le cooldown laisse le temps à l’entrée fraîchement promue de se stabiliser.

Les critères de santé s’ajustent au mode failover. En mode simple, « sain » signifie connecté avec bande passante > 0 — des paquets arrivent. En mode quality, le candidat doit passer tous les seuils configurés (erreurs CC, jitter, débit minimum) pendant toute la fenêtre de stabilité. Un lien qui reconnecte à bas bitrate ne déclenche pas de failback en mode quality. Le système préfère rester sur le secours plutôt que switcher vers un signal borderline.

La configuration se fait dans la modal Failover Settings : une checkbox Auto-failback, un champ Failback Stability (ms) et un champ Cooldown (ms). Les routes où le failback est actif sont visuellement marquées d’un suffixe ↩ sur le badge failover dans les vues Table, Card et Diagram.

Basculement agnostique au protocole

L’un des avantages architecturaux de Vajracast est que le basculement fonctionne entre types d’entrées. La chaîne de priorité peut combiner n’importe quelle combinaison d’entrées supportées :

Cette flexibilité est essentielle pour les déploiements réels où toutes les sources n’utilisent pas le même protocole. Un contributeur distant peut envoyer en RTMP parce que son encodeur ne supporte pas SRT. Une unité mobile peut utiliser un lien SRTLA agrégé pour atteindre la passerelle de manière fiable sur cellulaire. L’encodeur sur site utilise SRT pour des performances optimales. Du point de vue du moteur de basculement, ce sont toutes des entrées — chacune est surveillée, monitorée en santé, et éligible pour prendre le slot actif quand les entrées de priorité supérieure tombent.

SRTLA n’est pas du failover

Un point qui mérite d’être posé clairement puisque les deux sont souvent confondus : SRTLA n’est pas un mécanisme de failover. C’est un protocole d’agrégation de liens qui bonde plusieurs connexions réseau physiques (typiquement des modems cellulaires) en un seul flux SRT logique. Si un lien bondé tombe, les liens restants maintiennent le flux — le flux lui-même ne bascule vers rien. Du point de vue de la passerelle, une entrée SRTLA est une entrée, un flux, une ligne dans la chaîne de priorité.

Le failover opère à un niveau différent : il bascule entre des entrées entièrement indépendantes. SRTLA gère la redondance des liens à l’intérieur d’une source unique ; le failover gère la redondance des sources entre sources. Ils sont complémentaires et orthogonaux. Vous pouvez faire du failover sans SRTLA (deux flux SRT non bondés sur deux FAI différents). Vous pouvez faire du SRTLA sans failover (un seul flux cellulaire bondé comme unique entrée). Ou vous pouvez combiner les deux : utiliser une entrée cellulaire SRTLA comme un des slots d’une chaîne de failover qui contient aussi une entrée SRT fibre.

Pour une comparaison approfondie de SRT et RTMP et quand utiliser chacun, consultez SRT vs RTMP : Quel protocole de streaming choisir ?.

Cas d’usage réels du basculement

Diffusion sportive en direct

La diffusion sportive est le scénario de basculement le plus exigeant. Un flux interrompu pendant un but, un touchdown ou une arrivée de course est irrécupérable. L’instant est passé, et aucun replay ne peut remplacer l’expérience en direct. Pour un aperçu complet des défis techniques de la diffusion sportive, lisez notre article sur la diffusion sportive en direct.

Configuration type :

• Principale : SRT depuis le car régie sur site
• Secours 1 : SRT depuis un second encodeur sur un chemin réseau indépendant (FAI distinct ou circuit dédié)
• Secours 2 : Chemin cellulaire en dernier recours — l’encodeur mobile utilise l’agrégation SRTLA en interne pour survivre aux pannes de modems individuels, mais du point de vue de la chaîne de failover ce n’est qu’une entrée SRT de plus
• Secours 3 : Générateur Bars & Tone intégré avec overlay « Difficultés techniques »

La chaîne de priorité de Vajracast gère cela nativement. Le système fait tourner les quatre entrées en veille active, surveillant chacune en permanence. Si l’encodeur principal crashe, le basculement vers le Secours 1 s’effectue en moins de 100 ms. Si l’ensemble du lieu perd sa connexion internet filaire, le chemin cellulaire prend le relais — et parce que ce chemin cellulaire est agrégé SRTLA sur plusieurs modems, la chute d’un modem ne se voit même pas au niveau du failover. Si le lien cellulaire entier tombe (tous les modems morts), seulement alors le failover escalade vers le fallback Bars & Tone plutôt qu’un lecteur cassé.

Nous avons fait tourner plus de 40 routes dans cette configuration pour la production sportive en direct, 24h/24 et 7j/7. Le système a été testé en conditions réelles, pas seulement en laboratoire.

Chaînes linéaires 24h/24

Les chaînes qui diffusent en continu — réseaux d’information, chaînes musicales, programmes religieux — ne peuvent se permettre aucun temps d’arrêt. Contrairement à la production événementielle avec un début et une fin définis, les chaînes 24/7 doivent survivre à tous les scénarios de panne possibles sur des semaines et des mois.

Configuration type :

• Principale : SRT depuis le serveur de playout
• Secours 1 : SRT depuis un serveur de playout redondant
• Secours 2 : Pull HTTP/TS depuis un serveur de playlist pré-programmé
• Le basculement est combiné avec la reprise après crash — si le processus Vajracast redémarre, il reconstruit automatiquement toutes les routes en moins de 5 secondes

La fonctionnalité de reprise après crash est particulièrement importante ici. Dans un environnement 24/7, la passerelle doit survivre non seulement aux pannes d’entrée mais aussi à ses propres redémarrages (mises à jour OS, crashs de processus, maintenance matérielle). Le système d’adoption de processus de Vajracast détecte les processus FFmpeg encore en cours après un redémarrage et se reconnecte à eux sans interrompre les flux de sortie.

Production à distance (REMI)

La production à distance déplace la régie de production hors du lieu de l’événement. Les flux caméra sont envoyés en IP vers un centre de production où le mélange, les habillages et la distribution ont lieu. Ce modèle repose entièrement sur un transport fiable — et le basculement est le filet de sécurité. Découvrez comment mettre en place un workflow complet dans notre guide sur la production distante avec SRT et Starlink.

Configuration type :

• Principale : SRT depuis chaque encodeur caméra sur site
• Secours : un lien cellulaire SRTLA-bondé par caméra, alimentant une entrée SRT secondaire dans la même chaîne de priorité (le bonding gère les pannes de modem individuel à l’intérieur du lien ; le failover gère le cas où le lien cellulaire est complètement coupé)
• Retour : SRT vers le lieu pour l’IFB (interruptible foldback) et le monitoring de confiance

Dans les workflows REMI, chaque caméra constitue une chaîne de basculement indépendante. Vajracast gère cela en créant des routes séparées pour chaque caméra, chacune avec sa propre chaîne de priorité et sa surveillance de santé. La vue diagramme dans l’interface facilite la visualisation et la gestion simultanée de dizaines de routes.

Supervision et alertes pour les événements de basculement

Un basculement que vous ne pouvez pas observer est un basculement auquel vous ne pouvez pas faire confiance. Une supervision efficace comporte trois niveaux :

Tableau de bord en temps réel

L’interface web de Vajracast affiche l’état de chaque entrée dans chaque route :

• Vert : sain, actif
• Jaune : connecté mais dégradé (pertes élevées, faible débit)
• Rouge : déconnecté ou en panne
• Indicateur actif montrant quelle entrée dans la chaîne de priorité alimente actuellement la sortie

La vue diagramme fournit une carte visuelle de toutes les routes, avec des overlays de statut en temps réel sur chaque connexion.

Métriques Prometheus

Vajracast expose plus de 50 métriques via un endpoint /metrics compatible Prometheus. Les métriques liées au basculement comprennent :

vajracast_input_status{route="sports_main", input="primary"} 1
vajracast_input_status{route="sports_main", input="backup1"} 1
vajracast_failover_events_total{route="sports_main"} 3
vajracast_failover_last_timestamp{route="sports_main"} 1707523200
vajracast_input_bitrate_bps{route="sports_main", input="primary"} 8500000
vajracast_input_packet_loss{route="sports_main", input="primary"} 0.002

Ces métriques peuvent être graphées dans Grafana (des tableaux de bord préconfigurés sont inclus) et utilisées pour déclencher des alertes via Alertmanager. Par exemple : « Alerter si une route a déclenché plus de 2 événements de basculement au cours de la dernière heure. »

Journalisation des événements et webhooks

Chaque événement de basculement est journalisé avec :

• Horodatage
• Nom de la route
• Entrée source (celle qui a échoué)
• Entrée cible (celle qui a pris le relais)
• Raison (timeout, seuil de perte de paquets, chute de débit, basculement manuel)
• Durée sur la source de secours avant récupération

Ce journal est inestimable pour l’analyse post-événement. Si un basculement s’est déclenché pendant une diffusion, vous pouvez retracer exactement ce qui s’est passé, quand et pourquoi — sans conjecturer.

Bonnes pratiques pour configurer le basculement

1. Utilisez des chemins réseau indépendants

Si vos entrées principale et de secours partagent le même switch réseau, le même FAI ou le même câble, une seule panne réseau emporte les deux. Une véritable redondance nécessite des chemins indépendants :

• FAI différents pour la principale et la secours
• Interfaces réseau physiques distinctes
• Câblages séparés (conduits différents)
• Pour la sauvegarde cellulaire, des opérateurs différents

2. Testez votre basculement régulièrement

Un système de basculement jamais testé n’est pas un système de basculement — c’est un espoir. Planifiez des exercices de basculement réguliers :

• Débranchez le câble réseau de l’encodeur principal pendant un flux de test
• Arrêtez le processus de l’encodeur et mesurez le temps de basculement
• Injectez de la perte de paquets avec des outils de simulation réseau (tc netem sous Linux) pour tester la détection de seuils
• Vérifiez que la récupération automatique fonctionne quand la source principale revient

Testez en charge. Le comportement de basculement peut différer quand le système gère 50 routes par rapport à 2.

3. Ajustez vos seuils

Les seuils par défaut ne sont qu’un point de départ. Ajustez-les en fonction de votre environnement spécifique :

• Timeout trop agressif (par exemple 50 ms) — provoque de faux basculements sur des micro-coupures réseau
• Timeout trop conservateur (par exemple 5 secondes) — les spectateurs voient 5 secondes de vidéo cassée avant le basculement
• Point de départ recommandé : timeout de 200-500 ms, seuil de perte de paquets à 10 %, plancher de débit à 50 %

Surveillez votre journal de basculements. Si vous constatez des basculements fréquents suivis d’une récupération immédiate, vos seuils sont trop agressifs.

4. Mettez toujours un Bars & Tone en dernière position

La dernière entrée de votre chaîne de priorité doit être quelque chose qui ne peut pas tomber. Vajracast embarque un générateur Bars & Tone pensé exactement pour ça : une entrée virtuelle qui produit un flux MPEG-TS réel en local, sans aucune source externe, sans réseau, sans encodeur. Comme il tourne sur le serveur lui-même, il est toujours disponible. Il n’y a rien à déconnecter.

Ce n’est pas une image statique. C’est un signal de test de niveau broadcast :

• Patterns vidéo : mires SMPTE (75 % ou 100 % HD), PAL 100 % ou testsrc2 de FFmpeg avec éléments mobiles
• Six presets couvrant 1080p25, 1080i50, 576i50 (audio 8 canaux), 720p50 avec horloge, 1080p25 HEVC et 540p25 pour scénarios bas-débit
• Text overlay : nom de chaîne, identifiant ou message personnalisé, police/taille/couleur/position configurables, brûlé dans la vidéo
• Clock overlay : heure serveur brûlée pour debug lip-sync ou preuve de direct horodatée
• Animation frame-identifiable : square pulse ou staircase pulse rend le pattern identifiable frame par frame
• Logo overlay : PNG superposé dans un coin
• Tone audio : 1 kHz, 400 Hz, 440 Hz ou silence ; 2, 4 ou 8 canaux ; niveau configurable de 0 à -20 dBFS ; mode sweep qui cycle le tone canal par canal

Au-delà du fallback d’urgence, le même générateur couvre plusieurs workflows qui maintiennent les routes chaudes et réduisent les frictions de test :

• Validation downstream : spawner un Bars & Tone avant la production. Vos viewers HLS, vos callers SRT, vos multiviewers reçoivent immédiatement un signal known-good. Si le viewer ne voit rien, le problème est downstream, pas upstream
• Maintien d’un slot chaud : pendant que le car régie se prépare, la route reste live sur les bars. Les décodeurs distants restent connectés, pas de déconnexion SRT à gérer. Quand le vrai signal arrive, un failover manuel (Set Active) ou une chaîne de priorité configurée prend le relais proprement
• Vérification des canaux audio : le mode sweep fait tourner le tone canal par canal pour que votre opérateur downstream confirme que le câblage 5.1 ou 7.1 est correct
• Mesure de lip-sync : le pattern animé combiné au tone permet de mesurer visuellement l’offset audio/vidéo downstream
• Démo prospect : montrer un workflow Vajracast complet depuis une salle de réunion avec zéro équipement physique

Configurez-le en priorité N+1 dans votre chaîne de failover. Si toutes les sources live tombent, les spectateurs voient un pattern de test intentionnel avec le nom de votre chaîne, pas une frame figée ni un lecteur cassé.

5. Surveillez vos sources de secours

Une source de secours hors ligne quand vous en avez besoin est inutile. La surveillance en veille active ne concerne pas seulement la réactivité — il s’agit de valider en permanence que la source de secours est saine. Vajracast surveille toutes les entrées d’une chaîne de priorité de manière égale, qu’elles soient actives ou en veille. Si votre source de secours tombe, vous le savez immédiatement, pas au moment où la source principale échoue et que la secours ne prend pas le relais.

6. Planifiez la redondance au niveau de la passerelle

Le basculement protège contre la défaillance des entrées. Mais qu’en est-il de la défaillance de la passerelle elle-même ? Pour une fiabilité maximale, faites tourner deux instances Vajracast :

• La passerelle principale gère toutes les routes de production
• La passerelle secondaire duplique la configuration et peut prendre le relais via un basculement DNS ou des health checks de load balancer
• Les deux instances peuvent utiliser la même infrastructure de déploiement Docker/Kubernetes

Comparaison de Vajracast avec d’autres solutions de basculement

Les mélangeurs matériels excellent en commutation frame-accurate pour les workflows SDI mais ne peuvent pas gérer les environnements multi-protocoles IP. Les solutions cloud introduisent de la latence et des coûts à la minute qui s’accumulent rapidement. Le basculement manuel est intrinsèquement peu fiable car il dépend d’un humain éveillé, attentif et rapide.

Vajracast se positionne au juste milieu : défini par logiciel, natif IP, multi-protocole et automatisé — pour une fraction du coût des alternatives matérielles ou cloud.

Synthèse

Pour une référence concrète d’un déploiement Vajracast redondé avec failover multi-entrées sur deux ingests et quatre régions de restream, voir l’exemple de déploiement — schémas annotés avec détails au survol de chaque nœud.

Une configuration de basculement complète dans Vajracast suit cette structure :

1. Définissez votre route: une destination de sortie (par exemple, push SRT vers CDN)
2. Ajoutez l’entrée principale: votre encodeur principal, priorité la plus élevée
3. Ajoutez les entrées de secours: par ordre de priorité, chacune sur un chemin indépendant
4. Ajoutez un fallback statique: priorité la plus basse, disponibilité garantie
5. Configurez les seuils de santé: timeout, perte de paquets, plancher de débit
6. Définissez le comportement de récupération: récupération auto avec délai de maintien, ou manuelle
7. Connectez la supervision: scraping Prometheus, tableaux de bord Grafana, alertes
8. Testez tout: simulez des pannes avant de passer en direct

Avec cette configuration, votre flux est protégé contre les pannes d’encodeur, les coupures réseau, les problèmes de protocole et même la perte complète de connectivité du lieu. Le système gère tout automatiquement, silencieusement et de manière fiable.

Pour un guide de configuration pas à pas, consultez Guide de configuration SRT : de zéro à la production. Pour l’architecture globale du routage et de la distribution des flux, poursuivez vers Routage de flux en direct : le guide complet.

Prochaines étapes

• Hub broadcast — la plateforme de routage centrale qui gère le basculement multi-régions
• Passerelle de streaming SRT — le guide complet de l’infrastructure vidéo basée sur SRT
• Bonnes pratiques de basculement vidéo — guide tactique concis pour la configuration du basculement
• SRT vs RTMP — comprendre les compromis protocolaires qui affectent les performances de basculement
• Routage de flux en direct — comment router, distribuer et gérer les signaux vidéo dans votre infrastructure