Configuration serveur de streaming : guide matériel pour l'infrastructure de diffusion

Dimensionner votre serveur de streaming

La question la plus courante lors de la construction d’une infrastructure de streaming est : quel matériel me faut-il ? La réponse dépend entièrement de ce que vous demandez au serveur de faire. Un serveur qui route 20 flux SRT en passthrough a des besoins très différents d’un serveur qui transcode 5 flux avec accélération matérielle.

Ce guide détaille les exigences matérielles pour chaque composant d’un workflow de streaming, des configurations minimales aux deployments à l’échelle de l’entreprise. Nous couvrirons le CPU, la RAM, le GPU, le réseau et le stockage, avec des recommandations spécifiques pour l’exécution de Vajra Cast.

Comprendre votre charge de travail

Avant de choisir le matériel, classifiez votre charge de travail. Les serveurs de streaming effectuent trois tâches fondamentalement différentes, chacune avec un profil de ressources distinct :

1. Routage passthrough

Le serveur reçoit un flux et le retransmet vers une ou plusieurs destinations sans modifier la vidéo ni l’audio. Les données circulent : réseau entrant, mémoire, réseau sortant.

Profil de ressources :

• CPU : très faible (gestion du protocole uniquement)
• RAM : faible (espace tampon par flux)
• GPU : non utilisé
• Réseau : le goulot d’étranglement
• Disque : non utilisé (sauf enregistrement)

C’est ce qui se passe avec la distribution zero-copy de Vajra Cast. Le coût CPU est quasi nul par sortie supplémentaire car les données du flux sont partagées en mémoire.

2. Transcodage (logiciel)

Le serveur décode la vidéo entrante, la ré-encode à une résolution, un débit ou un codec différent, et envoie le résultat aux sorties. C’est extrêmement coûteux en calcul.

Profil de ressources :

• CPU : très élevé (le goulot d’étranglement)
• RAM : modéré
• GPU : non utilisé
• Réseau : modéré
• Disque : faible (sauf enregistrement)

Le transcodage logiciel (x264, x265) est flexible mais intensif en CPU. Un seul transcodage H.264 en 1080p60 à bonne qualité peut saturer 8 coeurs CPU ou plus.

3. Transcodage (accélération matérielle)

Le serveur délègue l’encodage et le décodage à du matériel dédié (Intel QSV, NVIDIA NVENC, AMD VCE). Le GPU gère le travail de calcul intensif.

Profil de ressources :

• CPU : faible à modéré (gestion du pipeline)
• RAM : modéré
• GPU : le goulot d’étranglement
• Réseau : modéré
• Disque : faible (sauf enregistrement)

Le transcodage matériel est 5 à 10 fois plus rapide et bien plus efficace en énergie que le transcodage logiciel, au prix d’une qualité légèrement inférieure au même débit (l’écart s’est considérablement réduit avec le matériel moderne).

Exigences CPU

Pour le routage passthrough

Le routage passthrough n’est pas limité par le CPU. Le processeur gère l’analyse de protocole (SRT, RTMP, packetisation HLS), le chiffrement/déchiffrement (AES) et la charge système. Les processeurs modernes gèrent cela sans difficulté.

Pour le transcodage logiciel

Le transcodage logiciel est entièrement limité par le CPU. L’encodeur x264 utilise tous les coeurs disponibles. Le preset de qualité détermine le nombre de coeurs nécessaires par flux :

Pour le streaming en direct, les presets veryfast ou faster sont la norme. Ils équilibrent qualité et charge CPU à une latence acceptable. Le preset medium produit une qualité notablement meilleure mais peut nécessiter des coeurs dédiés par flux.

Dimensionnement pratique pour le transcodage logiciel :

Pour le transcodage matériel

Avec Intel QSV ou NVIDIA NVENC, les exigences CPU chutent drastiquement car le travail d’encodage/décodage est effectué sur le GPU. Le CPU gère le pipeline, traite l’audio et exécute l’application de la passerelle :

Le GPU devient le goulot d’étranglement avant le CPU.

Exigences GPU

Intel Quick Sync Video (QSV)

Vajra Cast supporte Intel QSV pour l’encodage et le décodage H.264 et HEVC accélérés matériellement. QSV est intégré aux processeurs Intel (pas besoin de GPU discret) et est disponible sur la plupart des processeurs Intel à partir de la 6e génération (Skylake).

Pour les deployments Linux, Vajra Cast supporte également VAAPI (Video Acceleration API), qui fonctionne avec les GPU Intel et AMD. Le chemin de repli automatique est QSV d’abord, puis VAAPI, garantissant que l’accélération matérielle est utilisée dès qu’elle est disponible.

