Migration RTMP vers SRT : guide complet étape par étape

Pourquoi migrer de RTMP vers SRT ?

RTMP est le protocole d’ingest par défaut du streaming en direct depuis l’ère Flash. Il fonctionne. Il est supporté partout. Mais il a été conçu pour un internet différent — un internet avec des connexions fiables et à faible latence entre des points connus. Ce n’est pas l’internet sur lequel la plupart d’entre nous diffusent aujourd’hui.

SRT (Secure Reliable Transport) a été conçu de zéro pour les réseaux non fiables. Il utilise UDP au lieu de TCP, implémente une retransmission sélective (ARQ) au lieu d’une retransmission intégrale, et intègre nativement le chiffrement AES dans le protocole. Si vous utilisez encore RTMP pour vos flux de contribution, la production à distance ou toute transmission passant par internet, vous laissez des gains de performance et de sécurité sur la table.

Voici ce que vous gagnez en migrant :

• Chiffrement natif — AES-128 ou AES-256, intégré au protocole. Pas de surcouche TLS, pas de gestion de certificats, pas de dépendances externes.
• Latence effective réduite — le transport UDP de SRT évite le blocage en tête de file TCP. Vous pouvez ajuster la latence précisément avec le paramètre latency au lieu d’espérer que TCP se comporte bien.
• Meilleure récupération d’erreurs — l’ARQ de SRT ne retransmet que les paquets perdus, pas le flux entier. Il peut tolérer jusqu’à 30 % de perte de paquets avec un tampon de latence suffisant.
• Diagnostics en temps réel — RTT, gigue, taux de perte de paquets, compteur de retransmissions, estimation de bande passante. Le tout disponible en temps réel, par flux.
• Support du bonding — SRTLA permet d’agréger plusieurs connexions réseau (cellulaire + Wi-Fi + Ethernet) en un seul flux résilient. RTMP n’a pas d’équivalent.

La question n’est pas de savoir s’il faut migrer, mais comment le faire sans perturber vos workflows existants.

Avant de commencer : évaluez votre configuration actuelle

Avant de modifier quoi que ce soit, documentez ce que vous avez. Vous devez connaître :

1. Inventoriez vos points d’entrée RTMP

Listez chaque point d’ingest RTMP et chaque destination de sortie :

Points d'ingest :
  - rtmp://ingest1.example.com/live (encodeur principal)
  - rtmp://ingest2.example.com/live (encodeur de secours)

Destinations de sortie :
  - rtmp://a.rtmp.youtube.com/live2 (YouTube Live)
  - rtmp://live.twitch.tv/app (Twitch)
  - rtmp://recording-server.local/archive (enregistrement local)

2. Identifiez votre parc d’encodeurs

Quels encodeurs utilisez-vous ? Vérifiez leur compatibilité SRT :

Si un encodeur ne supporte pas SRT, vous devrez conserver un point d’ingest RTMP pour celui-ci et convertir en SRT au niveau de la passerelle. C’est exactement ce que gère une passerelle comme Vajra Cast — accepter le RTMP des équipements anciens et acheminer le flux en SRT en interne.

3. Vérifiez votre réseau

SRT utilise UDP. C’est le blocage le plus fréquent lors d’une migration :

• Règles de pare-feu : la plupart des pare-feu d’entreprise autorisent TCP en sortie par défaut mais bloquent UDP. Vous avez besoin de règles UDP pour vos ports SRT.
• Traversée NAT : le mode caller SRT fonctionne à travers la plupart des NAT (il initie la connexion en sortie). Le mode listener nécessite une redirection de port ou une IP publique.
• Plage de ports : la convention est le port 9000 et au-delà. Un port par listener SRT.

Effectuez un test rapide :

# Sur votre serveur (côté listener)
nc -u -l 9000

# Du côté de votre encodeur
echo "test" | nc -u votre-serveur.com 9000

Si le paquet arrive, la connectivité UDP est confirmée.

Étape 1 : configurez votre passerelle SRT

La migration la plus propre utilise une passerelle comme point de conversion central. Cela vous permet de migrer progressivement — un encodeur à la fois sans perturber les autres.

Avec Vajra Cast, créez votre premier ingest SRT :

1. Ouvrez l’interface web
2. Créez un nouvel ingest
3. Sélectionnez SRT Listener comme protocole
4. Définissez le port (par exemple 9000)
5. Configurez la latence en fonction de vos conditions réseau :

6. Activez le chiffrement — saisissez une passphrase (minimum 10 caractères) et sélectionnez AES-256
7. Enregistrez l’ingest

Votre point d’entrée SRT est maintenant actif à l’adresse srt://votre-serveur:9000.

