Technique

Protocoles de transport vidéo : NDI^®, SRT, RTMP, HLS et les autres

NDI®, SRT, RTSP, RTMP, HLS, TS over UDP : ces termes ne désignent pas tous la même couche technique. Certains décrivent la manière de compresser la vidéo, d'autres la manière de l'emballer, d'autres encore la manière de la transporter ou de la demander. Ce guide pose d'abord les bases, oriente ensuite par usage, et compare seulement à la fin.

Les bases : codec, conteneur, transport

H.264, H.265

Le codec

La méthode utilisée pour compresser et relire l'image. C'est lui qui conditionne le poids du flux, la qualité, la latence et la compatibilité.

MPEG-TS

Le conteneur

L'emballage qui regroupe vidéo, audio, timecode et métadonnées dans un même flux. Le « TS » de « TS over UDP », c'est lui.

UDP, SRT, RTMP, HTTP

Le transport

La manière dont cet emballage circule sur le réseau. C'est à ce niveau que les technologies de cette page se comparent vraiment.

Une image simple aide à s'y retrouver : le codec est le contenu compressé de la lettre, le conteneur est l'enveloppe, le transport est le service d'acheminement.

Ces couches s'empilent, et c'est ce qui explique les noms composés des fiches techniques. « TS over UDP » n'est pas un protocole unique : c'est l'enveloppe MPEG-TS envoyée directement sur UDP. SRT transporte souvent une enveloppe MPEG-TS similaire, mais ajoute des mécanismes de fiabilisation, de contrôle de flux et, selon la configuration, du chiffrement. HLS change la logique : il découpe le flux en segments référencés par des playlists. Dans beaucoup de cas, le codec vidéo reste le même, par exemple H.264 ou H.265 ; ce qui change, c'est la manière d'emballer, de découper ou d'acheminer ce flux selon l'usage visé. C'est pourquoi un même encodeur peut proposer SRT, RTMP, HLS, TS over UDP et RTSP en sortie d'un seul flux H.264.

Autre repère pratique, à prendre comme une tendance plutôt qu'une règle absolue : certains modes poussent le flux vers une destination (TS over UDP, RTMP vers une plateforme), d'autres laissent le récepteur venir le chercher (HLS, RTSP). SRT, souvent utilisé en contribution point à point, gère ses modes de connexion séparément du sens du flux.

NDI® est un cas particulier : ce n'est pas seulement un mode d'acheminement vidéo, mais un écosystème complet pensé pour la production IP, principalement sur réseau local ou réseau maîtrisé.

Choisir selon le besoin

Besoin	Choix naturel	À retenir
Produire en IP sur un réseau local (caméras, régie, monitoring)	NDI®	Écosystème complet de production IP, découverte automatique des sources
Envoyer une caméra ou un programme vers une régie via Internet (contribution)	SRT	Lien vidéo fiabilisé sur réseau imparfait, chiffrement possible
Accéder au flux d'une caméra IP	RTSP	Protocole de session : le récepteur vient chercher le flux, souvent porté par RTP
Publier un direct vers une plateforme (YouTube, CDN, plateforme live)	RTMP / RTMPS	Le standard de l'ingest plateforme : une URL serveur et une clé de stream
Livrer une vidéo à des spectateurs web ou OTT	HLS	Segments servis via HTTP, échelle CDN, latence élevée
Distribuer un flux sur un réseau maîtrisé (IPTV interne, liaison dédiée)	TS over UDP	MPEG-TS envoyé directement en UDP, en unicast ou en multicast

Six technologies, six rôles

Le plus orienté production locale

NDI

NDI remplace des câbles vidéo dans un environnement réseau local. On le retrouve avec les caméras PTZ et les logiciels de production comme vMix, OBS ou TriCaster, ainsi que chez des fabricants comme BirdDog ou Kiloview. Il fait circuler vidéo, audio, tally, contrôle PTZ et métadonnées sur un même réseau. En High Bandwidth, il annonce un débit de l'ordre de 150 à 165 Mb/s en 1080p60 avec une latence très faible (souvent sous 100 ms selon le profil) ; les variantes NDI|HX s'appuient sur H.264/H.265 pour réduire fortement le débit.

