Installer un serveur de streaming : un seul envoi pour une infinité de spectateurs

Qui diffuse sans serveur à lui envoie son image à chaque spectateur séparément. Dix spectateurs, cela fait dix fois les mêmes données, cent spectateurs cent fois. La voie montante à la maison ou au bureau est donc saturée au bout de quelques spectateurs, et l'image commence à saccader alors que la machine s'ennuie.

Un serveur de streaming inverse la logique : vous envoyez exactement un flux vers le serveur, et le serveur alimente tous les spectateurs. Votre propre ligne ne porte ainsi jamais qu'un seul envoi, que dix ou dix mille personnes regardent. Cet article montre pourquoi cela fonctionne si bien, comment mettre en place un tel serveur, quelle latence coûte quel protocole et quel volume de trafic s'accumule réellement.

Le problème : votre voie montante est le goulot d'étranglement

La vidéo est un flux continu. Un flux en 1080p à 60 images par seconde demande, selon le contenu, de 4,5 à 8 Mbit/s, le 720p se situe entre 3 et 5 Mbit/s. Ce débit circule par spectateur, tout le temps, sans pause.

Un raccordement domestique moyen en Allemagne atteint entre 10 et 50 Mbit/s en envoi, et même beaucoup de raccordements en fibre plafonnent entre 50 et 100 Mbit/s dans ce sens. Le calcul est donc vite terminé :

S'y ajoute un second problème, souvent oublié : votre raccordement partage cette ligne avec tout le reste du foyer ou du bureau. Dès que quelqu'un envoie un gros fichier ou qu'une sauvegarde démarre, le flux s'effondre. Un serveur en centre de données n'a pas ce problème, là-bas la connectivité est à votre seule disposition.

Le principe : un seul envoi, de multiples réceptions

L'architecture comporte trois parties :

• L'émetteur, donc OBS, ffmpeg ou un boîtier matériel, envoie un flux vers le serveur. Cela s'appelle l'ingest.
• Le serveur reçoit ce flux unique, le convertit dans le format de diffusion souhaité et le tient prêt.
• Les spectateurs récupèrent le flux depuis le serveur. Cela s'appelle l'egress, et c'est la partie qui grandit avec le nombre de spectateurs.

L'asymétrie est décisive : le chemin de vous vers le serveur est parcouru une seule fois, le chemin du serveur vers les spectateurs mille fois. Votre raccordement n'a donc besoin que de l'envoi d'un unique flux, tandis que le serveur a besoin d'une connectivité qui suit le rythme du public.

Quel volume de trafic s'accumule réellement

La bande passante n'est que la moitié du calcul. Le volume est plus intéressant, car c'est sur lui que beaucoup d'hébergeurs facturent. La formule est simple :

Volume en Go = débit en Mbit/s × secondes × spectateurs ÷ 8000

Quelques exemples réalistes :

Les chiffres de la dernière colonne expliquent pourquoi le streaming et la facturation au volume vont mal ensemble. Une seule diffusion bien suivie peut consommer le volume inclus d'un mois entier, et chaque téraoctet supplémentaire est ensuite facturé à l'unité. Avec une offre à trafic illimité, ce calcul disparaît complètement : le prix mensuel est fixe, que 200 Go ou 50 To passent par la ligne.

Quel logiciel vous convient

Pour débuter, nginx avec le module RTMP est le choix le plus évident : il est disponible partout, bien documenté, et vous pourrez utiliser le même serveur plus tard comme serveur web pour la page des spectateurs, sans rien remanier.

Mettre en place un serveur de streaming avec nginx et RTMP

Installer

Sur Debian et Ubuntu, le paquet libnginx-mod-rtmp apporte le module, vous n'avez rien à compiler vous-même :

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

Sur AlmaLinux et Rocky Linux, le module vient du dépôt EPEL :

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

Configurer

La partie RTMP se place dans nginx.conf en dehors du bloc http, c'est l'erreur de débutant la plus fréquente. Une version légère et fonctionnelle ressemble à ceci :

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS pour les spectateurs ordinaires
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # seule votre propre adresse a le droit de diffuser
            allow publish 203.0.113.10;
            deny publish all;

            # tout le monde peut regarder
            allow play all;
        }
    }
}

Les fichiers HLS sont ensuite servis par le serveur web normal. Un petit bloc dans la partie http suffit :

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

Créer le répertoire, vérifier la configuration, redémarrer :

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

Ouvrir les ports

RTMP écoute sur le port 1935, la diffusion passe par 80 et 443. Avec nftables ou ufw :

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

Notez la première ligne : le port d'émission n'est ouvert que pour votre propre adresse. Un port RTMP ouvert au monde entier est trouvé en quelques jours, parce que des plages d'adresses entières sont parcourues automatiquement, et quelqu'un d'autre diffuse alors par votre ligne.

Émettre avec OBS

Dans OBS, sous Paramètres, Stream, indiquez le service « Personnalisé » :

Sous Sortie, vous réglez le débit. À titre indicatif : 1080p60 à 6000 kbit/s, 1080p30 à 4500 kbit/s, 720p30 à 3000 kbit/s. Mettez l'intervalle entre images clés à 2 secondes, sinon HLS produit des segments irréguliers et le lecteur hoquette au moment des changements.

