SRTLA vs SRT vs RTMP : quel protocole choisir pour le streaming IRL ?

Pour le streaming IRL, SRT est généralement mieux adapté que RTMP, et SRTLA est la meilleure option quand tu peux envoyer ton flux sur plusieurs connexions en même temps. RTMP reste nécessaire, car les plateformes de streaming l'attendent, mais il a sa place sur le dernier tronçon stable entre un serveur et la plateforme, pas sur un réseau mobile.

Ce guide explique comment fonctionnent les trois protocoles, comment ils se comportent sur les connexions cellulaires et comment régler correctement la latence SRT.

Qu'est-ce que RTMP ?

RTMP (Real-Time Messaging Protocol) a été spécifié par Adobe et publié comme spécification ouverte en 2009. Il est conçu pour fonctionner sur un transport fiable comme TCP, qui garantit que tous les messages arrivent dans l'ordre (spécification RTMP). Le brouillon IETF consacré à SRT qualifie RTMP de standard de fait pour la contribution sur l'internet public, ce qui explique pourquoi pratiquement tous les encodeurs, applications et plateformes le comprennent.

Le point faible vient de la même conception. Comme RTMP repose sur TCP, il n'offre une fiabilité acceptable que sur des connexions avec un faible temps d'aller-retour, et le contrôle de congestion de TCP l'empêche d'exploiter toute la bande passante d'une connexion. C'est mal adapté à un téléphone qui passe d'une antenne-relais à l'autre.

Le RTMP classique a aussi des limites côté codecs : il ne prend en charge que deux canaux audio et un ensemble restreint de codecs, sans HEVC, VP9 ni AV1. La spécification Enhanced RTMP ajoute ces codecs, et YouTube indique désormais H.264, H.265 et AV1 pour RTMP(S). Il faut toutefois que ton logiciel et la plateforme le prennent tous les deux en charge. RTMPS, c'est RTMP dans une connexion SSL chiffrée, et YouTube le recommande justement pour cette raison.

Qu'est-ce que SRT ?

SRT (Secure Reliable Transport) est un protocole open source développé dans le dépôt GitHub public de Haivision et décrit dans un Internet-Draft de l'IETF. Il fonctionne sur UDP et ajoute la fiabilité qui manque à UDP seul. La méthode principale est l'ARQ (Automatic Repeat reQuest) : quand le récepteur remarque qu'un paquet manque, il demande à l'émetteur de le renvoyer. Le protocole prend aussi en charge la Forward Error Correction et son propre bonding de connexions.

Trois propriétés comptent pour le streaming IRL :

• Tampon de latence : Le récepteur retient chaque paquet pendant une durée configurée avant de le transmettre. Cette fenêtre laisse aux paquets perdus le temps d'être retransmis et reproduit le rythme d'origine du flux. Les paquets qui arrivent trop tard peuvent être abandonnés, de sorte que le délai reste constant au lieu d'augmenter.
• Chiffrement : SRT prend en charge le chiffrement AES avec des clés de 128, 192 ou 256 bits.
• Indépendance vis-à-vis du codec : SRT est agnostique au contenu transporté. Il transporte n'importe quel codec, résolution ou fréquence d'images, HEVC compris.

Le compromis est inhérent au protocole. Le tampon ajoute volontairement du délai, tu dois donc choisir une valeur de latence adaptée à ton réseau (plus de détails ci-dessous).

Qu'est-ce que SRTLA ?

SRTLA est un proxy de transport SRT avec agrégation de liens. Il provient du projet BELABOX et transporte le trafic SRT sur plusieurs liens réseau pour gagner en capacité et en redondance. Le trafic est réparti dynamiquement selon l'état du réseau, et l'usage prévu est l'agrégation de modems mobiles pour la diffusion en direct.

SRTLA ne remplace pas SRT. Il se place entre l'émetteur et le récepteur SRT : ton appareil envoie le flux SRT, par exemple, via deux cartes SIM ou une SIM plus le Wi-Fi, et un récepteur qui comprend SRTLA réassemble les paquets et les transmet comme un flux SRT normal. Trois conséquences pratiques en découlent :

