CGJU
CGJU
25 juin 2026 · Temps de lecture 7 minutes
💡 Choix rapide : RTMP pour le streaming général, SRT pour une faible latence et haute qualité, WebRTC pour l'interaction en temps réel dans le navigateur.
I. Aperçu des trois protocoles de streaming
1. Protocole RTMP
RTMP (Real-Time Messaging Protocol) est un protocole de transmission de messages en temps réel développé par Macromedia (racheté ensuite par Adobe), initialement utilisé pour la transmission audio-vidéo entre le lecteur Flash et le serveur.
- Date de publication : 2002
- Développeur : Adobe / Macromedia
- Couche transport : TCP
- Port par défaut : 1935
Bien que Flash ait disparu, RTMP reste le protocole le plus utilisé pour l'envoi de flux en direct, et presque toutes les plateformes de streaming (comme Douyin, Bilibili, Twitch) prennent en charge la diffusion RTMP.
2. Protocole SRT
SRT (Secure Reliable Transport) est un protocole de transport vidéo open source développé par Haivision, basé sur UDP, tout en offrant une fiabilité similaire à TCP.
- Date de publication : 2017 (open source)
- Développeur : Haivision
- Couche transport : UDP
- Port par défaut : personnalisable (souvent 9000)
L'avantage principal de SRT est de maintenir une faible latence et une transmission de haute qualité même dans des environnements réseau instables, ce qui le rend adapté à la production à distance, au streaming en extérieur, etc.
3. Protocole WebRTC
WebRTC (Web Real-Time Communication) est une technologie de communication en temps réel sur le web, prenant en charge la communication audio-vidéo directe entre navigateurs, sans nécessiter l'installation de plugin.
- Date de publication : 2011
- Développeur : Google, devenu ensuite standard W3C
- Couche transport : UDP
- Port par défaut : aléatoire (souvent 3478/19302)
Le plus grand avantage de WebRTC est sa latence extrêmement faible (généralement inférieure à 500 ms), et sa prise en charge native par les navigateurs, ce qui le rend idéal pour le streaming interactif en direct, les visioconférences, etc.
II. Comparaison de la latence
La latence est l'un des indicateurs les plus importants des protocoles de streaming, et différentes applications ont des exigences de latence variables.
| Protocole |
Latence typique |
Niveau de latence |
| RTMP |
1-3 secondes |
Faible latence |
| SRT |
0.5-2 secondes |
Très faible latence |
| WebRTC |
100-500 ms |
Ultra-faible latence |
⚠️ Note : Ce sont les latences entre l'émetteur et le serveur. Si la diffusion vers les spectateurs passe par des protocoles comme HLS/DASH, la latence totale peut augmenter jusqu'à 10-30 secondes. Pour obtenir une faible latence de bout en bout, il faut utiliser des protocoles à faible latence sur toute la chaîne.
III. Comparaison de compatibilité
Compatibilité côté émission
- RTMP : pris en charge par presque tous les logiciels d'émission (OBS, FFmpeg, Wirecast, etc.) et plateformes de streaming, meilleure compatibilité
- SRT : pris en charge par OBS 25.0+, FFmpeg 4.0+, les appareils Haivision, etc., le support s'améliore rapidement
- WebRTC : pris en charge nativement par les navigateurs, peu de support dans les logiciels de bureau comme OBS, nécessite un SDK dédié
Compatibilité côté lecture
- RTMP : les navigateurs nécessitent Flash (obsolète) ou utilisent des bibliothèques comme flv.js pour la lecture via HTTP-FLV, mauvais support natif
- SRT : non pris en charge par les navigateurs, nécessite un lecteur ou un appareil dédié
- WebRTC : pris en charge nativement par tous les navigateurs principaux (Chrome, Firefox, Safari, Edge)
Support CDN
- RTMP : pris en charge par tous les fournisseurs CDN, est le protocole standard des CDN de streaming
- SRT : pris en charge par certains CDN (comme Cloudflare Stream, Akamai), le support augmente
- WebRTC : peu de CDN prennent en charge la diffusion WebRTC, coût plus élevé
IV. Comparaison de l'adaptabilité réseau
Le streaming en direct est souvent confronté à des instabilités réseau, donc l'adaptabilité réseau du protocole est très importante.
| Caractéristique |
RTMP |
SRT |
WebRTC |
| Protocole de transport |
TCP |
UDP + ARQ |
UDP |
| Retransmission en cas de perte |
✓ Retransmission TCP |
✓ Retransmission sélective |
△ Support partiel |
| Impact des pertes |
Élevé (saccades cumulées) |
Faible |
Faible (baisse de qualité) |
| Fluctuation de bande passante |
Mauvaise |
Bonne |
Très bonne (adaptative) |
| Chiffrement |
△ RTMPS |
✓ AES-128/256 |
✓ DTLS-SRTP |
V. Tutoriel de configuration OBS
OBS Studio est le logiciel de streaming en direct le plus populaire. Voici comment configurer la diffusion avec différents protocoles.
1. Configuration de diffusion RTMP
- Ouvrez OBS, cliquez sur « Fichier » → « Paramètres » → « Diffusion »
- Pour le service, choisissez « Personnalisé... »
- Serveur :
rtmp://votre-adresse-serveur/live
- Clé de stream : votre clé de salle de diffusion
- Cliquez sur « OK » pour enregistrer les paramètres
- Cliquez sur « Démarrer la diffusion » pour commencer le direct
2. Configuration de diffusion SRT
- Ouvrez OBS, cliquez sur « Fichier » → « Paramètres » → « Diffusion »
- Pour le service, choisissez « Personnalisé... »
- Serveur :
srt://votre-adresse-serveur:9000?streamid=votre-nom-de-flux
- Laissez la clé de stream vide
- Cliquez sur « OK » pour enregistrer les paramètres
- Cliquez sur « Démarrer la diffusion » pour commencer le direct
3. Paramètres de codage vidéo recommandés
- Encodeur : x264 (bonne compatibilité) ou NVENC (accélération matérielle, faible utilisation CPU)
- Résolution : 1920×1080 (1080p) ou 1280×720 (720p)
- Fréquence d'images : 30 fps ou 60 fps
- Débit : 3000-6000 kbps (ajustez selon la bande passante montante)
- Intervalle d'images clés : 2 secondes (60 images @ 30fps)
- Préréglage : veryfast ou faster (équilibre entre vitesse et qualité)
VI. Mise en place d'un serveur Nginx-RTMP
Nginx-RTMP est la solution la plus courante pour auto-héberger un serveur de streaming. Voici une méthode de mise en place rapide.
1. Installation Ubuntu/Debian
# Installer les dépendances
sudo apt update
sudo apt install -y build-essential libpcre3 libpcre3-dev libssl-dev zlib1g-dev
# Télécharger nginx et nginx-rtmp-module
wget http://nginx.org/download/nginx-1.24.0.tar.gz
wget https://github.com/arut/nginx-rtmp-module/archive/refs/heads/master.zip -O nginx-rtmp-module.zip
# Décompresser
tar zxf nginx-1.24.0.tar.gz
unzip nginx-rtmp-module.zip
# Compiler et installer
cd nginx-1.24.0
./configure --add-module=../nginx-rtmp-module-master
make
sudo make install
2. Configuration Nginx-RTMP
Éditez /usr/local/nginx/conf/nginx.conf, ajoutez la configuration rtmp avant le bloc http :
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
# Configuration HLS
hls on;
hls_path /tmp/hls;
hls_fragment 3s;
hls_playlist_length 10s;
}
}
}
Ajoutez ensuite la configuration d'accès HLS dans le bloc http :
location /hls {
types {
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
root /tmp;
add_header Cache-Control no-cache;
add_header Access-Control-Allow-Origin *;
}
3. Démarrer le service
# Démarrer nginx
sudo /usr/local/nginx/sbin/nginx
# Recharger la configuration
sudo /usr/local/nginx/sbin/nginx -s reload
# Arrêter
sudo /usr/local/nginx/sbin/nginx -s stop
4. Tester la diffusion
Utilisez FFmpeg pour tester la diffusion :
ffmpeg -re -i input.mp4 -c copy -f flv rtmp://localhost/live/stream1
Vous pouvez ensuite regarder via les adresses suivantes :
- Adresse RTMP :
rtmp://votre-IP-serveur/live/stream1
- Adresse HLS :
http://votre-IP-serveur/hls/stream1.m3u8
VII. Commandes de diffusion FFmpeg
1. Diffusion RTMP
Diffusion de fichier local (vitesse en temps réel) :
ffmpeg -re -i input.mp4 -c:v libx264 -b:v 2500k -g 60 \
-c:a aac -b:a 128k -f flv rtmp://server/live/stream
Le paramètre -re signifie lire l'entrée à la vitesse d'images native, simulant un direct en temps réel.
2. Diffusion en direct caméra/microphone
# Linux
ffmpeg -f v4l2 -i /dev/video0 -f alsa -i default \
-c:v libx264 -b:v 2000k -g 60 \
-c:a aac -b:a 128k \
-f flv rtmp://server/live/stream
# Windows
ffmpeg -f dshow -i video="Nom-caméra":audio="Nom-micro" \
-c:v libx264 -b:v 2000k -g 60 \
-c:a aac -b:a 128k \
-f flv rtmp://server/live/stream
3. Diffusion SRT
# Côté émetteur
ffmpeg -re -i input.mp4 -c:v libx264 -b:v 2500k -g 30 \
-c:a aac -b:a 128k -f mpegts srt://0.0.0.0:9000?mode=listener
# Côté lecteur (ou réacheminement)
ffplay srt://IP-émetteur:9000?mode=caller
4. Diffusion capture d'écran
# X11 (Linux)
ffmpeg -f x11grab -s 1920x1080 -r 30 -i :0.0 \
-c:v libx264 -b:v 3000k -g 60 \
-c:a aac -b:a 128k \
-f flv rtmp://server/live/stream
# gdigrab (Windows)
ffmpeg -f gdigrab -s 1920x1080 -r 30 -i desktop \
-c:v libx264 -b:v 3000k -g 60 \
-c:a aac -b:a 128k \
-f flv rtmp://server/live/stream
VIII. Bonnes pratiques du streaming en direct
1. Paramètres de diffusion recommandés
| Niveau de qualité |
Résolution |
FPS |
Débit vidéo |
Débit audio |
| SD |
854×480 |
30 |
800-1500k |
96-128k |
| HD |
1280×720 |
30 |
1500-3000k |
128k |
| Full HD |
1920×1080 |
30 |
3000-6000k |
128-192k |
| Full HD haut FPS |
1920×1080 |
60 |
4500-8000k |
128-192k |
2. Conseils de réseau
- Utilisez le réseau filaire : le WiFi est instable, pour les directs importants utilisez une connexion Ethernet directe
- Réservez de la bande passante : la vitesse de téléversement doit être au moins 1.5-2 fois le débit de diffusion
- Testez le réseau : avant le direct, testez la vitesse montante avec speedtest.net
- Plan de secours : préparez un réseau de secours 4G/5G en cas de panne du réseau principal
3. Sécurité de la diffusion
- Utilisez une clé de stream : ne divulguez pas votre adresse et clé de diffusion
- Activez l'authentification : configurez l'authentification de diffusion sur le serveur pour éviter les diffusions non autorisées
- Utilisez RTMPS : sur les plateformes qui le supportent, utilisez RTMPS (RTMP over TLS) pour chiffrer la diffusion
Conclusion
Le choix du protocole de streaming dépend du cas d'utilisation spécifique :
- RTMP : écosystème le plus mature, meilleure compatibilité, adapté à la plupart des scénarios de streaming
- SRT : excellente résistance aux saccades réseau, adapté au streaming en extérieur, à la production à distance
- WebRTC : latence la plus faible, pris en charge nativement par les navigateurs, adapté au streaming interactif en temps réel
Pour la plupart des utilisateurs, la diffusion RTMP + distribution HLS/HTTP-FLV est la solution la plus sûre. Si vous avez besoin d'interaction à faible latence, envisagez WebRTC.
Vous voulez tester si votre flux de direct fonctionne ? Utilisez notre lecteur FLV/RTMP en ligne pour vérifier rapidement la disponibilité du flux.