Conversion RTMP vers SRT : Pont protocolaire pour systèmes anciens

Comment convertir des flux RTMP en SRT pour un transport moderne. Reliez vos encodeurs anciens à l'infrastructure SRT avec Vajra Cast.

Le problème de l’héritage RTMP

Le RTMP (Real-Time Messaging Protocol) a été l’épine dorsale de l’ingest de streaming en direct pendant plus de quinze ans. Pratiquement chaque encodeur, chaque plateforme de streaming et chaque workflow de diffusion parle RTMP. Il fonctionne, il est compris, et une énorme base installée de matériel et de logiciels en dépend.

Mais le RTMP a été conçu pour une autre époque. Il utilise TCP, ce qui signifie que toute perte de paquet déclenche un blocage en tête de file et un gel du flux. Il n’a pas de chiffrement intégré (RTMPS ajoute un wrapper TLS, mais tous les appareils ne le prennent pas en charge). Il ne fournit aucun diagnostic au niveau du transport. Et Adobe, le gestionnaire du protocole, l’a effectivement abandonné.

Pendant ce temps, SRT offre tout ce que le RTMP n’a pas : chiffrement AES natif, transport basé sur UDP avec retransmission sélective, tampons de latence configurables et statistiques riches en temps réel. Le problème est que des milliers d’encodeurs, de caméras et d’outils de workflow ne parlent encore que le RTMP.

La solution est un pont protocolaire.

Comment fonctionne le pontage de protocoles

Un pont protocolaire accepte un flux dans un protocole et le republie dans un autre. Pour la conversion RTMP vers SRT, le pont :

  1. Reçoit le flux RTMP entrant (TCP, port 1935)
  2. Démultiplexe le conteneur RTMP pour extraire les flux élémentaires vidéo H.264/HEVC et audio AAC/Opus bruts
  3. Remultiplexe ces flux en MPEG-TS (le format conteneur utilisé par SRT)
  4. Transmet via SRT avec chiffrement, paramètres de latence et correction d’erreurs

C’est une opération de passthrough. Les codecs vidéo et audio ne sont pas réencodés, il n’y a donc aucune perte de qualité et une utilisation CPU minimale. Le pont ne change que le format de transport et de conteneur.

Vajra Cast comme pont RTMP vers SRT

Vajra Cast dispose d’un ingest RTMP natif via son intégration nginx-rtmp intégrée. Cela signifie que vous pouvez recevoir des flux RTMP directement sans logiciel supplémentaire.

Configuration de l’ingest RTMP

  1. Dans l’interface web de Vajra Cast, créez une nouvelle route
  2. Ajoutez une entrée RTMP avec une clé de flux (par ex. live/monflux)
  3. Vajra Cast provisionne automatiquement le endpoint nginx-rtmp
  4. Pointez votre encodeur vers rtmp://votre-serveur/live/monflux

Vajra Cast gère la configuration nginx-rtmp de manière dynamique. Lorsque vous créez un ingest RTMP, il crée l’application nginx et la clé de flux correspondantes. Lorsque vous le supprimez, la configuration est nettoyée. Aucune modification manuelle de nginx.conf requise.

Routage du RTMP vers la sortie SRT

Une fois le flux RTMP ingéré, vous pouvez ajouter n’importe quel nombre de sorties SRT :

  1. Sur la même route, ajoutez une sortie SRT (mode caller)
  2. Définissez l’adresse et le port de destination
  3. Configurez le chiffrement (phrase de passe, AES-256)
  4. Définissez la latence pour les conditions réseau cibles

Le flux est désormais ponté : votre encodeur RTMP ancien envoie à Vajra Cast, qui convertit et pousse via SRT vers le serveur en aval avec chiffrement complet et correction d’erreurs.

Exemple de configuration

Une route de pontage RTMP vers SRT typique dans Vajra Cast :

Route : "Pont Caméra Studio"

Entrée :
  Protocole : RTMP
  Clé de flux : live/studio-cam-1
  Endpoint : rtmp://passerelle.exemple.com/live/studio-cam-1

Sortie 1 :
  Protocole : SRT (Caller)
  Destination : srt://serveur-production:9000
  Phrase de passe : [phrase de passe AES-256]
  Latence : 200ms

Sortie 2 :
  Protocole : SRT (Caller)
  Destination : srt://serveur-backup:9001
  Phrase de passe : [phrase de passe AES-256]
  Latence : 500ms

Dans cet exemple, une seule entrée RTMP est distribuée vers deux destinations SRT (principale et secours) avec des paramètres de chiffrement et de latence indépendants. Grâce à la distribution zéro-copie de Vajra Cast, la deuxième sortie n’ajoute aucune surcharge CPU supplémentaire.

SRT vers RTMP : le pont inverse

La conversion fonctionne aussi dans l’autre sens. De nombreuses plateformes de streaming (YouTube Live, Twitch, Facebook Live) nécessitent encore un ingest RTMP. Avec Vajra Cast, vous pouvez :

  1. Recevoir en SRT depuis votre réseau de production (chiffré, résilient)
  2. Diffuser en RTMP vers chaque plateforme de streaming

Cela vous offre les avantages du SRT pour votre transport interne tout en maintenant la compatibilité avec toutes les principales plateformes.