• Il te faut un émetteur compatible SRTLA. L'application iOS gratuite Moblin, par exemple, peut utiliser en même temps une connexion cellulaire, une connexion Wi-Fi et plusieurs connexions Ethernet. IRL Pro et les appareils BELABOX proposent eux aussi le bonding SRTLA.
• Il te faut un récepteur SRTLA. Une plateforme de streaming ou un simple listener SRT ne sait pas faire ça, donc un serveur avec entrée SRTLA doit s'intercaler entre les deux.
• Il faut le régler. Les paquets arrivent dans le désordre sur les différents liens. Le README exige donc des options côté récepteur comme lossmaxttl et une latence adaptée.

RTMP vs SRT vs SRTLA en un coup d'œil

Pourquoi les plateformes veulent du RTMP et pourquoi un serveur s'intercale

La documentation encodeur des grandes plateformes tourne encore autour de RTMP. YouTube indique RTMP/RTMPS comme protocole d'encodeur (HLS est l'alternative), et la documentation développeur de Twitch décrit l'envoi du flux vers Twitch via RTMP. Dans la plupart des cas, tu ne peux donc pas pointer SRT et SRTLA directement vers une plateforme.

Un serveur résout ce problème et apporte un second avantage. La chaîne se présente ainsi :

1. Ton téléphone ou ton encodeur envoie du SRT ou du SRTLA (ou du RTMP) vers un serveur.
2. Ton logiciel de streaming, comme OBS Studio, récupère le flux depuis ce serveur.
3. OBS envoie le flux final à la plateforme via RTMP(S), sur une connexion stable.

Le tronçon mobile fragile utilise le protocole le plus tolérant, et la plateforme reçoit le protocole qu'elle attend sur une connexion qui ne bouge pas. Si le signal mobile coupe brièvement, OBS continue de streamer vers la plateforme, donc le stream ne s'arrête pas pour tes spectateurs. Ton encodeur et OBS initient tous les deux la connexion vers le serveur, tu n'as donc pas besoin d'ouvrir de ports sur ton routeur.

C'est ce que fait notre IRL Endpoint Server pour toi, avec OBS sur ton propre PC. Il accepte RTMP, SRT et SRTLA en entrée. Si tu n'as pas de PC de streaming, l'IRL Broadcasting Server exécute OBS Studio dans le cloud et accepte les mêmes trois entrées. Pour une vue d'ensemble d'une configuration IRL, consulte notre guide du streaming IRL.

Comment régler la latence SRT

La latence SRT n'est pas le délai total entre la caméra et le spectateur. Dans la documentation de Haivision, elle ne décrit que le délai introduit par l'envoi sur le réseau. L'encodage, le décodage, OBS et la plateforme s'y ajoutent. Ce que le réglage définit vraiment, c'est le temps supplémentaire que le récepteur attend pour compenser les paquets en retard et les retransmissions.

La base de connaissances d'OBS donne une règle empirique pour l'option la plus importante :

• La valeur par défaut est de 120 ms.
• La valeur doit être d'au moins 2,5 fois le temps d'aller-retour entre l'encodeur et le serveur, en millisecondes.
• Dans une URL de style FFmpeg, qu'utilise OBS, l'unité est la microseconde. Une latence de 1 seconde s'écrit latency=1000000.

Exemple : si un ping vers ton serveur indique un temps d'aller-retour de 80 ms, la règle donne un minimum de 200 ms, donc tu saisirais srt://SERVER:PORT?latency=200000. Utilise l'adresse et le port exacts de ton portail client. Dans OBS, ces options peuvent être ajoutées à l'URL SRT d'une source média ou d'une destination de stream personnalisée.

Pour les streams vers nos serveurs, nous recommandons une latence de 2 secondes. Selon l'application, tu la saisis sous la forme 2000 (millisecondes) ou 2000000 (microsecondes). La plupart des applications ont un champ dédié. Sinon, ajoute-la à l'URL SRT, par exemple srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. Une valeur plus basse est possible, mais nous recommandons volontairement 2 secondes pour privilégier la stabilité.

Quelques points à garder en tête :

