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

  1. Ouvrez OBS, cliquez sur « Fichier » → « Paramètres » → « Diffusion »
  2. Pour le service, choisissez « Personnalisé... »
  3. Serveur : rtmp://votre-adresse-serveur/live
  4. Clé de stream : votre clé de salle de diffusion
  5. Cliquez sur « OK » pour enregistrer les paramètres
  6. Cliquez sur « Démarrer la diffusion » pour commencer le direct

2. Configuration de diffusion SRT

  1. Ouvrez OBS, cliquez sur « Fichier » → « Paramètres » → « Diffusion »
  2. Pour le service, choisissez « Personnalisé... »
  3. Serveur : srt://votre-adresse-serveur:9000?streamid=votre-nom-de-flux
  4. Laissez la clé de stream vide
  5. Cliquez sur « OK » pour enregistrer les paramètres
  6. 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.

Articles recommandés

Plus d'articles intéressants et d'outils pratiques

Vous voulez tester votre flux de direct ?

Utilisez notre lecteur FLV/RTMP en ligne pour vérifier rapidement si votre flux fonctionne

Essayer maintenant ➡