Routage de flux en direct : le guide complet de la gestion des signaux vidéo

Qu’est-ce que le routage de flux en direct ?

Le routage de flux en direct est le processus qui consiste à diriger les signaux vidéo depuis leurs sources vers leurs destinations. Dans sa forme la plus simple, le routage prend une entrée vidéo et l’envoie vers une sortie. En pratique, le routage professionnel implique la conversion de protocoles, le splitting de signal, la surveillance de la qualité, la gestion des canaux audio, la logique de basculement et le contrôle en temps réel — le tout simultanément sur des dizaines ou des centaines de flux.

Si vous avez déjà travaillé avec des routeurs vidéo physiques dans un centre de diffusion — ces équipements avec des entrées SDI d’un côté et des sorties SDI de l’autre — le routage de flux en direct en est l’équivalent IP. Mais au lieu de patcher des câbles sur une matrice physique, vous configurez des routes logicielles capables de convertir entre protocoles, de dupliquer des signaux sans matériel supplémentaire, et d’être gérées à distance via API.

Le routage est la couche fondamentale de toute infrastructure vidéo. Toutes les autres fonctionnalités — basculement, transcodage, distribution, supervision — reposent sur le moteur de routage. Maîtrisez le routage, et tout le reste suit.

Anatomie d’une route

Dans Vajra Cast, chaque route comporte trois composants :

Entrée (Source)

D’où provient la vidéo. Une entrée peut être :

• SRT Listener: ouvre un port et attend une connexion SRT entrante
• SRT Caller: initie une connexion SRT sortante vers une source distante
• SRTLA: entrée SRT agrégée pour le transport cellulaire/multi-chemin (compatible BELABOX)
• RTMP: reçoit un push RTMP depuis des encodeurs (OBS, vMix, encodeurs matériels)
• HTTP/TS: récupère un flux MPEG-TS depuis une URL
• UDP: reçoit un flux UDP unicast depuis une source sur le réseau local

Chaque entrée est configurée indépendamment avec ses propres paramètres protocolaires : réglages de chiffrement pour SRT, buffer de latence, clé de flux pour RTMP, etc.

Traitement (optionnel)

Ce qui se passe entre l’entrée et la sortie. Le traitement comprend :

• Transcodage: changer de codec (H.264 vers H.265), de résolution (1080p vers 720p) ou de débit. Vajra Cast supporte l’accélération matérielle Intel QSV et VAAPI pour le transcodage en temps réel sans surcharge CPU.
• Routage audio: remapper les canaux audio, convertir le 5.1 en stéréo, extraire des canaux spécifiques, appliquer un contrôle de gain. La matrice audio offre un contrôle par canal.
• Analyse de qualité VMAF: scoring automatique de la qualité perceptuelle sur toute route active. Analyse en un clic avec suivi historique des tendances.

Le traitement est optionnel. De nombreuses routes sont en passthrough: le signal est relayé sans modification, ce qui ne nécessite quasiment aucun CPU. Vajra Cast gère le routage passthrough avec moins de 50 ms de latence ajoutée.

Sortie (Destination)

Où va la vidéo. Une sortie peut être :

• SRT (Listener ou Caller): push vers des serveurs SRT en aval, avec chiffrement AES
• SRTLA: sortie SRT agrégée vers des récepteurs distants
• RTMP: push vers YouTube Live, Twitch, Facebook Live, ou tout endpoint RTMP
• HTTP/TS: serveur HTTP intégré pour la lecture directe dans VLC, ffplay ou les lecteurs web
• UDP: unicast vers des destinations réseau
• HLS: streaming à débit adaptatif avec durée de segment configurable et compteur de spectateurs en direct intégré

Une seule route peut avoir plusieurs sorties. C’est là que la distribution zero-copy devient essentielle.

Distribution zero-copy : une entrée, des sorties illimitées

Le besoin de routage le plus courant est le one-to-many : prendre une seule entrée et l’envoyer vers de multiples destinations simultanément. Un flux sportif va sur YouTube, Twitch, Facebook, un CDN et un enregistrement local — le tout en même temps.

