Protocole SRT : Transport sécurisé et fiable pour la vidéo en direct

Qu’est-ce que SRT ?

SRT (Secure Reliable Transport) est un protocole de transport vidéo open source développé par Haivision et diffusé à la communauté open source en 2017 via la SRT Alliance. Il a été conçu avec un objectif unique : transporter de la vidéo en direct de manière fiable sur des réseaux imprévisibles. Contrairement aux protocoles basés sur TCP qui bloquent lorsque des paquets sont perdus, SRT utilise UDP avec un mécanisme de retransmission sélective appelé ARQ (Automatic Repeat reQuest) qui ne récupère que les paquets manquants, maintenant une latence faible et des flux propres.

SRT est rapidement devenu le standard pour les flux de contribution professionnels, la production à distance et le transport vidéo point à point. Il est pris en charge par des centaines de produits, des encodeurs matériels comme le Haivision Makito et le Teradek aux plateformes logicielles comme OBS Studio, vMix et Vajra Cast.

Modes de connexion SRT

SRT définit trois modes de connexion. Le choix du bon mode détermine comment deux points de terminaison établissent leur session.

Mode Caller (appelant)

Le caller initie la connexion vers un listener distant. C’est le mode le plus courant pour les encodeurs envoyant de la vidéo vers un serveur.

srt://server.example.com:9000?mode=caller

Utilisez le mode caller quand :

• Votre encodeur est derrière un NAT et ne peut pas accepter les connexions entrantes
• Vous envoyez un flux vers une passerelle centralisée ou un serveur cloud
• Vous voulez que la source contrôle le démarrage de la connexion

Dans Vajra Cast, vous configurez un ingest caller lorsque vous devez tirer un flux d’une source SRT distante, ou une sortie caller lorsque vous devez pousser un flux vers un listener SRT en aval.

Mode Listener (écouteur)

Le listener ouvre un port UDP et attend les connexions caller entrantes. C’est le mode côté serveur.

srt://0.0.0.0:9000?mode=listener

Utilisez le mode listener quand :

• Vous exploitez un serveur d’ingest centralisé (comme Vajra Cast) qui accepte des flux d’encodeurs distants
• Votre serveur a une adresse IP publique ou un transfert de port correctement configuré
• Vous devez accepter plusieurs flux entrants sur différents ports

Vajra Cast fonctionne principalement en mode listener pour l’ingest, ouvrant un port SRT dédié pour chaque entrée. Chaque listener peut être configuré indépendamment avec ses propres paramètres de latence, chiffrement et identifiant de flux.

Mode Rendezvous

Le mode rendezvous permet à deux points de terminaison de se connecter sans qu’aucun des deux ne joue le rôle de serveur permanent. Les deux côtés tentent de se connecter mutuellement simultanément, et le handshake SRT détermine la direction du flux de données.

srt://remote-peer:9000?mode=rendezvous

Le rendezvous est utile quand :

• Les deux points de terminaison sont derrière un NAT et aucun ne peut accepter les connexions entrantes
• Vous avez besoin d’une connectivité pair-à-pair sans serveur relais
• Vous construisez un workflow de contribution symétrique

En pratique, le mode rendezvous est moins courant en environnement de production car il nécessite une coordination précise du timing et que les deux côtés connaissent l’adresse IP de l’autre. La plupart des workflows professionnels utilisent le modèle caller/listener avec une passerelle centralisée comme Vajra Cast.

Chiffrement SRT

L’un des avantages les plus significatifs de SRT par rapport au RTMP est le chiffrement intégré. SRT utilise AES (Advanced Encryption Standard) au niveau du transport, ce qui signifie que chaque charge utile de paquet est chiffrée avant de quitter l’émetteur.

Comment ça fonctionne

1. Les deux points de terminaison partagent une phrase de passe (10-79 caractères)
2. Pendant le handshake, le listener génère un sel aléatoire
3. Les deux côtés dérivrent la clé AES à partir de la phrase de passe et du sel via PBKDF2
4. Toutes les données vidéo/audio sont chiffrées avec la clé dérivée
5. Les en-têtes SRT restent non chiffrés (nécessaire pour le routage et la retransmission des paquets)
6. Les clés sont périodiquement renégociées pour la confidentialité persistante (forward secrecy)

Longueurs de clé

SRT prend en charge trois longueurs de clé AES :

Sur tout matériel équipé d’AES-NI (pratiquement tous les processeurs x86 modernes), le chiffrement n’a pas d’impact mesurable sur les performances. Utilisez AES-256 pour tout, sauf si vous avez une raison spécifique de ne pas le faire. Pour un guide complet de la configuration du chiffrement, consultez notre guide de configuration du chiffrement SRT.

Configuration de la phrase de passe

srt://server:9000?passphrase=MyS3cur3P@ssphr4se&pbkeylen=32