• Les unités diffèrent. La bibliothèque SRT et le README de SRTLA utilisent des millisecondes, alors que les URL de style FFmpeg utilisent des microsecondes. Vérifie quelle unité ton application attend avant de saisir une valeur.
• Les deux côtés négocient. Selon le draft SRT, la latence d'une connexion est le maximum des valeurs proposées par l'émetteur et le récepteur. La baisser d'un côté ne sert à rien si l'autre côté en demande plus.
• Le mobile et les flux en bonding demandent de la marge. La règle ci-dessus est un minimum, pas une recommandation. Une fenêtre plus large laisse plus de temps à la retransmission et au réordonnancement, mais ajoute aussi du délai. Le README de SRTLA, par exemple, utilise latency=2000 (ms) avec lossmaxttl dans son exemple de configuration de récepteur.
• Change une seule chose à la fois et teste en te déplaçant, pas seulement à ton bureau.

Emplacement du serveur et latence

Comme la latence SRT minimale évolue avec le temps d'aller-retour, la distance compte. Un serveur plus proche de toi a un temps d'aller-retour plus court : tu peux donc utiliser une fenêtre de latence plus petite ou obtenir la même stabilité avec moins de délai. La même logique vaut pour le dernier tronçon : Twitch, par exemple, recommande des points d'ingest en fonction du chemin réseau vers ton appareil.

Nous proposons des serveurs dans les régions suivantes : États-Unis, Europe, Asie et Amérique du Sud. Avec l'IRL Endpoint Server, tu peux choisir parmi elles avec l'offre standard et en changer à tout moment dans le portail client, ce qui aide quand tu voyages. Avec l'offre Dedicated, nous configurons un endpoint pour toi, par défaut à l'emplacement le plus proche de ton adresse de facturation.

Quel protocole utiliser ?

• Une connexion, application moderne : utilise SRT et règle la latence en fonction de ton temps d'aller-retour.
• Deux connexions ou plus : utilise SRTLA, si ton application le prend en charge et que ton serveur l'accepte.
• Application ou caméra qui ne gère que RTMP : utilise RTMP. Ça fonctionne, mais il tolère moins bien les réseaux faibles.
• HEVC : SRT est indépendant du codec. Vérifie que toute ta chaîne, de l'encodeur à OBS puis à la plateforme, le prend en charge. Règle l'intervalle d'images clés de ton encodeur sur 2 secondes et, avec HEVC sur les appareils Apple, désactive les B-frames si ton application le permet.

FAQ

SRT est-il meilleur que RTMP pour le streaming IRL ?

Pour le tronçon mobile, généralement oui. SRT fonctionne sur UDP et retransmet les paquets perdus dans une fenêtre de latence configurable, alors que RTMP repose sur TCP et ne reste fiable que sur des connexions avec un faible temps d'aller-retour. RTMP reste le choix courant pour la connexion entre un serveur ou OBS et la plateforme.

Quelle est la différence entre SRT et SRTLA ?

SRT est le protocole de transport pour une seule connexion. SRTLA transporte le trafic SRT sur plusieurs liens réseau à la fois, par exemple deux cartes SIM, pour ajouter de la capacité et de la redondance. SRTLA demande une application compatible SRTLA et un récepteur qui le comprend.

Puis-je streamer en SRT directement vers Twitch ou YouTube ?

La documentation encodeur des deux plateformes se concentre sur RTMP(S), avec HLS comme alternative sur YouTube. Si tu veux utiliser SRT ou SRTLA sur le tronçon mobile, place un serveur et OBS entre ton appareil et la plateforme.

Quelle latence régler pour SRT ?

Pour les streams vers nos serveurs, nous recommandons 2 secondes, saisies sous la forme 2000 (millisecondes) ou 2000000 (microsecondes) selon l'application. Une valeur plus basse est possible, mais 2 secondes est un choix délibéré en faveur de la stabilité. En règle générale, la base de connaissances d'OBS indique au moins 2,5 fois le temps d'aller-retour vers ton serveur, avec 120 ms par défaut. Les réseaux mobiles et les connexions en bonding demandent généralement plus de marge, au prix d'un délai plus important.

L'IRL Endpoint Server prend-il en charge les trois protocoles ?

Oui. L'IRL Endpoint Server et l'IRL Broadcasting Server acceptent RTMP, SRT et SRTLA en entrée.