L’approche naïve consiste à décoder l’entrée une fois par sortie, puis ré-encoder et envoyer. Cela augmente linéairement avec le CPU : 5 sorties signifient 5 fois le traitement. A 10 sorties, la plupart des serveurs sont submergés.

Vajra Cast résout ce problème avec la distribution zero-copy. En interne, les données du flux d’entrée sont lues une seule fois en mémoire, et chaque sortie lit depuis ce même buffer mémoire. Il n’y a pas de décodage ou de copie par sortie. Ajouter une seconde sortie coûte le même CPU que la première : effectivement zéro pour les routes passthrough.

                    ┌→ SRT Push (CDN 1)
                    ├→ SRT Push (CDN 2)
SRT Input → Buffer  ├→ RTMP Push (YouTube)
                    ├→ RTMP Push (Twitch)
                    ├→ HLS (lecteur web)
                    └→ HTTP/TS (monitoring VLC)

Cette architecture signifie que vous pouvez router une entrée vers 50 destinations sur un serveur modeste. Le goulot d’étranglement devient la bande passante réseau, pas le CPU.

Avantages clés :

• Aucune surcharge CPU par sortie additionnelle
• Chaque sortie peut utiliser un protocole différent (SRT, RTMP, HLS, UDP)
• Les sorties peuvent être ajoutées, supprimées ou reconfigurées pendant que le flux est en cours (gestion à chaud)
• Chaque sortie bénéficie d’une surveillance de santé indépendante

Pour en savoir plus sur la gestion du basculement avec de multiples entrées par Vajra Cast, consultez Basculement de flux vidéo : guide complet.

Conversion de protocoles

L’infrastructure vidéo du monde réel utilise rarement un seul protocole de bout en bout. Les encodeurs envoient en SRT. Les plateformes sociales acceptent le RTMP. Les lecteurs web ont besoin de HLS. Les stations de monitoring récupèrent du HTTP/TS. Un routeur de flux doit convertir entre tous ces protocoles de manière transparente.

Vajra Cast effectue la conversion de protocoles au niveau de la couche de routage. Tout protocole d’entrée peut être routé vers tout protocole de sortie :

La conversion de protocoles en mode passthrough (sans transcodage) ajoute une latence minimale — typiquement moins de 50 ms. Le signal est remuxé (réemballé) dans le format conteneur du protocole cible sans toucher au codec vidéo ou audio.

Lorsque le transcodage est nécessaire (par exemple, convertir une entrée H.265 en sortie H.264 pour la compatibilité RTMP), Vajra Cast utilise l’accélération matérielle Intel QSV ou VAAPI. Cela maintient une utilisation CPU faible même lors de la conversion de codec.

Pour une comparaison détaillée des caractéristiques des protocoles SRT et RTMP, consultez SRT vs RTMP : Quel protocole choisir ?. Si vous envisagez de moderniser votre infrastructure existante, notre guide sur la migration de RTMP vers SRT vous accompagne étape par étape.

La vue diagramme : gestion visuelle des routes

Gérer des routes dans une liste ou un tableau fonctionne bien pour une poignée de flux. Mais quand vous avez 20, 30 ou plus de 50 routes, il faut une représentation visuelle de votre flux de signaux.

Vajra Cast inclut une vue diagramme interactive construite avec React Flow. Chaque route est affichée sous forme de graphe visuel :

• Noeuds d’entrée à gauche — un par source, coloré par protocole
• Noeuds de traitement au centre — transcodage, routage audio, logique de basculement
• Noeuds de sortie à droite — un par destination, coloré par protocole
• Lignes de connexion entre les noeuds, avec des indicateurs de statut en temps réel

Le diagramme n’est pas une image statique. C’est un outil interactif en direct :

• Glisser-déposer pour réorganiser la disposition
• Cliquer sur n’importe quel noeud pour voir la configuration détaillée et les métriques en direct (débit, perte de paquets, état de connexion)
• Overlay en temps réel montrant les données transitant par chaque connexion — vert pour sain, jaune pour dégradé, rouge pour en panne
• Scalabilité confortable jusqu’à plus de 50 routes sans dégradation de performance

