Streaming d'événements live : Infrastructure fiable pour concerts et conférences
Construisez une infrastructure de streaming d'événements live fiable avec failover automatique, sortie multi-destinations et déploiement temporaire.
Le défi des événements live
Les événements en direct ne pardonnent pas. Un concert, une keynote de conférence, un match sportif, un lancement de produit — cela n’arrive qu’une fois. Il n’y a pas de deuxième prise. La connexion internet sur le lieu peut être peu fiable. L’équipe technique installe peut-être l’infrastructure le matin même pour la démonter le soir. Et chaque minute d’indisponibilité est visible par chaque spectateur.
L’infrastructure de streaming événementiel doit être fiable (elle ne doit pas tomber pendant l’événement), flexible (les besoins changent jusqu’au dernier moment) et déployable (elle doit fonctionner dans des lieux que vous n’avez jamais visités, sur des réseaux que vous ne contrôlez pas).
La connectivité internet sur les lieux d’événements
La variable la plus importante du streaming d’événements live est le réseau. Le Wi-Fi d’un centre de conférences n’est pas comparable à une ligne fibre dédiée. Un festival de musique en plein champ n’a aucune infrastructure filaire.
Le problème
- L’internet du lieu est souvent partagé, congestionné et imprévisible
- Le Wi-Fi introduit du jitter et de la perte de paquets
- Les réseaux cellulaires saturent quand des milliers de participants se connectent simultanément
- Les connexions filaires peuvent ne pas exister à l’emplacement précis dont vous avez besoin dans le lieu
La solution : SRT et SRTLA
SRT a été conçu exactement pour ces conditions. Son tampon de latence configurable et sa correction d’erreur ARQ gèrent la perte de paquets avec élégance. Pour les pires conditions réseau, le bonding SRTLA agrège plusieurs connexions (deux cartes SIM cellulaires, un hotspot Wi-Fi, un backup filaire) en un seul flux fiable.
Une configuration de connectivité événementielle typique :
BELABOX / Encodeur mobile
--> 4G SIM 1 (Opérateur A) --|
--> 4G SIM 2 (Opérateur B) --|-- SRTLA bonding --> Vajra Cast (cloud)
--> Wi-Fi du lieu --|
--> Ethernet USB (si disponible) --|
Si une connexion individuelle tombe, les autres prennent la charge. Avec trois ou quatre connexions en bonding, vous pouvez maintenir un streaming HD fiable même dans des environnements RF difficiles.
Architecture de failover pour les événements
Pour un événement en direct, le failover n’est pas optionnel. C’est le fondement de votre architecture de streaming.
Failover d’entrée
Configurez votre route Vajra Cast avec plusieurs entrées redondantes :
Route : "Scène Principale"
Principale : SRT depuis l'encodeur principal (plateau, sur site)
Secours 1 : SRT depuis l'encodeur de secours (plateau, réseau différent)
Secours 2 : SRTLA depuis l'encodeur mobile (bonding cellulaire)
Secours 3 : HTTP/TS pull depuis un relais cloud (si pré-positionné)
Vajra Cast surveille toutes les entrées simultanément et bascule en moins de 50 ms quand l’entrée active se dégrade. Les critères de basculement sont configurables :
- Seuil de perte de paquets : basculer quand la perte dépasse un pourcentage
- Débit minimum : basculer quand le débit descend sous un minimum
- Timeout de connexion : basculer quand la source se déconnecte complètement
Quand l’entrée principale revient, Vajra Cast rebascule automatiquement (avec un timer de maintien configurable pour éviter les oscillations entre sources instables).
Pour un guide complet de configuration du failover, consultez notre article bonnes pratiques de failover vidéo.
Redondance de sortie
Côté sortie, envoyez votre flux vers plusieurs destinations :
Vajra Cast --> SRT vers l'origine CDN principale
--> SRT vers l'origine CDN de secours
--> RTMP vers YouTube Live (backup)
--> Enregistrement HLS local (archivage)
Si votre CDN principal a un problème, le CDN de secours a le même flux. Si les deux CDN tombent, le flux YouTube sert de dernier recours. Et l’enregistrement local garantit que vous avez toujours une archive.
Distribution multi-destinations
Les événements live doivent souvent atteindre plusieurs plateformes simultanément :
- Conférence corporate : site de l’entreprise, portails partenaires, réseau interne
- Concert : plateforme de billetterie, réseaux sociaux, partenaire de diffusion
- Événement sportif : plateforme OTT, diffuseurs régionaux, clips réseaux sociaux
Avec la distribution zero-copy de Vajra Cast, ajouter des destinations ne coûte aucun CPU. Une entrée peut alimenter 50+ sorties avec le même overhead qu’une seule. Cela rend économiquement viable l’ajout de destinations spéculatives (un réseau social qui « pourrait vouloir le flux ») sans se soucier de l’impact sur les ressources.
Ajouter des destinations pendant l’événement
C’est là que la gestion à chaud devient critique. Pendant un événement live :
- Un sponsor demande son propre flux 10 minutes avant le début
- Un réseau social est ajouté en cours d’événement
- Un CDN partenaire doit être remplacé à cause de problèmes de latence
- Une sortie de test doit être supprimée pour nettoyer le tableau de bord
Tous ces changements s’effectuent en direct, avec zéro interruption pour les sorties existantes. Pas de redémarrage, pas de rechargement de config, pas de souffle retenu.
Déploiement d’infrastructure temporaire
Les événements sont temporaires. Votre infrastructure de streaming doit se déployer rapidement et se démonter proprement.
Déploiement Docker
Vajra Cast s’exécute dans Docker, rendant le déploiement événementiel reproductible :
docker run -d \
--name vajracast \
-p 9000-9010:9000-9010/udp \
-p 1935:1935 \
-p 8080:8080 \
vajracast/vajracast:latest
Apportez la même configuration à chaque lieu. Utilisez Docker Compose ou des manifests Kubernetes pour les configurations complexes avec plusieurs instances.
Hybride Cloud + Site
Une architecture événementielle courante combine un encodeur sur site avec une passerelle côté cloud :
Sur site :
Caméras --> Encodeur --> SRT (chiffré) --> Internet
Cloud :
Vajra Cast (instance cloud)
--> Reçoit le SRT du site
--> Distribue vers CDN, plateformes, partenaires
--> Fournit le failover entre les flux du site
--> Exécute le tableau de bord de supervision accessible de partout
Cette architecture déplace la complexité du routage vers le cloud, où vous avez une connectivité et des ressources de calcul fiables. Le côté site n’a besoin que d’un encodeur et d’une connexion internet (n’importe quelle connexion — SRT gère le reste).
Tests pré-événement
Avant l’événement, validez toute votre chaîne :
- Envoyez des flux de test depuis l’encodeur du site vers le Vajra Cast cloud
- Vérifiez que toutes les sorties reçoivent correctement
- Testez le failover en coupant délibérément l’entrée principale
- Vérifiez la latence bout en bout de l’encodeur au spectateur
- Surveillez les statistiques SRT pour comprendre les caractéristiques réseau du lieu
- Lancez une analyse VMAF pour vérifier la qualité vidéo à travers la chaîne
Le tableau de bord de Vajra Cast rend tout cela visible en temps réel depuis n’importe quel navigateur.
Opérations le jour J
Avant l’événement
- Vérifier que toutes les connexions d’entrée sont actives et stables
- Confirmer que toutes les destinations de sortie sont connectées
- Vérifier que le failover est armé (entrées de secours prêtes)
- Configurer les alertes Grafana pour les conditions critiques
- Briefer l’équipe d’exploitation sur le tableau de bord et les procédures de reprise manuelle
Pendant l’événement
- Surveiller le tableau de bord pour toute dégradation de qualité d’entrée
- Guetter les événements de failover (ils devraient être automatiques, mais la vigilance compte)
- Être prêt à ajouter ou supprimer des sorties à chaud selon l’évolution des besoins
- Suivre les compteurs de spectateurs sur les sorties HLS
Après l’événement
- Revoir les logs d’événements de failover (des basculements ont-ils eu lieu ? Pourquoi ?)
- Vérifier les métriques de qualité (scores VMAF tout au long de l’événement)
- Exporter les statistiques pour le rapport post-événement
- Arrêter les routes et démonter l’infrastructure
Scaling pour les grands événements
Pour les grands événements avec plusieurs scènes ou plusieurs sessions simultanées :
Configuration multi-scènes
Scène A --> Route "Scène A" --> CDN / Plateformes
Scène B --> Route "Scène B" --> CDN / Plateformes
Scène C --> Route "Scène C" --> CDN / Plateformes
Chaque scène a sa propre route dans Vajra Cast avec failover, supervision et destinations de sortie indépendants.
Déploiement haute disponibilité
Pour les événements critiques, déployez deux instances Vajra Cast dans des zones de disponibilité différentes :
Encodeur --> SRT --> Vajra Cast (Principal, Région A) --> CDN
--> SRT --> Vajra Cast (Secours, Région B) --> CDN
Le failover d’origine CDN bascule entre les deux instances Vajra Cast si l’une tombe. Cela fournit une redondance au niveau infrastructure au-delà du failover au niveau flux au sein de chaque instance.
Prochaines étapes
- Découvrez les workflows de diffusion live pour les modèles de production studio
- Explorez la production à distance avec le bonding SRTLA
- Consultez le Guide de la passerelle de streaming SRT pour les détails complets de l’architecture
- Apprenez à configurer la latence SRT pour les conditions réseau de votre lieu
- Configurez la sortie HLS pour la diffusion web vers votre audience