Faire remonter un direct depuis un lieu de tournage, un studio délocalisé ou le domicile d’un invité ne passe plus forcément par un satellite ou une ligne dédiée : la plupart du temps, le flux transite par Internet, et deux protocoles se partagent le terrain, RTMP et SRT. On les retrouve dans les encodeurs matériels, dans les logiciels de production, dans les boîtiers de contribution cellulaire. Choisir l’un ou l’autre n’est pas qu’une case à cocher : cela décide de la robustesse de votre liaison, du retard à l’antenne et, pour qui s’occupe du son, de la qualité et de la synchronisation de l’audio. Faisons le tri.
RTMP : le vétéran du streaming
RTMP (Real-Time Messaging Protocol) est né à l’époque de Flash, à la fin des années 2000. Conçu pour acheminer de l’audio et de la vidéo sur Internet, il est devenu le format d’entrée universel des grandes plateformes : pendant des années, « streamer », c’était pousser un flux RTMP vers l’ingest d’un service de diffusion. Il reste aujourd’hui le plus petit dénominateur commun : à peu près tout encodeur sait émettre en RTMP, et à peu près toute plateforme sait le recevoir.
Techniquement, RTMP s’appuie sur TCP, le protocole de transport qui garantit que chaque paquet arrive, dans l’ordre, quitte à retransmettre ce qui s’est perdu. Sur un réseau propre et stable, c’est parfait. Le problème surgit dès que la liaison se dégrade : sur une connexion instable, les retransmissions TCP font gonfler la latence, le flux bufferise, puis se fige. RTMP n’a aucun mécanisme pensé pour absorber les pertes d’un réseau capricieux ; il subit. Côté formats, il est aussi vieillissant : il reste cantonné à des codecs anciens comme le H.264 en vidéo et l’AAC en audio, sans ouverture vers les codecs plus récents.
SRT : la contribution pensée pour un Internet imparfait
SRT (Secure Reliable Transport) est beaucoup plus récent et répond précisément à ce que RTMP ne sait pas faire : transporter un direct de qualité broadcast sur un réseau qu’on ne maîtrise pas, 4G/5G comprise. Il repose sur UDP, mais ajoute par-dessus une couche de fiabilisation intelligente. Plutôt que de tout retransmettre aveuglément comme TCP, il récupère sélectivement les paquets perdus dans une fenêtre de temps définie, et abandonne ceux qui arriveraient de toute façon trop tard pour être utiles.
Le coeur de SRT, c’est la notion de latence de tampon réglable. L’opérateur fixe un budget de retard, typiquement quelques centaines de millisecondes. Dans cette fenêtre, SRT a le temps de redemander et de réinsérer les paquets manquants, ce qui lisse les pertes et les gigues du réseau. On échange donc un peu de retard contre beaucoup de robustesse : un flux qui, en RTMP, se serait figé tient en SRT, au prix d’une latence maîtrisée et choisie. SRT est par ailleurs agnostique en codecs (il transporte ce que vous lui donnez, y compris des codecs modernes) et chiffre nativement le flux, un atout pour la contribution de contenus sensibles.
Le tableau qui résume
| Critère | RTMP | SRT |
|---|---|---|
| Transport | TCP (retransmission intégrale) | UDP + fiabilisation sélective |
| Comportement réseau instable | bufferise puis se fige | absorbe pertes et gigue dans la fenêtre de latence |
| Latence | faible sur réseau propre, imprévisible sinon | réglable et stable (budget choisi) |
| Codecs | figés (H.264 / AAC) | agnostique, codecs modernes possibles |
| Chiffrement | non natif | natif (AES) |
| Compatibilité plateformes | universelle en diffusion finale | surtout en contribution, moins en diffusion grand public |
Lequel pour quel usage ?
Les deux ne s’opposent pas vraiment : ils occupent souvent deux maillons différents de la même chaîne.
- Contribution, remontée terrain, duplex d’invité sur 4G/5G : SRT, sans hésiter. C’est exactement le scénario pour lequel il a été conçu, là où le réseau est incertain et où la stabilité prime.
- Diffusion finale vers une plateforme grand public : RTMP reste souvent le point d’entrée imposé, parce que c’est ce que la plateforme accepte. Beaucoup de workflows remontent donc en SRT jusqu’à un point de production fiable, puis repartent en RTMP vers la plateforme.
- Liaison point à point entre deux régies : SRT, pour sa robustesse et son chiffrement.
Pour qui travaille le son, deux points méritent l’attention. D’abord, la latence : un budget SRT généreux fiabilise mais retarde, ce qui complique un échange en direct entre un plateau et un invité distant. C’est le même arbitrage que pour tout retour à distance, et la logique du transport audio-vidéo sur IP s’applique ici. Ensuite, la synchronisation lèvres/son et le respect des cibles de loudness à la sortie, qui restent de votre responsabilité quel que soit le protocole de transport. Car SRT comme RTMP ne font que porter un flux déjà encodé : ils ne remplacent ni un bon mix-minus pour l’invité, ni une chaîne de contribution propre.
Et par rapport aux autres transports ?
SRT et RTMP vivent sur l’Internet public et visent la contribution à distance et le streaming. Ils ne jouent pas dans la même cour que les transports internes d’une installation : le réseau Dante d’un studio, pensé pour un LAN maîtrisé et une latence minuscule, ou la liaison studio-émetteur qui relie la régie à l’émetteur. Chacun son terrain : on ne contribue pas un direct distant en Dante, et on ne câble pas un studio en SRT. De même, pour acheminer un programme radio codé à faible débit, on reste sur des chaînes dédiées et des codecs spécialisés. SRT et RTMP sont les outils de la remontée et de la diffusion sur Internet, ni plus, ni moins.
Mon avis
Entre les deux, le match est plié pour la contribution : SRT fait ce que RTMP ne sait pas, tenir un direct sur un réseau qui bouge. Ce réglage de latence qu’on choisit soi-même change la vie quand on remonte un plateau en 5G, loin du satellite et de son coût. RTMP n’est pas mort pour autant : il reste la porte d’entrée des plateformes, le dernier maillon imposé. Le bon réflexe n’est donc pas de choisir un camp, mais de savoir lequel va où dans la chaîne. Et de ne jamais oublier que le protocole porte le son sans jamais le soigner : ça, ça reste votre travail, en amont.