Avantages

+Très faible latence, surtout en NDI High Bandwidth
+Confortable en production live sur réseau local
+Découverte automatique des sources
+Transporte vidéo, audio, alpha, tally, PTZ et métadonnées
+Écosystème très large en AV pro, PTZ et logiciels de production

Limites

-Gourmand en bande passante, surtout en High Bandwidth
-Exige un réseau propre : switches corrects, débit suffisant, idéalement VLAN dédié
-Moins adapté à Internet ou aux réseaux instables (NDI Bridge ouvre des usages inter-réseaux)
-NDI|HX réduit le débit mais ajoute de la compression et souvent de la latence
-Dépendant de l'écosystème NDI, contrairement à SRT qui est open source

Usage recommandé

Régie locale, salle de conférence, studio, plateau léger. À éviter comme solution principale de contribution longue distance sur Internet, sauf cas bien maîtrisé.

Le meilleur choix pour traverser Internet

SRT

SRT transporte un flux vidéo de façon fiable sur un réseau imparfait : Internet, 4G/5G, fibre non garantie, liaison inter-sites. Il agit au niveau transport et ne définit pas le codec vidéo : il achemine ce qu'on lui confie, souvent une enveloppe MPEG-TS en H.264 ou H.265. Open source, il est conçu pour la basse latence, la récupération des paquets perdus, la gestion du jitter, le chiffrement AES 128/256 bits et la résilience sur les réseaux imprévisibles.

Avantages

+Très bon sur Internet et les réseaux mobiles
+Bien plus robuste que RTMP sur des réseaux instables
+Chiffrement AES possible
+Latence faible, souvent sous la seconde selon le réglage
+Adapté à la contribution broadcast distante
+Multivendeur et open source

Limites

-Pas aussi « plug and play » que NDI
-Gestion des modes caller / listener / rendezvous, des ports et du firewall
-Pas de découverte automatique des sources sur un LAN
-Pas un protocole de production complet : ni tally, ni PTZ, ni discovery
-Le one-to-many demande souvent un serveur, une gateway ou un cloud intermédiaire

Usage recommandé

Envoyer une caméra, un programme ou un retour vidéo entre deux sites. Pour une liaison vidéo fiable via Internet, c'est généralement le choix le plus sérieux.

Le protocole classique des caméras IP

RTSP

RTSP sert surtout à accéder au flux d'une caméra IP. En pratique, il contrôle la session (setup, play, pause, teardown) mais ne transporte généralement pas la vidéo lui-même : le média passe souvent par RTP. Le RFC officiel le décrit comme un protocole de contrôle pour données temps réel, une forme de télécommande réseau pour serveur multimédia.

Avantages

+Très courant sur les caméras IP, NVR et systèmes de surveillance
+Compatible VLC, OBS, FFmpeg et certains media servers
+Latence faible en réseau local
+Simple pour récupérer un flux caméra : une URL du type rtsp://...

Limites

-Mauvais choix pour diffuser directement vers des viewers web
-Les navigateurs ne lisent pas RTSP nativement : repackaging vers HLS ou WebRTC souvent nécessaire
-Pénible avec les firewalls et le NAT, surtout avec RTP en UDP
-Sécurité variable selon les caméras ; beaucoup de flux mal protégés
-Moins robuste que SRT sur Internet

Usage recommandé

Accéder à une source caméra, le cas le plus courant. Pas adapté à la diffusion publique ni à la contribution fiable longue distance.

L'ancien protocole qui reste très utilisé pour l'ingest

RTMP / RTMPS