Pour les opérateurs gérant une infrastructure complexe, la vue diagramme fournit une conscience situationnelle immédiate. Au lieu de défiler dans un tableau à la recherche de la route en panne, vous repérez instantanément le noeud rouge dans le graphe visuel.

Routage par matrice audio

Le routage vidéo retient toute l’attention, mais le routage audio est tout aussi critique — et souvent plus complexe. Un signal vidéo peut transporter 2, 6 ou 8 canaux audio, et les besoins en sortie correspondent rarement à l’entrée.

Scénarios courants de routage audio :

• Conversion 5.1 vers stéréo pour les sorties plateformes sociales qui n’acceptent que 2 canaux audio
• Extraction d’une paire de canaux spécifique (par exemple, commentaires sur les canaux 3-4) pour une sortie particulière
• Mixage de plusieurs sources audio en une seule sortie (par exemple, ambiance du lieu + commentaires + lit musical)
• Application d’un gain par canal pour équilibrer les niveaux entre sources
• Routage du son surround 7.1 vers un flux broadcast tout en envoyant un downmix stéréo vers les sorties web

Pour une exploration détaillée des techniques de routage audio en diffusion directe, consultez notre article sur le routage audio en diffusion direct.

La matrice audio de Vajra Cast offre un contrôle par canal sur chaque route :

Canaux d'entrée :       Canaux de sortie :
┌─────────────────┐     ┌──────────────────┐
│ Ch 1 (Gauche)   │────→│ Ch 1 (Gauche)    │  Sortie stéréo
│ Ch 2 (Droite)   │────→│ Ch 2 (Droite)    │
│ Ch 3 (Comm.)    │     └──────────────────┘
│ Ch 4 (Comm.)    │
│ Ch 5 (LFE)      │     ┌──────────────────┐
│ Ch 6 (Surr.)    │     │ Ch 1 (Comm.)     │  Commentaires uniquement
│ Ch 7 (Surr.)    │     │ Ch 2 (Comm.)     │
│ Ch 8 (Musique)  │     └──────────────────┘
└─────────────────┘

Chaque sortie d’une route peut avoir son propre mappage de canaux audio. Le même signal vidéo peut alimenter une sortie avec du 5.1 complet et une autre avec un mix stéréo commentaires uniquement.

API REST : gestion programmatique des routes

La gestion manuelle des routes convient pour les petits déploiements. Mais quand votre infrastructure gère des dizaines de routes, s’intègre avec des systèmes de planification ou doit répondre à des événements externes, l’automatisation est indispensable.

Vajra Cast fournit une API REST complète avec des opérations CRUD (Create, Read, Update, Delete) sur chaque objet :

Création d’une route via API

curl -X POST https://votre-vajracast:8080/api/routes \
  -H "Authorization: Bearer VOTRE_TOKEN_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "sports-main",
    "input": {
      "type": "srt-listener",
      "port": 9000,
      "latency": 500,
      "encryption": "aes-256",
      "passphrase": "VotrePassphraseSecurisee"
    },
    "outputs": [
      {
        "type": "rtmp",
        "url": "rtmp://a.rtmp.youtube.com/live2",
        "key": "votre-cle-de-flux"
      },
      {
        "type": "srt-caller",
        "host": "serveur-backup.example.com",
        "port": 9001,
        "latency": 200
      }
    ]
  }'

Lister toutes les routes

curl -X GET https://votre-vajracast:8080/api/routes \
  -H "Authorization: Bearer VOTRE_TOKEN_JWT"

Modifier une sortie (gestion à chaud)

curl -X PATCH https://votre-vajracast:8080/api/routes/sports-main/outputs/1 \
  -H "Authorization: Bearer VOTRE_TOKEN_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": false
  }'

Cela désactive la sortie sans affecter les autres sorties de la même route. Le flux continue vers toutes les autres destinations.

Authentification API

L’API utilise l’authentification JWT (JSON Web Token). Les tokens sont générés via l’interface web ou via un endpoint de login. Tous les appels API sont journalisés dans la piste d’audit pour la conformité et le dépannage.

Cas d’usage de l’API