Pour une compréhension approfondie des modes listener et caller SRT, consultez notre Guide de configuration SRT Streaming.

Étape 2 : configurez OBS pour la sortie SRT

OBS Studio est l’encodeur le plus répandu sur le terrain. Voici comment le basculer de RTMP vers SRT :

OBS 30+ (recommandé)

1. Allez dans Paramètres > Flux
2. Définissez le Service sur Personnalisé
3. Définissez le Serveur à :

srt://votre-serveur:9000?latency=500000&passphrase=VotrePassphraseSecurisee&pbkeylen=32

Note : OBS attend la latence en microsecondes, pas en millisecondes. Donc 500ms = 500000.

4. Laissez le champ Clé de flux vide (SRT n’utilise pas de clés de flux)
5. Cliquez sur Appliquer

Paramètres de sortie

Pour des performances SRT optimales dans OBS :

Mode de sortie : Avancé
Encodeur : x264 ou matériel (NVENC/QSV)
Contrôle du débit : CBR
Débit : 6000 Kbps (ajustez selon votre résolution)
Intervalle d'images clés : 2 secondes
Profil : High
Tune : zerolatency

Le CBR est important. SRT fonctionne mieux avec un débit constant car il peut prévoir les besoins en bande passante et optimiser la planification des retransmissions. Le VBR pousse SRT à surallouer la bande passante de surcharge.

Étape 3 : configurez les autres encodeurs

FFmpeg

ffmpeg -i input.mp4 \
  -c:v libx264 -b:v 6000k -g 60 -keyint_min 60 \
  -c:a aac -b:a 128k \
  -f mpegts \
  "srt://votre-serveur:9000?mode=caller&latency=500000&passphrase=VotrePassphraseSecurisee&pbkeylen=32"

Paramètres importants :

• -f mpegts — SRT transporte du MPEG-TS, pas du FLV (contrairement à RTMP)
• -g 60 -keyint_min 60 — intervalle d’images clés régulier (2 secondes à 30fps)
• mode=caller — FFmpeg initie la connexion vers votre passerelle

vMix

1. Allez dans Add Output > SRT
2. Définissez le nom d’hôte et le port
3. Définissez la latence (en millisecondes — vMix utilise les ms, pas les microsecondes)
4. Saisissez la passphrase et la longueur de clé
5. Démarrez la sortie

BELABOX

BELABOX supporte nativement SRT et SRTLA. Configurez la destination :

Protocole : SRT
Hôte : votre-serveur.com
Port : 9000
Latence : 2000 (ms)
Passphrase : VotrePassphraseSecurisee
Longueur de clé : 32 (AES-256)

Pour le bonding SRTLA (combinaison de plusieurs connexions cellulaires), consultez notre guide dédié Bonding SRTLA avec BELABOX.

Étape 4 : conservez les sorties RTMP là où c’est nécessaire

Voici le point essentiel : vous n’avez pas besoin de migrer toutes vos sorties en une seule fois. De nombreuses plateformes exigent encore l’ingest RTMP :

• YouTube Live — RTMP uniquement (en 2026)
• Twitch — RTMP principalement, SRT pas largement disponible
• Facebook Live — RTMP uniquement

Votre passerelle gère cela en acceptant le SRT côté ingest et en convertissant en RTMP côté sortie. Dans Vajra Cast :

1. Créez une sortie
2. Sélectionnez RTMP Push
3. Saisissez l’URL RTMP de la plateforme et la clé de flux
4. Liez-la à votre ingest SRT

Votre workflow ressemble maintenant à ceci :

Encodeur → SRT (chiffré) → Vajra Cast → RTMP → YouTube/Twitch
                                       → SRT  → Serveur de production
                                       → SRT  → Serveur d'enregistrement

Le chemin de contribution critique (encodeur vers passerelle) est chiffré et résilient. La livraison finale aux plateformes reste en RTMP car c’est ce qu’elles acceptent. Vous obtenez le meilleur des deux mondes.

Étape 5 : configurez le failover

L’un des principaux avantages de SRT est qu’il permet un failover plus intelligent. Comme SRT fournit des métriques de santé du flux en temps réel (perte de paquets, RTT, gigue), une passerelle peut détecter la dégradation avant qu’une défaillance complète ne survienne.

Configurez le failover dans Vajra Cast :

1. Créez votre ingest principal (SRT, port 9000)
2. Créez un ingest de secours (SRT, port 9001 — ou RTMP pour un encodeur de secours ancien)
3. Dans la configuration de route, définissez les entrées principale et de secours
4. Définissez les seuils de détection :
   • Perte de paquets : basculer à >5 % soutenu pendant 2 secondes
   • Timeout : basculer après 500ms sans données
   • Débit plancher : basculer si le débit chute en dessous de 50 % de la valeur attendue