GPU NVIDIA

Bien que le chemin principal d’accélération matérielle de Vajra Cast soit Intel QSV/VAAPI, NVIDIA NVENC est supporté via l’intégration NVENC de FFmpeg. Les GPU NVIDIA offrent un transcodage haute densité :

Important : les GPU grand public NVIDIA (GeForce) sont limités à 3-5 sessions NVENC simultanées par politique du pilote. Pour un usage production nécessitant plus de sessions, utilisez des GPU datacenter (Tesla, série A) ou utilisez Intel QSV à la place, qui n’a pas de limite artificielle de sessions.

Apple Silicon (série M)

Sur macOS, Vajra Cast exploite VideoToolbox d’Apple pour l’accélération matérielle. Apple Silicon offre d’excellentes performances média :

Le Mac Mini M2 avec 16 Go de RAM est un excellent serveur de streaming économique pour les deployments petits à moyens. Il est silencieux, consomme 10-15 W au repos, et gère 10-20 flux passthrough ou 3-5 transcodages matériels.

Exigences RAM

L’utilisation RAM d’un serveur de streaming évolue avec le nombre de flux simultanément actifs et la taille du tampon par flux.

Utilisation mémoire par flux

Recommandations RAM totales

Bonne pratique : allouez au moins 2 fois votre minimum calculé. Les charges de streaming sont par rafales, et fonctionner près des limites de mémoire risque des OOM (Out of Memory) kills, qui font planter vos flux.

ECC vs. non-ECC

Pour les serveurs de diffusion de production fonctionnant 24h/24 et 7j/7, la mémoire ECC (Error-Correcting Code) est fortement recommandée. L’ECC détecte et corrige les erreurs de bits isolées qui peuvent corrompre les données du flux ou faire planter l’application. Le surcoût de l’ECC est faible par rapport au coût d’une panne en direct.

Les processeurs Intel Xeon et AMD EPYC supportent l’ECC nativement. Les processeurs grand public Intel Core et AMD Ryzen ne le supportent généralement pas (avec quelques exceptions dans la gamme AMD).

Exigences réseau

Le réseau est la ressource la plus souvent sous-estimée dans la planification d’un serveur de streaming.

Calcul de bande passante

Calculez votre besoin total en bande passante :

Bande passante totale = (Somme des débits entrants) + (Somme des débits sortants) + (Surdébit SRT)

Exemple : 5 entrées SRT à 10 Mbps chacune, distribuées vers 3 sorties RTMP et 2 sorties SRT chacune :

Entrées : 5 × 10 Mbps = 50 Mbps
Sorties : 5 × 5 × 10 Mbps = 250 Mbps (5 flux × 5 sorties chacun)
Surdébit SRT : ~25 % sur l'entrée = 12,5 Mbps
Total : ~312,5 Mbps

Cela nécessite au minimum une interface réseau de 1 Gbps avec une marge confortable.

Recommandations d’interface réseau

Considérations réseau

Trames jumbo : activez les trames jumbo (MTU 9000) sur votre réseau local pour le trafic SRT. Cela réduit la charge CPU pour le traitement des paquets et améliore le débit sur les liens 10 Gbps.

Séparez le trafic de gestion et le trafic média : utilisez des interfaces réseau dédiées pour les données de streaming et le trafic de gestion/surveillance. Cela empêche les appels API de surveillance de concurrencer les données de flux en direct.

Bande passante symétrique : les serveurs de streaming nécessitent une bande passante montante égale ou supérieure à la bande passante descendante. Beaucoup de connexions internet grand public sont asymétriques (haut débit descendant, faible débit montant). Utilisez une connectivité professionnelle ou datacenter avec une bande passante symétrique.

Exigences de stockage

Le stockage n’est nécessaire que si vous enregistrez des flux ou écrivez des segments HLS sur disque.

Enregistrement

Calculez le stockage pour l’enregistrement :

Stockage par heure = (Débit en Mbps × 3600) / 8 = Mo par heure

Pour l’enregistrement ISO de 6 caméras à 10 Mbps chacune plus la sortie programme :

7 flux × 4,5 Go/heure = 31,5 Go/heure
Événement de 8 heures = 252 Go

Utilisez des SSD NVMe pour l’enregistrement lors de l’écriture de plusieurs flux simultanés. Les disques mécaniques peuvent gérer 2-3 flux simultanés mais peinent avec 5 ou plus en raison de la latence de recherche. Le NVMe élimine entièrement ce goulot d’étranglement.

Segments HLS