• Intégration de planification: créer et détruire automatiquement des routes en fonction d’un calendrier d’événements
• Intégration monitoring: récupérer les métriques en temps réel depuis l’API et les injecter dans votre pile de supervision existante
• Reprise après sinistre: scripter la recréation de toutes les routes sur un serveur de secours
• Plateformes multi-tenant: provisionner des routes par programme pour les clients
• CI/CD pour l’infrastructure: versionner vos configurations de routes et les appliquer automatiquement au déploiement

L’API est entièrement documentée avec des spécifications OpenAPI (Swagger), ce qui permet de générer des bibliothèques client dans n’importe quel langage.

Architectures de routage : patterns pour la production

Pattern 1 : ingestion et distribution simple

Le pattern le plus courant. Un encodeur envoie vers Vajra Cast, qui distribue vers de multiples plateformes :

OBS/vMix → RTMP → Vajra Cast → RTMP → YouTube
                              → RTMP → Twitch
                              → RTMP → Facebook
                              → HLS  → Lecteur web
                              → SRT  → Serveur d'enregistrement

Cela remplace le besoin de multiples sorties d’encodeur ou d’un service de restreaming séparé. Vajra Cast gère le fan-out avec une efficacité zero-copy. Pour savoir comment configurer un tel workflow de diffusion multi-destinations, consultez notre guide sur le streaming multi-destinations.

Pattern 2 : hub de production multi-sources

De multiples sources alimentent Vajra Cast, qui route chacune vers sa destination appropriée :

Caméra 1 (SRT)      → Vajra Cast → SRT → Mélangeur de production
Caméra 2 (SRT)      → Vajra Cast → SRT → Mélangeur de production
Commentaires (SRT)   → Vajra Cast → SRT → Mélangeur de production
Habillage (RTMP)     → Vajra Cast → SRT → Mélangeur de production

Chaque source a sa propre route avec basculement, supervision et conversion de protocoles indépendants. Le mélangeur de production reçoit tous les flux en SRT, quel que soit le protocole source original.

Pattern 3 : réseau de contribution et distribution

Une architecture en couches où les instances Vajra Cast remplissent des rôles différents :

Lieu A → SRT → Vajra Cast (Edge) → SRT → Vajra Cast (Core) → CDN
Lieu B → SRT → Vajra Cast (Edge) → SRT ↗                    → Archive
Lieu C → SRT → Vajra Cast (Edge) → SRT ↗                    → Réseaux sociaux

Les instances edge gèrent l’ingestion, le basculement local et la normalisation des protocoles. L’instance core agrège tous les flux et gère la distribution. Cette architecture scale horizontalement — ajoutez des instances edge au fur et à mesure que vous ajoutez des lieux.

Pattern 4 : monitoring et contrôle qualité

Routez une copie (tap) de chaque flux de production vers une sortie de monitoring :

Route de production : SRT Input → SRT Output (CDN)
                                → HTTP/TS Output (monitoring QC dans VLC)
                                → Analyse VMAF (scoring qualité)

Les sorties de monitoring utilisent le même mécanisme zero-copy, donc ajouter des taps QC ne coûte aucun CPU. Les opérateurs peuvent regarder n’importe quel flux dans VLC en récupérant l’URL HTTP/TS, et les scores VMAF fournissent une mesure de qualité objective sans évaluation humaine subjective.

Gestion à chaud : modifier les routes sans interruption

Dans un environnement de production en direct, la configuration n’est jamais statique. Des sorties doivent être ajoutées, supprimées, activées ou désactivées en réponse aux besoins opérationnels en temps réel. Vajra Cast supporte la gestion à chaud: toutes les modifications de route s’effectuent sans interrompre les flux en cours.

Opérations réalisables en direct :

• Ajouter une sortie à une route existante (par exemple, démarrer le streaming vers une nouvelle plateforme en cours d’événement)
• Supprimer une sortie (par exemple, arrêter le flux Facebook tout en conservant YouTube)
• Activer/désactiver une sortie temporairement (par exemple, mettre en pause l’enregistrement sans supprimer la configuration)
• Modifier les paramètres de sortie (par exemple, changer la clé de flux RTMP pour une nouvelle diffusion YouTube)
• Ajouter une nouvelle entrée à la chaîne de basculement (par exemple, connecter un encodeur de secours qui vient de se mettre en ligne)
• Réordonner les priorités de basculement (par exemple, promouvoir la source de secours en source principale)