Regarder

Le flux se trouve ensuite sous https://stream.example.com/hls/kanal1.m3u8 et s'ouvre avec n'importe quel lecteur compatible HLS, dans le navigateur par exemple avec hls.js ou Video.js. Pour une vérification rapide, VLC suffit via « Ouvrir un flux réseau ».

Émettre vers plusieurs plateformes en même temps

C'est le deuxième grand avantage d'un serveur à soi. Au lieu de faire exploser votre ligne avec trois envois parallèles, vous émettez une fois vers le serveur, et celui-ci redistribue. Pour cela, vous ajoutez une ligne par destination dans le bloc application :

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

Votre envoi reste un flux unique. La multiplication est l'affaire du serveur, et là-bas la bande passante est exactement ce pour quoi il est fait.

Latence : quel protocole pour quel usage

La latence naît presque entièrement à la diffusion, pas à l'émission. C'est important à comprendre, car beaucoup cherchent au mauvais endroit :

Plus la latence est basse, plus le spectateur individuel coûte cher. HLS est le moins cher, parce qu'il se compose de simples fichiers que n'importe quel serveur web et n'importe quel cache savent servir. WebRTC maintient en revanche une connexion ouverte par spectateur et demande donc nettement plus de puissance de calcul. Ne prenez la latence basse que là où vous en avez vraiment besoin.

Transcodage : quand cela vaut la peine

Tant que le serveur ne fait que transmettre le flux, il n'a presque pas besoin de puissance de calcul. Un seul cœur moderne sert ainsi plusieurs centaines de spectateurs, le goulot d'étranglement est uniquement la connectivité.

Dès que vous voulez proposer plusieurs niveaux de qualité, afin que les spectateurs à faible connexion puissent regarder aussi, cela change. Chaque niveau supplémentaire doit être calculé :

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

Comptez deux à quatre cœurs par niveau. Trois niveaux occupent donc déjà huit à douze cœurs en permanence. Réfléchissez bien à leur nécessité : pour un public majoritairement devant un ordinateur ou en Wi-Fi, un seul niveau bien choisi suffit souvent.

Sécuriser : qui a le droit d'émettre

Un serveur de streaming est visible de l'extérieur et il sera trouvé. Trois mesures suffisent au quotidien :

• Pare-feu sur le port d'émission. Seule votre propre adresse a accès au 1935. Si votre adresse change, utilisez plutôt un accès VPN vers le serveur.
• Vérifier la clé de stream. Avec on_publish, nginx appelle à chaque tentative d'émission un petit script qui compare la clé à une liste et refuse en cas de non-correspondance.
• Protection de base contre la surcharge. Un serveur de streaming est une cible intéressante, parce qu'une panne est immédiatement visible. Chez KernelHost, une protection anti-flood d'une capacité de 3,2 Tbps est posée sur chaque serveur, sans que vous ayez quoi que ce soit à configurer. Plus de détails sur la page consacrée à la protection DDoS.

Choix de l'emplacement et plusieurs serveurs

Le serveur n'a pas sa place près de vous, mais près de vos spectateurs. Votre propre connexion vers le serveur est établie une fois et reste ensuite stable, même à travers un demi-continent. La connexion vers les spectateurs, elle, décide du temps de chargement et du taux d'abandon.

Si votre public se trouve majoritairement en Europe, un emplacement en Allemagne est le bon choix. S'il se répartit sur plusieurs continents, un deuxième serveur et une répartition par DNS valent la peine, pour que chaque spectateur arrive sur le plus proche. KernelHost propose pour cela des emplacements en Allemagne, sur la côte ouest et sur la côte est des États-Unis ainsi qu'à Singapour et en Corée du Sud, vous trouverez un aperçu sous Emplacements des serveurs.

Si vous distribuez des fichiers au lieu d'images en direct, donc des mises à jour, des images ou des archives vidéo, le bon outil n'est pas un serveur de streaming mais un cache placé devant. Le fonctionnement est décrit dans l'article Monter son propre serveur CDN.

Quel serveur convient

Pour un serveur de streaming, l'ordre des priorités n'est pas celui d'un serveur web :

1. Connectivité et trafic. C'est le goulot d'étranglement, et toujours. Une vraie connectivité gigabit sans bridage porte environ 160 spectateurs à 6 Mbit/s.
2. Trafic illimité. Les offres facturées au volume sont difficilement calculables pour le streaming, parce qu'une seule soirée réussie consomme le volume du mois.
3. CPU. Secondaire, tant que vous ne transcodez pas. Avec le transcodage, il devient le deuxième goulot d'étranglement.
4. RAM et disque. Les moins critiques. L'espace disque ne devient un sujet que lorsque vous conservez les enregistrements.

Nos serveurs root à trafic illimité sont taillés exactement pour ce cas : une vraie connectivité de 2 × 1 Gbit/s par serveur, un volume illimité sans bridage, un prix mensuel fixe indépendant de la quantité transférée, et 3,2 Tbps de protection anti-flood d'origine. Le serveur est mis à disposition en moins de 30 secondes, avec un accès root complet, une IPv4 et un réseau IPv6 en /64. La facturation se fait en prépaiement et reste résiliable chaque mois, vous pouvez donc commencer avec une petite offre et grandir quand votre public grandit.