Installer un serveur de streaming Linux avec SRT et RTMP
Ce que fait un serveur de streaming Linux
Un serveur de streaming Linux reçoit des flux vidéo (SRT, RTMP, RIST), les route vers une ou plusieurs destinations, et éventuellement les transcode. C’est le noeud central de toute infrastructure de diffusion en direct. Il peut alimenter des CDN, des plateformes comme YouTube ou Twitch, des lecteurs HLS internes, ou d’autres serveurs en cascade.
Ce guide couvre quatre solutions concrètes pour monter un serveur de streaming Linux : Vajra Cast, Nginx-RTMP, SRT Live Server et MediaMTX. Chacune a son domaine de pertinence. Vous trouverez les commandes d’installation, les fichiers de configuration, et un comparatif pour choisir en connaissance de cause.
Configuration matérielle requise
Le dimensionnement dépend de votre charge de travail. Le routage passthrough (recevoir un flux et le retransmettre sans transcodage) consomme très peu de CPU. Le transcodage, en revanche, est extrêmement gourmand.
| Charge de travail | CPU | RAM | Réseau |
|---|---|---|---|
| 1-10 flux passthrough | 2 coeurs | 4 Go | 1 Gbps |
| 10-30 flux passthrough | 4 coeurs | 8 Go | 1 Gbps |
| 1-5 transcodages 1080p60 | 8 coeurs (ou GPU QSV) | 16 Go | 1 Gbps |
| 10+ transcodages simultanés | 16 coeurs + GPU dédié | 32 Go | 10 Gbps |
Pour le transcodage matériel, un processeur Intel de 11e génération ou plus récent avec Quick Sync Video offre le meilleur rapport performance/prix. Pas besoin de carte graphique discrète.
Choix du système : Ubuntu 22.04 ou 24.04
Ubuntu Server LTS est le choix le plus pragmatique. Les raisons :
- Support long terme (5 ans de mises à jour de sécurité)
- Paquets à jour pour Docker, FFmpeg, et les pilotes Intel
- Documentation abondante pour chaque cas de figure
- Compatibilité garantie avec les images Docker des quatre solutions présentées ici
Ubuntu 22.04 LTS est le choix le plus éprouvé en production. Ubuntu 24.04 LTS apporte un noyau plus récent (6.8), ce qui améliore le support matériel pour les GPU Intel Arc et les dernières générations de processeurs.
Installation minimale recommandée :
# Mise à jour du système
sudo apt update && sudo apt upgrade -y
# Paquets de base pour le streaming
sudo apt install -y docker.io docker-compose-plugin curl net-tools iperf3
# Activer Docker au démarrage
sudo systemctl enable docker
sudo usermod -aG docker $USER
Option 1 : Vajra Cast (Docker)
Vajra Cast est une passerelle de streaming SRT avec interface web. Elle gère l’ingestion SRT/RTMP/RIST, le routage multi-destinations, le transcodage matériel (Intel QSV, VAAPI, VideoToolbox), l’enregistrement, et la sortie HLS. Le tout dans un seul conteneur Docker.
Installation
# Créer les répertoires de données
mkdir -p /opt/vajracast/data /opt/vajracast/recordings
# Lancer Vajra Cast
docker run -d \
--name vajracast \
--network host \
--device /dev/dri:/dev/dri \
-v /opt/vajracast/data:/data \
-v /opt/vajracast/recordings:/recordings \
--restart unless-stopped \
vajracast/vajracast:latest
L’interface web est accessible sur le port 3000. La configuration se fait entièrement via l’UI : création d’ingests SRT/RTMP, ajout de sorties, activation du transcodage, supervision en temps réel des métriques SRT (RTT, perte de paquets, gigue).
Points forts
- Pas de fichiers de configuration à écrire manuellement
- Supervision des métriques SRT intégrée (pas besoin de Grafana pour commencer)
- Basculement automatique entre sources (failover)
- Distribution zero-copy : le routage passthrough multi-sorties ne consomme quasiment pas de CPU
- Déploiement Docker et Kubernetes documenté et testé
Limites
- Logiciel commercial (licence payante au-delà de la version d’essai)
- Pas de code source disponible
Option 2 : Nginx-RTMP
Le module RTMP pour Nginx est un classique. Il transforme Nginx en serveur RTMP capable de recevoir des flux et de les redistribuer en RTMP ou HLS.
Installation
sudo apt install -y libnginx-mod-rtmp nginx
Configuration
Ajoutez le bloc RTMP dans /etc/nginx/nginx.conf :
rtmp {
server {
listen 1935;
chunk_size 4096;
application live {
live on;
record off;
# Sortie HLS
hls on;
hls_path /var/www/hls;
hls_fragment 4;
hls_playlist_length 60;
# Relais vers YouTube
# push rtmp://a.rtmp.youtube.com/live2/VOTRE_CLE;
}
}
}
Créez le répertoire HLS et redémarrez :
sudo mkdir -p /var/www/hls
sudo chown www-data:www-data /var/www/hls
sudo systemctl restart nginx
Points forts
- Gratuit, open source, très stable
- Excellent pour le RTMP pur et la conversion RTMP vers HLS
- Consommation mémoire minimale
Limites
- Pas de support SRT natif (RTMP uniquement en entrée)
- Pas d’interface web, tout se configure dans des fichiers texte
- Pas de transcodage intégré (il faut chaîner FFmpeg manuellement)
- Pas de métriques SRT, pas de supervision intégrée
- Le module n’est plus activement maintenu par son auteur original
Option 3 : SRT Live Server
SRT Live Server (sls) est un serveur léger dédié au protocole SRT. Il reçoit des flux SRT et les redistribue en SRT. Pas de RTMP, pas de HLS, pas de transcodage. C’est un routeur SRT pur.
Installation
sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/Haivision/srt.git /tmp/srt
cd /tmp/srt && mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
make -j$(nproc) && sudo make install
git clone https://github.com/Edward-Wu/srt-live-server.git /tmp/sls
cd /tmp/sls
make -j$(nproc)
sudo cp bin/sls /usr/local/bin/
Configuration
Créez /etc/sls/sls.conf :
srt {
worker_threads 1;
worker_connections 300;
server {
listen 8080;
latency 200;
domain_player play {
on_event_url "";
}
domain_publisher publish {
on_event_url "";
}
}
}
Lancez le serveur :
sls -c /etc/sls/sls.conf
Points forts
- Très léger, empreinte mémoire quasi nulle
- Conçu exclusivement pour SRT, performances optimales pour ce cas
- Open source (licence MIT)
Limites
- SRT uniquement, pas de RTMP ni HLS en sortie
- Pas d’interface web
- Pas de transcodage
- Projet peu actif, documentation sommaire
- Il faut compiler depuis les sources
Option 4 : MediaMTX
MediaMTX (anciennement rtsp-simple-server) est un serveur multiprotocole : RTSP, RTMP, HLS, WebRTC, SRT. Un binaire unique, zéro dépendance.
Installation
# Télécharger la dernière version
MEDIAMTX_VERSION=$(curl -s https://api.github.com/repos/bluenviron/mediamtx/releases/latest | grep tag_name | cut -d '"' -f 4)
wget "https://github.com/bluenviron/mediamtx/releases/download/${MEDIAMTX_VERSION}/mediamtx_${MEDIAMTX_VERSION}_linux_amd64.tar.gz"
tar xzf mediamtx_*.tar.gz
sudo mv mediamtx /usr/local/bin/
sudo mv mediamtx.yml /etc/mediamtx.yml
Configuration
Éditez /etc/mediamtx.yml :
# Protocoles activés
rtsp: yes
rtmp: yes
hls: yes
srt: yes
webrtc: yes
# Ports
rtspAddress: :8554
rtmpAddress: :1935
hlsAddress: :8888
srtAddress: :8890
paths:
all_others:
Lancez le serveur :
mediamtx /etc/mediamtx.yml
Points forts
- Multiprotocole dans un seul binaire
- Configuration YAML simple
- Support WebRTC pour la prévisualisation basse latence
- Open source, projet actif
Limites
- Pas de transcodage intégré
- Pas d’interface web de gestion
- Pas de métriques SRT détaillées (RTT, retransmissions, gigue)
- Pas de basculement automatique entre sources
Tableau comparatif
| Fonctionnalité | Vajra Cast | Nginx-RTMP | SRT Live Server | MediaMTX |
|---|---|---|---|---|
| Ingestion SRT | Oui | Non | Oui | Oui |
| Ingestion RTMP | Oui | Oui | Non | Oui |
| Sortie HLS | Oui | Oui | Non | Oui |
| Sortie WebRTC | Non | Non | Non | Oui |
| Transcodage matériel | Oui (QSV, VAAPI) | Non | Non | Non |
| Interface web | Oui | Non | Non | Non |
| Métriques SRT temps réel | Oui | N/A | Basique | Non |
| Basculement automatique | Oui | Non | Non | Non |
| Enregistrement | Oui | Oui | Non | Oui |
| Licence | Commerciale | BSD | MIT | MIT |
| Difficulté d’installation | Faible | Faible | Moyenne | Faible |
Pour une comparaison détaillée entre Vajra Cast et d’autres solutions commerciales, consultez la page alternative à Wowza.
Configuration réseau
Pare-feu
Ouvrez les ports nécessaires selon les protocoles utilisés :
# SRT (UDP)
sudo ufw allow 9000:9100/udp comment "SRT listeners"
# RTMP (TCP)
sudo ufw allow 1935/tcp comment "RTMP"
# HLS (TCP)
sudo ufw allow 8888/tcp comment "HLS"
# Interface web Vajra Cast
sudo ufw allow 3000/tcp comment "Vajra Cast UI"
# Appliquer
sudo ufw enable
Point critique : SRT utilise UDP. Beaucoup de pare-feu d’entreprise bloquent UDP par défaut. Vérifiez chaque maillon de la chaîne réseau (serveur, routeur, FAI, pare-feu cloud). Pour approfondir les différences entre SRT et RTMP, consultez le comparatif SRT vs RTMP.
Configuration MTU pour SRT
Sur les réseaux locaux, activez les trames jumbo pour réduire la charge CPU liée au traitement des paquets :
# Vérifier le MTU actuel
ip link show eth0
# Activer les trames jumbo (MTU 9000) sur l'interface
sudo ip link set eth0 mtu 9000
# Rendre permanent dans /etc/netplan (Ubuntu)
# Ajoutez mtu: 9000 sous l'interface dans votre fichier netplan
Sur les liens internet publics, conservez le MTU par défaut (1500). Les trames jumbo ne traversent pas internet.
Optimisation des performances (paramètres noyau)
Les paramètres par défaut du noyau Linux ne sont pas optimisés pour le streaming vidéo UDP à haut débit. Ajustez les tampons réseau :
# Augmenter les tampons réseau UDP
sudo sysctl -w net.core.rmem_max=67108864
sudo sysctl -w net.core.wmem_max=67108864
sudo sysctl -w net.core.rmem_default=4194304
sudo sysctl -w net.core.wmem_default=4194304
# Augmenter la file d'attente réseau
sudo sysctl -w net.core.netdev_max_backlog=65536
# Rendre permanent
sudo tee -a /etc/sysctl.d/99-streaming.conf << 'EOF'
net.core.rmem_max=67108864
net.core.wmem_max=67108864
net.core.rmem_default=4194304
net.core.wmem_default=4194304
net.core.netdev_max_backlog=65536
EOF
sudo sysctl -p /etc/sysctl.d/99-streaming.conf
Ces paramètres augmentent les tampons de réception et d’envoi UDP à 64 Mo, ce qui évite les pertes de paquets lors de pics de trafic. C’est particulièrement important pour SRT, qui utilise des tampons de retransmission volumineux sur les liaisons longue distance.
Affinité CPU et interruptions réseau
Sur les serveurs à fort trafic (10 Gbps+), répartissez les interruptions réseau sur plusieurs coeurs :
# Vérifier la répartition actuelle des interruptions
cat /proc/interrupts | grep eth0
# Activer la répartition automatique (irqbalance)
sudo apt install -y irqbalance
sudo systemctl enable irqbalance
Monitoring
Un serveur de streaming sans supervision est un serveur qui tombera en panne sans prévenir. Au minimum, surveillez :
- Bande passante réseau (entrée et sortie) pour détecter la saturation
- Charge CPU pour anticiper les limites de transcodage
- Métriques SRT (RTT, perte de paquets, retransmissions) pour évaluer la qualité du lien
Prometheus + Grafana (toutes solutions)
# Installer node_exporter pour les métriques système
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-*linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/
Créez un service systemd pour node_exporter, configurez Prometheus pour le scraper, et montez un tableau de bord Grafana avec les métriques réseau et CPU.
Vajra Cast expose ses propres métriques SRT en temps réel dans son interface web. Pour les autres solutions, il faut instrumenter manuellement (parser les logs ou interroger les APIs quand elles existent).
Pour un guide complet sur la configuration SRT et la supervision des métriques, consultez le guide de configuration SRT.
Sécurité
Chiffrement SRT
Activez systématiquement le chiffrement AES sur les flux SRT qui traversent internet :
# Exemple d'URL SRT avec chiffrement AES-256
srt://votre-serveur:9000?passphrase=VotrePassphraseSecurisee&pbkeylen=32
Les deux extrémités (émetteur et récepteur) doivent utiliser la même passphrase et la même longueur de clé. Une passphrase de 20 caractères minimum est recommandée en production.
Restriction d’accès
Limitez l’exposition réseau du serveur :
# Restreindre l'interface web aux IP de gestion uniquement
sudo ufw allow from 192.168.1.0/24 to any port 3000 proto tcp
# Restreindre SSH
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
# Désactiver l'accès root SSH
sudo sed -i 's/#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
Mises à jour automatiques
Pour un serveur de production, activez les mises à jour de sécurité automatiques :
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
Conclusion
Le choix du serveur de streaming Linux dépend de votre cas d’usage. Si vous avez besoin uniquement de RTMP vers HLS, Nginx-RTMP suffit. Si vous voulez du SRT pur sans fioritures, SRT Live Server fait le travail. MediaMTX couvre un large spectre de protocoles pour le prototypage ou les petits déploiements.
Pour un usage production avec SRT, transcodage matériel, basculement automatique et supervision intégrée, Vajra Cast centralise tout cela dans une interface unique, sans avoir à assembler et maintenir une chaîne d’outils séparés.
Quel que soit votre choix, les fondamentaux restent les mêmes : dimensionnez votre matériel selon votre charge, optimisez les paramètres noyau pour UDP, surveillez vos métriques, et chiffrez tout ce qui passe sur internet.