Si vous écrivez les segments HLS sur disque (plutôt que de les servir depuis la mémoire), le besoin en stockage est faible mais les exigences en E/S sont élevées. Les segments HLS sont de petits fichiers écrits fréquemment (un par durée de segment par niveau de qualité) :

Segments de 4 secondes, 4 niveaux de qualité = 1 écriture de fichier par seconde en continu

Utilisez un SSD pour le répertoire de travail HLS. L’espace total est modeste (quelques Go pour la fenêtre live), mais le profil d’E/S exige des performances rapides en écriture aléatoire.

Configuration requise pour Vajra Cast

Voici les exigences spécifiques pour exécuter Vajra Cast :

Configuration minimale

Configuration production recommandée

Deployment Docker

Pour les deployments conteneurisés, Vajra Cast fonctionne dans Docker avec ces considérations :

# extrait docker-compose.yml
services:
  vajracast:
    image: vajracast/vajracast:latest
    network_mode: host  # Requis pour SRT/UDP
    devices:
      - /dev/dri:/dev/dri  # Acces Intel QSV
    volumes:
      - ./data:/data
      - ./recordings:/recordings
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G

Considérations clés pour Docker :

• network_mode: host est requis pour les performances SRT (UDP). Le réseau bridge de Docker ajoute de la latence et complique le mapping de ports pour les SRT listeners.
• Le pass-through du périphérique /dev/dri est requis pour l’accélération matérielle Intel QSV dans les conteneurs Linux.
• Limites mémoire : définissez la limite mémoire du conteneur à au moins 2 fois votre ensemble de travail attendu pour éviter les OOM kills lors des pics de trafic.

Deployment Kubernetes

Pour l’orchestration Kubernetes, Vajra Cast supporte le deployment multi-instances avec PostgreSQL comme base de données partagée :

• Utilisez hostNetwork: true pour les pods gérant le trafic SRT
• Demandez les ressources GPU via le plugin de périphérique Intel pour QSV
• Déployez PostgreSQL en tant que StatefulSet séparé ou utilisez un service de base de données gérée
• Utilisez des volumes persistants pour le stockage d’enregistrement

Directives de mise à l’échelle

Mise à l’échelle verticale (serveur plus puissant)

Ajoutez plus de CPU, de RAM ou un meilleur GPU pour gérer davantage de flux sur un seul serveur :

La mise à l’échelle verticale est plus simple à gérer mais a un plafond. Un seul serveur atteint sa limite autour de 50-100 flux selon la charge de travail.

Mise à l’échelle horizontale (plus de serveurs)

Déployez plusieurs instances Vajra Cast derrière une stratégie de distribution de charge :

Source → Passerelle 1 (flux 1-20)  → Sorties
       → Passerelle 2 (flux 21-40) → Sorties
       → Passerelle 3 (flux 41-60) → Sorties

Chaque passerelle fonctionne indépendamment avec son propre ensemble de flux. Un orchestrateur central (Kubernetes, Terraform ou automatisation personnalisée) gère le deployment et la configuration.

La mise à l’échelle horizontale n’a pas de plafond théorique et fournit une isolation naturelle des pannes : si la Passerelle 2 tombe en panne, les Passerelles 1 et 3 continuent de fonctionner.

Configurations de référence

Configuration 1 : serveur de streaming économique

Cas d’usage : petite production, 5-10 flux passthrough, 1-2 transcodages

Configuration 2 : serveur de production moyen

Cas d’usage : 15-30 flux, 5-10 transcodages, enregistrement ISO

Configuration 3 : serveur broadcast entreprise

Cas d’usage : 50+ flux, transcodage intensif, fonctionnement 24h/24 7j/7

Conclusion

Le choix du matériel pour un serveur de streaming se résume à comprendre votre charge de travail : le routage passthrough nécessite de la bande passante réseau, le transcodage logiciel nécessite des coeurs CPU, et le transcodage matériel nécessite le bon GPU. Commencez par classifier votre charge de travail, calculez vos besoins en utilisant les tableaux ci-dessus, et construisez ou approvisionnez avec au moins 50 % de marge pour la croissance et les pics de charge.

Pour la plupart des deployments, un système Intel milieu de gamme avec QSV (ou un Mac Mini M2 pour les opérations plus petites) offre le meilleur équilibre entre performance, coût et efficacité énergétique. Mettez à l’échelle horizontalement avec Docker ou Kubernetes lorsqu’un seul serveur ne suffit plus.

Explorez le guide de passerelle SRT pour l’architecture logicielle qui tourne sur ce matériel, et consultez les bonnes pratiques de basculement vidéo pour garantir que votre infrastructure reste opérationnelle quand des composants tombent en panne.