Quand le principal se rétablit, Vajra Cast rebascule automatiquement.

Pour une analyse approfondie de l’architecture de failover, consultez Failover vidéo : bonnes pratiques.

Étape 6 : validez la migration

Avant de déclarer la migration terminée, parcourez cette liste de vérification :

Liste de vérification de la connectivité

• La connexion SRT s’établit entre l’encodeur et la passerelle
• Le chiffrement est actif (vérifiez dans les stats SRT : sndKmState: SECURED)
• La latence est dans la plage attendue (vérifiez le RTT par rapport à la latence configurée)
• Pas de perte de paquets non récupérée (des retransmissions sont normales, des pertes ne le sont pas)

Liste de vérification de la qualité

• La vidéo est propre sur toutes les sorties
• L’audio est synchronisé
• L’intervalle d’images clés est régulier (2 secondes maximum pour la compatibilité avec les plateformes)
• Le débit correspond aux paramètres de l’encodeur (vérifiez les métriques de la passerelle)

Liste de vérification du failover

• Déconnectez l’encodeur principal — le secours s’active dans le délai défini
• Reconnectez le principal — la passerelle rebascule automatiquement
• Simulez de la perte de paquets (si possible) et vérifiez la récupération SRT

Liste de vérification de la supervision

• Le tableau de bord de la passerelle affiche toutes les métriques SRT (RTT, pertes, gigue, bande passante)
• Les alertes sont configurées pour les coupures de connexion
• La journalisation capture les événements de failover avec horodatage

Test de durée

Faites tourner le workflow complet pendant au moins 4 heures en continu. Surveillez :

• Les fuites mémoire (augmentation progressive de la RAM sur la passerelle)
• La dérive du RTT (augmentation de la latence au fil du temps)
• Le comportement de reconnexion (l’encodeur se reconnecte-t-il proprement après une brève interruption réseau ?)

Problèmes courants de migration et solutions

”Connexion refusée” ou pas de connexion

Cause : le pare-feu bloque UDP. Solution : ouvrez le port UDP pour SRT. Testez d’abord avec nc -u.

Le flux se connecte mais la vidéo est corrompue

Cause : l’encodeur envoie un conteneur FLV au lieu de MPEG-TS. Solution : définissez le format de sortie sur MPEG-TS (-f mpegts dans FFmpeg). SRT ne transporte pas le FLV.

Perte de paquets élevée sur SRT malgré un bon réseau

Cause : maxbw défini trop bas, privant les retransmissions de bande passante. Solution : définissez maxbw=0 (automatique) ou augmentez à au moins 1,5 fois le débit de votre flux.

La latence est beaucoup plus élevée que la valeur configurée

Cause : le paramètre de latence est le minimum. La latence réelle inclut le délai d’encodage, le tampon de gigue réseau et le temps de décodage. Solution : c’est un comportement attendu. Le paramètre latency contrôle le tampon de réception SRT, pas la latence de bout en bout. Réduisez le délai de l’encodeur (utilisez le tune zerolatency) et le buffering côté décodage séparément.

OBS affiche “Échec de connexion”

Cause : passphrase non concordante ou latence dans la mauvaise unité. Solution : OBS utilise les microsecondes. 500ms = 500000. Vérifiez également que la passphrase correspond exactement (pas d’espaces en fin de chaîne).

Calendrier de migration

Un calendrier de migration réaliste pour une structure de taille moyenne :

Le principe clé : migrez en parallèle, pas en remplacement direct. Faites fonctionner SRT aux côtés de RTMP jusqu’à ce que vous soyez confiant, puis basculez. Vajra Cast accepte les deux protocoles simultanément, il n’y a donc pas de “jour J” à risque.

Et après la migration ?

Une fois sur SRT, de nouvelles possibilités s’ouvrent :

• Bonding SRTLA pour la production mobile — agrégation de connexions cellulaires pour un streaming extérieur fiable
• Chiffrement de bout en bout sans infrastructure de certificats
• Supervision qualité en temps réel avec des métriques par flux alimentant Prometheus et Grafana
• Failover intelligent basé sur la santé du flux, pas seulement sur la connectivité
• Réduction des coûts opérationnels — moins de coupures signifie moins d’interventions d’urgence

L’industrie du streaming se tourne vers SRT. La SRT Alliance compte désormais plus de 500 entreprises membres, et le support SRT est standard dans quasiment tous les encodeurs professionnels commercialisés depuis 2022. Migrer maintenant vous place en avance plutôt qu’en rattrapage.

Pour en savoir plus sur les raisons pour lesquelles SRT remplace RTMP dans toute l’industrie, consultez notre comparaison SRT vs RTMP.