Route : "Distribution Réseaux Sociaux"

Entrée :
  Protocole : SRT (Listener)
  Port : 9000
  Chiffrement : AES-256

Sortie 1 :
  Protocole : RTMP
  Destination : rtmp://a.rtmp.youtube.com/live2/[cle-de-flux]

Sortie 2 :
  Protocole : RTMP
  Destination : rtmp://live.twitch.tv/app/[cle-de-flux]

Sortie 3 :
  Protocole : RTMP
  Destination : rtmps://live-api-s.facebook.com:443/rtmp/[cle-de-flux]

Détails de l’intégration nginx-rtmp

L’ingest RTMP de Vajra Cast est propulsé par nginx-rtmp, un module éprouvé qui gère les connexions RTMP à grande échelle. L’intégration offre :

  • Création dynamique d’applications — de nouveaux endpoints RTMP sont provisionnés automatiquement lorsque vous créez des routes dans l’interface ou via l’API REST
  • Gestion des clés de flux — chaque ingest RTMP a une clé de flux unique qui sert à la fois d’identifiant et de mécanisme d’authentification de base
  • Reconnexion fiable — si l’encodeur RTMP se déconnecte et se reconnecte (courant avec OBS, vMix et Wirecast), Vajra Cast reprend la nouvelle connexion de manière transparente
  • Flux simultanés multiples — chaque ingest RTMP est indépendant ; vous pouvez exécuter des dizaines d’entrées RTMP simultanément

Sécuriser l’ingest RTMP

Le RTMP lui-même n’a pas de chiffrement (le protocole est antérieur à l’adoption généralisée du TLS). Pour sécuriser votre ingest RTMP :

  1. Utilisez RTMPS si possible — certains encodeurs prennent en charge le RTMP sur TLS. Vajra Cast peut terminer les connexions RTMPS.
  2. Utilisez des clés de flux uniques — traitez les clés de flux comme des mots de passe. Changez-les entre les événements.
  3. Restreignez par IP — si votre encodeur a une IP statique, configurez les règles de pare-feu pour n’accepter le RTMP que depuis les sources connues.
  4. Pontez vers SRT immédiatement — l’approche la plus sécurisée est de garder le RTMP en local (même réseau ou localhost) et d’utiliser SRT avec AES-256 pour tout transport sur internet.

Pourquoi ne pas simplement utiliser le RTMP partout ?

Si le RTMP fonctionne pour votre encodeur, pourquoi ajouter la complexité de la conversion de protocole ? Plusieurs raisons :

Résilience réseau

Le RTMP utilise TCP. Un seul paquet perdu provoque la retransmission de toute la fenêtre TCP, et pendant la récupération, les nouveaux paquets s’empilent derrière le paquet perdu (blocage en tête de file). Sur un réseau à pertes, cela crée des saccades visibles et de la mise en mémoire tampon. La retransmission sélective basée sur UDP de SRT ne récupère que le paquet manquant sans bloquer le reste du flux.

Chiffrement

Le RTMP natif n’est pas chiffré. Toute personne ayant accès au chemin réseau peut capturer et visualiser votre flux. Le RTMPS (TLS) ajoute du chiffrement mais tous les encodeurs matériels ne le prennent pas en charge. Le chiffrement AES-256 de SRT est intégré au protocole et pris en charge par chaque appareil compatible SRT.

Diagnostics

Le RTMP ne fournit pratiquement aucune métrique au niveau du transport. Si votre flux rencontre des problèmes, vous déboguez à l’aveugle. SRT expose le RTT, la gigue, le taux de perte de paquets, le nombre de retransmissions et les estimations de bande passante en temps réel. Vajra Cast affiche tout cela dans le tableau de bord et via les métriques Prometheus.

Traversée de pare-feu

Le RTMP utilise le port TCP 1935, que certains pare-feux d’entreprise bloquent. SRT utilise UDP sur des ports configurables et, en mode caller, initie des connexions sortantes qui fonctionnent avec la plupart des configurations NAT.

Stratégie de migration : RTMP vers SRT

Pour les organisations disposant d’une infrastructure RTMP significative, la migration vers SRT n’a pas besoin de se faire du jour au lendemain. Une approche progressive :

Phase 1 : Pontage à la passerelle

Déployez Vajra Cast comme pont RTMP vers SRT. Gardez vos encodeurs existants envoyant en RTMP. Vajra Cast convertit en SRT pour tout le transport en aval. Cela ne nécessite aucune modification de votre matériel d’encodage.

Phase 2 : Mise à jour progressive des encodeurs

À mesure que les encodeurs sont remplacés ou mis à jour, configurez les nouveaux pour envoyer directement en SRT. Vajra Cast accepte les deux protocoles simultanément, vous pouvez donc mélanger les entrées RTMP et SRT sur la même route avec un basculement automatique.

Phase 3 : SRT de bout en bout

Une fois que tous les encodeurs prennent en charge SRT, vous pouvez progressivement supprimer l’ingest RTMP. Conservez les sorties RTMP pour la compatibilité avec les plateformes (YouTube, Twitch), mais toute votre colonne vertébrale de contribution et de distribution fonctionne sur SRT.

Prochaines étapes

← Retour au guide principal