RTMP est ancien (historiquement lié à Flash) mais reste très utilisé aujourd'hui pour envoyer un flux live vers une plateforme. Il sert surtout de « first mile » : encodeur vers serveur ou encodeur vers plateforme. Le spectateur final, lui, regarde plutôt en HLS, DASH ou WebRTC. YouTube prend officiellement en charge RTMP, RTMPS, HLS et DASH pour l'ingestion live ; RTMP/RTMPS conviennent aux modes normal, low latency et ultra-low latency, tandis que HLS/DASH visent la 4K/HDR ou les codecs modernes, au prix de plus de latence.

Avantages

+Très largement compatible
+Simple à configurer : URL serveur + clé de stream
+Pris en charge par OBS, vMix, Wirecast, encodeurs hardware et plateformes live
+Bon choix pour envoyer vers YouTube, un CDN ou une plateforme événementielle
+RTMPS ajoute le chiffrement TLS

Limites

-RTMP classique n'est pas chiffré
-Principalement limité à H.264 / AAC dans les usages courants
-Basé sur TCP : en cas de perte réseau, latence ou saccades possibles
-Moins robuste que SRT sur une liaison Internet difficile
-Pas idéal pour la production locale basse latence
-Pas un protocole de lecture directe dans les navigateurs

Usage recommandé

Envoyer un programme vers une plateforme de diffusion, de préférence en RTMPS quand il est disponible. Pour relier deux régies ou une contribution critique, SRT est préférable.

La livraison aux spectateurs, à grande échelle

HLS

HLS (HTTP Live Streaming, développé par Apple) découpe le flux en petits segments référencés par des playlists (.m3u8) et servis via HTTP, comme des ressources web classiques. Lecture native ou via player web, avec une très bonne compatibilité réseau grâce à HTTP. C'est le standard de fait de la diffusion vers les spectateurs : sites web, OTT, applications mobiles.

Avantages

+Échelle énorme : les segments se distribuent via les CDN comme n'importe quel contenu web
+Traverse firewalls et proxys sans difficulté (HTTP/HTTPS)
+Débit adaptatif : la qualité s'ajuste à la connexion du spectateur
+Standard de fait de la diffusion OTT et web

Limites

-Latence élevée, souvent plusieurs dizaines de secondes en standard (réduite avec LL-HLS)
-Pas fait pour la contribution ni la production temps réel
-Logique de segments différente d'un flux continu : pas de retour direct vers la source

Usage recommandé

Diffuser vers des spectateurs, sur le web ou en OTT. HLS est d'abord pensé pour la livraison vers les lecteurs ; certains workflows peuvent aussi l'utiliser en entrée de plateforme, mais ce n'est pas son usage le plus courant en production live.

Le vétéran broadcast, brut et déterministe

TS over UDP

TS over UDP n'est pas un protocole unique : c'est l'enveloppe MPEG-TS envoyée directement sur UDP, en unicast ou en multicast. Très classique en IPTV, têtes de réseau et liaisons dédiées ; en environnement broadcast, le multicast sert souvent à distribuer un même flux vers plusieurs récepteurs. La variante RTP apporte une structure temps réel adaptée à l'audio/vidéo (horodatage, séquencement des paquets), sans garantir à elle seule la qualité de service.

Avantages

+Latence très faible et constante
+Multicast possible nativement : un flux servi à N récepteurs
+Simplicité de principe, comportement déterministe
+Omniprésent dans les équipements broadcast et IPTV

Limites

-Aucune récupération d'erreur : un paquet perdu devient un artefact à l'image
-Pas de chiffrement
-Exige un réseau maîtrisé (IGMP pour le multicast, débit garanti)
-Inadapté à Internet : SRT est précisément né pour fiabiliser ce type de flux sur les réseaux imparfaits

Usage recommandé

Distribuer un flux sur un réseau maîtrisé (IPTV interne, liaison dédiée, tête de réseau), en unicast ou en multicast. À éviter pour une contribution via Internet ouvert : c'est précisément le terrain de SRT.