Les deux côtés doivent utiliser exactement la même phrase de passe et la même longueur de clé. Une discordance provoque un échec de connexion silencieux sans message d’erreur, ce qui est une source courante de confusion lors de la configuration initiale.

Correction d’erreurs avec ARQ

Le mécanisme de correction d’erreurs de SRT est ce qui le distingue du streaming UDP brut. Lorsqu’un récepteur détecte un paquet manquant (via des lacunes dans les numéros de séquence), il envoie immédiatement un NAK (Negative Acknowledgment) à l’émetteur pour demander la retransmission. L’émetteur ne retransmet que les paquets spécifiquement manquants.

Ce processus est régi par le paramètre latency :

srt://server:9000?latency=500

La valeur de latence (en millisecondes) définit le tampon de réception. C’est la fenêtre de temps dont SRT dispose pour détecter la perte, demander la retransmission et recevoir le paquet récupéré avant que le décodeur n’en ait besoin. La formule pour choisir la bonne valeur :

Latence >= 4 x RTT + 2 x Gigue

Où RTT est le temps aller-retour entre les points de terminaison et Gigue est la variance du RTT. Sur une connexion nationale stable avec un RTT de 30ms, une latence de 200-500ms fonctionne bien. Pour les liaisons satellite ou cellulaires, vous pourriez avoir besoin de 1500-4000ms. Consultez notre guide détaillé d’optimisation de la latence SRT pour les valeurs recommandées selon différents scénarios réseau.

Que se passe-t-il quand la latence est trop basse

Si le tampon de latence est trop petit pour les conditions réseau, SRT ne peut pas récupérer les paquets à temps. Le résultat est une perte de paquets non récupérés, qui se manifeste par des artefacts visuels (macroblocs, glitches) ou des coupures audio. Vajra Cast signale ceux-ci comme des paquets perdus dans le tableau de bord des flux en temps réel.

Que se passe-t-il quand la latence est trop élevée

Un excès de latence ajoute simplement un délai inutile à votre flux. Cela compte dans les scénarios interactifs (interviews, Q&A en direct) mais est moins critique pour la diffusion unidirectionnelle. En cas de doute, commencez haut et réduisez progressivement.

Bande passante de surcharge SRT

SRT réserve un pourcentage de bande passante pour les retransmissions. Le paramètre oheadbw contrôle cela :

srt://server:9000?oheadbw=25

La valeur par défaut est 25%, ce qui signifie que si votre flux est à 10 Mbps, SRT autorisera jusqu’à 12,5 Mbps au total pour accommoder les retransmissions. Sur les réseaux à pertes (cellulaire, Wi-Fi), augmentez à 50% ou plus. Sur des liaisons dédiées propres, vous pouvez réduire à 10-15%.

Statistiques et surveillance SRT

SRT expose un ensemble riche de statistiques en temps réel via son API :

• RTT (Round Trip Time) — valeurs actuelles et lissées
• Taux de perte de paquets — pourcentage de paquets perdus avant récupération
• Taux de retransmission — paquets retransmis par seconde
• Bande passante disponible — capacité estimée du chemin
• Niveau du tampon — quelle proportion du tampon de latence est utilisée
• État du chiffrement — confirme que l’AES est actif

Vajra Cast expose toutes ces métriques par flux dans le tableau de bord web et les rend disponibles via le endpoint Prometheus /metrics pour l’intégration avec Grafana ou d’autres outils de surveillance. Cette observabilité est l’un des avantages les plus forts de SRT par rapport au RTMP, qui ne fournit pratiquement aucun diagnostic au niveau du transport.

SRT dans l’architecture Vajra Cast

Vajra Cast utilise SRT comme protocole de transport principal. L’architecture en trois étapes (Ingest, Traitement, Redistribution) exploite SRT aux étapes d’entrée et de sortie :

• Ingest : des listeners SRT acceptent les flux entrants des encodeurs, avec chiffrement et paramètres de latence par entrée
• Redistribution : des sorties SRT caller poussent les flux vers les serveurs en aval, les CDN ou d’autres instances Vajra Cast

Entre les étapes, Vajra Cast utilise le multicast interne zéro-copie, ce qui signifie que l’ajout de sorties SRT supplémentaires ne coûte aucune surcharge CPU. Vous pouvez router une entrée vers 50 sorties SRT avec la même utilisation de ressources qu’une seule.

Pour les workflows impliquant des équipements anciens, Vajra Cast fait le pont entre SRT et le RTMP ainsi que le HLS, vous permettant de recevoir dans un protocole et de distribuer dans un autre sans conversion manuelle.

Prochaines étapes

• Retournez au Guide de la passerelle de streaming SRT pour une vue d’ensemble complète de l’architecture
• Découvrez la configuration du chiffrement SRT pour une configuration détaillée des phrases de passe
• Optimisez votre réseau avec l’optimisation de la latence SRT
• Lisez notre article de blog sur SRT vs RTMP pour une comparaison des protocoles