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 travailCPURAMRéseau
1-10 flux passthrough2 coeurs4 Go1 Gbps
10-30 flux passthrough4 coeurs8 Go1 Gbps
1-5 transcodages 1080p608 coeurs (ou GPU QSV)16 Go1 Gbps
10+ transcodages simultanés16 coeurs + GPU dédié32 Go10 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 CastNginx-RTMPSRT Live ServerMediaMTX
Ingestion SRTOuiNonOuiOui
Ingestion RTMPOuiOuiNonOui
Sortie HLSOuiOuiNonOui
Sortie WebRTCNonNonNonOui
Transcodage matérielOui (QSV, VAAPI)NonNonNon
Interface webOuiNonNonNon
Métriques SRT temps réelOuiN/ABasiqueNon
Basculement automatiqueOuiNonNonNon
EnregistrementOuiOuiNonOui
LicenceCommercialeBSDMITMIT
Difficulté d’installationFaibleFaibleMoyenneFaible

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.