Comparaison détaillée

Cette table sert à confirmer un choix déjà orienté par le besoin, pas à le découvrir.

Critère	NDI	SRT	RTSP	RTMP / RTMPS	HLS	TS over UDP
Production live locale	Excellent	Moyen	Moyen	Faible	Faible	Moyen, en distribution
Contribution via Internet	Moyen	Excellent	Faible à moyen	Moyen	Faible	À éviter sur Internet ouvert
Caméras IP	Bon si caméra NDI	Possible, moins courant	Excellent	Rare	Rare	Possible selon les modèles
Plateformes live / CDN	Rare en direct	Selon la plateforme	Rare	Excellent	Selon la plateforme	Rare
Diffusion web vers spectateurs	Inadapté	Rare	Faible	Via une plateforme (ingest)	Excellent	Réseau maîtrisé uniquement
Latence	Très faible	Faible à configurable	Très faible sur LAN	Faible à moyenne	Élevée (réduite en LL-HLS)	Très faible
Robustesse réseau instable	Moyenne	Très bonne	Faible à moyenne	Moyenne	Bonne (HTTP, CDN)	Faible
Simplicité	Très simple sur LAN	Moyenne	Simple pour caméra	Très simple	Simple côté lecture	Simple sur réseau maîtrisé
Sécurité	Variable selon config	Très bonne avec AES	Variable	Bonne en RTMPS	Bonne en HTTPS	Faible : pas de chiffrement

Ces appréciations sont des repères d'usage courant, pas des mesures absolues : la performance réelle dépend du codec, du réglage, du matériel et de la qualité du réseau.

En résumé pratique

Régie locale avec plusieurs sources vidéo sur le même réseau

NDI

Liaison vidéo fiable entre deux sites, via Internet

SRT

Accéder au flux d'une caméra IP

RTSP

Envoyer un programme vers YouTube, un CDN ou une plateforme événementielle

RTMP / RTMPS (RTMPS de préférence)

Diffuser vers des spectateurs web ou OTT

HLS

Distribuer un flux sur un réseau maîtrisé, en unicast ou multicast (IPTV interne, liaison dédiée)

TS over UDP (RTP en variante)

L'essentiel

La confusion vient du fait qu'on dit souvent « streaming » pour tout, alors que ces technologies n'interviennent pas au même niveau. En pratique : NDI sert à produire, SRT à transporter, RTSP à accéder au flux d'une caméra, RTMP à publier vers une plateforme, HLS à livrer aux spectateurs, TS over UDP à distribuer sur un réseau maîtrisé.

Et pour relire n'importe quelle fiche technique : le codec, c'est la compression ; le conteneur, c'est l'emballage ; le transport, c'est l'acheminement.

Aller plus loin

Un projet de production IP ?

Parlons de votre chaîne vidéo.

Choix de protocole, dimensionnement réseau, contribution distante, matériel adapté : l'équipe HoriCast accompagne les intégrateurs et utilisateurs finaux en France.

Nous contacter

Protocoles de transport vidéo : NDI^®, SRT, RTMP, HLS et les autres

Le codec

Le conteneur

Le transport

NDI

SRT

RTSP

RTMP / RTMPS

HLS

TS over UDP

Protocoles de contrôle AV

Comprendre NDI

NDI vs SDI

Logiciels de production live

Parlons de votre chaîne vidéo.

Un projet AV en France ? Parlons-en.

Protocoles de transport vidéo : NDI®, SRT, RTMP, HLS et les autres

Le codec

Le conteneur

Le transport

NDI

SRT

RTSP

RTMP / RTMPS

HLS

TS over UDP

Protocoles de contrôle AV

Comprendre NDI

NDI vs SDI

Logiciels de production live

Parlons de votre chaîne vidéo.

Un projet AV en France ? Parlons-en.

Protocoles de transport vidéo : NDI^®, SRT, RTMP, HLS et les autres