Guide de configuration SRT Streaming : du zéro à la production

Pourquoi SRT ?

SRT (Secure Reliable Transport) est devenu le protocole de référence pour le transport vidéo professionnel sur internet. Que vous acheminiez de la vidéo entre deux sites (au sein d’une même ville ou d’un continent à l’autre), SRT vous offre une fiabilité, un chiffrement et une observabilité que RTMP ne peut tout simplement pas égaler.

Ce guide vous accompagne dans la mise en place de SRT depuis zéro.

Comprendre les modes de connexion SRT

SRT dispose de deux modes de connexion. Les comprendre est indispensable avant toute configuration.

Mode Listener (serveur)

Le listener ouvre un port et attend les connexions entrantes. Considérez-le comme le côté “serveur” de la connexion.

SRT Listener : srt://votre-serveur:9000?mode=listener

Utilisez le mode listener lorsque :

• Vous opérez une passerelle ou un serveur centralisé
• Vous devez accepter des flux provenant de sources multiples
• Votre serveur dispose d’une IP publique ou se trouve derrière un pare-feu correctement configuré

Mode Caller (client)

Le caller initie la connexion vers un listener. C’est le côté “client” de la connexion.

SRT Caller : srt://serveur-distant:9000?mode=caller

Utilisez le mode caller lorsque :

• Vous êtes un encodeur qui envoie un flux vers un serveur
• Vous êtes derrière un NAT et ne pouvez pas recevoir de connexions entrantes
• Vous devez pousser un flux vers une destination spécifique

Étape 1 : choisir vos ports

SRT utilise UDP, vous devez donc ouvrir les bons ports sur votre pare-feu. La convention est la suivante :

• Port 9000+ pour les listeners SRT
• Un port par listener (chaque session SRT nécessite son propre port, sauf en cas d’utilisation d’identifiants de connexion)

Assurez-vous que vos règles de pare-feu autorisent le UDP entrant sur les ports choisis.

Étape 2 : configurer la latence

La fonctionnalité clé de SRT est sa latence ajustable. Le paramètre latency (en millisecondes) contrôle la taille du tampon pour la récupération d’erreurs :

Règle d’or : configurez la latence à au moins 4 fois votre temps d’aller-retour (RTT). Cela donne à SRT un tampon suffisant pour demander les retransmissions.

srt://serveur:9000?latency=500

Étape 3 : activer le chiffrement

SRT prend en charge le chiffrement AES-128 et AES-256. Activez-le systématiquement lors d’une diffusion sur internet.

srt://serveur:9000?passphrase=VotrePassphraseSecurisee&pbkeylen=32

• passphrase : minimum 10 caractères, maximum 79
• pbkeylen : 16 pour AES-128, 24 pour AES-192, 32 pour AES-256

Les deux côtés (listener et caller) doivent utiliser la même passphrase et la même longueur de clé.

Étape 4 : configurer avec Vajra Cast

Vajra Cast simplifie la configuration SRT :

1. Créez un Ingest : Choisissez SRT Listener, sélectionnez un port, définissez votre latence
2. Activez le chiffrement : Saisissez une passphrase dans les paramètres de sécurité
3. Pointez votre encodeur : Configurez OBS, vMix ou tout encodeur compatible SRT en mode caller vers l’adresse de votre instance Vajra Cast
4. Supervisez : Observez les métriques en temps réel : débit, perte de paquets, RTT, gigue

L’ensemble du processus prend environ 2 minutes.

Étape 5 : optimiser les performances

Une fois votre flux opérationnel, affinez ces paramètres :

Bande passante maximale

Définissez maxbw pour limiter la surcharge de bande passante :

srt://serveur:9000?maxbw=10000000

Cela plafonne la bande passante totale (retransmissions incluses) à 10 Mbps.

Bande passante de surcharge

Le paramètre oheadbw (en pourcentage) contrôle la bande passante supplémentaire que SRT peut utiliser pour les retransmissions :

srt://serveur:9000?oheadbw=25

La valeur par défaut est 25 %. Augmentez-la sur les réseaux à pertes élevées, diminuez-la sur les réseaux stables.

Délai de connexion

Définissez connect_timeout en mode caller pour contrôler le temps d’attente de SRT avant abandon :

srt://serveur:9000?connect_timeout=3000

Supervision de votre flux

SRT fournit des statistiques riches en temps réel. Les métriques clés à surveiller :

• RTT (Round Trip Time) — doit rester stable ; les pics indiquent des problèmes réseau
• Taux de perte de paquets — en dessous de 1 % c’est correct ; SRT peut gérer jusqu’à 30 % avec une latence suffisante
• Paquets retransmis — une valeur non nulle est normale ; surveillez les valeurs élevées soutenues
• Bande passante disponible — SRT estime la bande passante disponible sur le chemin réseau

Dans Vajra Cast, toutes ces métriques sont visibles dans le tableau de bord en temps réel, sans aucune configuration nécessaire.

Pièges courants

1. Latence trop faible — provoque des artefacts lorsque SRT ne peut pas récupérer les paquets à temps. En cas de doute, augmentez la valeur.
2. Pare-feu bloquant l’UDP — SRT utilise UDP, pas TCP. Vérifiez que vos règles de pare-feu sont correctes.
3. Passphrases non concordantes — les connexions échouent silencieusement si les paramètres de chiffrement ne correspondent pas des deux côtés.
4. Oubli de définir caller/listener — les deux côtés doivent s’accorder sur leurs rôles respectifs.

Prochaines étapes

Maintenant que SRT fonctionne :

• Configurez un basculement automatique avec une entrée de secours
• Mettez en place une sortie multi-destination pour distribuer votre flux
• Consultez le bonding SRTLA pour la production mobile sur réseaux cellulaires

Toutes ces fonctionnalités sont intégrées à Vajra Cast et configurables depuis l’interface web.