Aucune de ces opérations ne nécessite un redémarrage. Aucune n’affecte les autres routes ou sorties de la même route. Le changement prend effet immédiatement.

C’est une différence fondamentale avec les systèmes qui nécessitent un rechargement de configuration ou un redémarrage de processus pour appliquer les changements. En production en direct, un redémarrage signifie un temps d’arrêt, et un temps d’arrêt signifie un échec.

Pour une plongée approfondie dans les capacités de gestion à chaud de Vajra Cast — incluant les opérations supportées, les détails de l’architecture interne, les scénarios pratiques et le suivi des modifications — consultez Gestion à chaud : Modifier les flux live sans interruption.

Superviser vos routes

Chaque route dans Vajra Cast expose des métriques en temps réel :

Métriques par entrée

• Etat de connexion (connecté/déconnecté/en cours de connexion)
• Débit (actuel, moyen, crête)
• Taux de perte de paquets (pour SRT/UDP)
• RTT et gigue (pour SRT)
• Erreurs de compteur de continuité (MPEG-TS)

Métriques par sortie

• Etat de connexion
• Débit (envoyé)
• Taux de retransmission (pour SRT)
• Profondeur de file d’attente (utilisation du buffer de sortie)
• Frames perdues (si la sortie ne peut pas suivre)

Métriques au niveau de la route

• Entrée active (quelle source alimente actuellement la sortie)
• Nombre d’événements de basculement
• Uptime (temps depuis le dernier redémarrage de la route)
• Score de qualité VMAF (si l’analyse est activée)

Toutes les métriques sont accessibles via le tableau de bord web, l’API REST et l’endpoint Prometheus /metrics. Pour les détails d’intégration Grafana et les tableaux de bord préconfigurés, consultez Logiciel de streaming broadcast : infrastructure vidéo professionnelle.

Dimensionner votre infrastructure de routage

Dimensionnement matériel

Vajra Cast est léger. La capacité de routage dépend de si vous faites du passthrough ou du transcodage :

Le routage passthrough utilise un minimum de CPU car les données du flux ne sont jamais décodées — elles sont remuxées et retransmises. Le transcodage est l’opération qui exige de la puissance de calcul, et l’accélération matérielle (Intel QSV ou VAAPI) décharge ce travail du CPU vers le GPU.

Considérations réseau

• Bande passante : Prévoyez 1,5 fois votre débit agrégé pour les retransmissions SRT et le surcoût protocolaire
• Ports : Chaque listener SRT nécessite son propre port UDP. Planifiez vos plages de ports en conséquence (par exemple, 9000-9099 pour 100 entrées SRT)
• Pare-feu : SRT utilise UDP. Assurez-vous que votre pare-feu autorise l’UDP entrant sur vos ports listener
• DNS : Utilisez des noms DNS pour les destinations SRT caller afin de permettre le basculement au niveau DNS

Déploiement avec Docker et Kubernetes

Vajra Cast fonctionne comme un conteneur Docker léger, ce qui facilite le déploiement sur n’importe quelle infrastructure :

docker run -d \
  --name vajracast \
  -p 8080:8080 \
  -p 9000-9099:9000-9099/udp \
  -v /data/vajracast:/data \
  vajracast/vajracast:latest

Pour les déploiements multi-instances, l’orchestration Kubernetes avec PostgreSQL comme store d’état partagé permet la scalabilité horizontale. Des modules Terraform sont disponibles pour le provisionnement infrastructure-as-code.

Prochaines étapes

• Basculement de flux vidéo — configurer le basculement automatique pour chaque route
• Passerelle de streaming SRT — plongée technique dans la configuration du protocole SRT
• Logiciel de streaming broadcast — comparer Vajra Cast avec les solutions alternatives
• SRT vs RTMP — comprendre les compromis protocolaires pour vos décisions de routage
• Guide de configuration SRT — tutoriel pas à pas pour configurer SRT