SRT Streaming avec Raspberry Pi : construire un relais SRT portable

Pourquoi un Raspberry Pi pour le SRT

Un Raspberry Pi coûte entre 50 et 80 EUR, consomme moins de 15 W et tient dans la paume de la main. C’est suffisant pour faire tourner un relais SRT capable de recevoir un flux, le re-chiffrer et le retransmettre vers une ou plusieurs destinations. Pour les équipes terrain qui ont besoin d’un point de relais léger, d’un encodeur de test ou d’un noeud SRT déporté, c’est une option difficile à battre en rapport coût/encombrement.

Le cas d’usage typique : vous avez un encodeur sur site qui pousse un flux SRT vers un relais Raspberry Pi connecté à une liaison fibre ou Starlink. Le Pi reçoit le flux, le transfère vers votre passerelle SRT principale au studio. Vous obtenez un point de présence SRT sans déployer un serveur complet.

Ce guide couvre l’installation complète, de la préparation du matériel à la connexion avec Vajra Cast.

Matériel requis

Choix du Raspberry Pi

Le Raspberry Pi 4 (4 Go) est le minimum viable. Le Raspberry Pi 5 (4 ou 8 Go) est recommandé pour le relais multi-flux ou l’encodage.

ModèleCPURAMDébit SRT max estiméUsage
Pi 4 (4 Go)Cortex-A72 4x 1.8 GHz4 Go~50 Mbps relaisRelais mono-flux
Pi 5 (4 Go)Cortex-A76 4x 2.4 GHz4 Go~120 Mbps relaisRelais multi-flux
Pi 5 (8 Go)Cortex-A76 4x 2.4 GHz8 Go~120 Mbps relaisRelais + encodage léger

Ne pas utiliser le Pi 3 ni le Pi Zero : le CPU est trop faible pour gérer la retransmission de paquets SRT à des débits exploitables.

Réseau

Le port Ethernet Gigabit du Pi 4 et du Pi 5 est connecté via un bus PCIe, pas via USB comme sur le Pi 3. Vous obtenez un vrai débit Gigabit. Utilisez toujours une connexion filaire pour le SRT. Le Wi-Fi introduit de la gigue et de la perte de paquets qui sapent les avantages du protocole.

Si vous devez connecter le Pi à un réseau cellulaire ou Starlink, utilisez un adaptateur USB-Ethernet vers le routeur concerné.

Autres composants

  • Alimentation USB-C 5V 3A minimum (officielle recommandée)
  • Carte microSD de 32 Go minimum, classe A2 (ou SSD NVMe via le HAT Pi 5 pour de meilleures performances I/O)
  • Boîtier avec dissipation thermique passive ou ventilateur (le Pi 5 chauffe sous charge réseau soutenue)

Installation de SRT et FFmpeg

Partez d’une installation fraîche de Raspberry Pi OS Lite (64-bit, basé sur Debian Bookworm). La version Lite suffit, pas besoin d’interface graphique.

Mise à jour du système

sudo apt update && sudo apt upgrade -y

Installation de libsrt

Le paquet libsrt est disponible dans les dépôts Debian Bookworm. Installez la bibliothèque et les outils en ligne de commande :

sudo apt install -y libsrt-openssl-dev srt-tools

Vérifiez l’installation :

srt-live-transmit --version

srt-live-transmit est l’outil de base pour relayer un flux SRT d’une source vers une destination. C’est le couteau suisse du relais SRT.

Installation de FFmpeg avec support SRT

Le FFmpeg des dépôts Debian est compilé avec le support SRT. Installez-le :

sudo apt install -y ffmpeg

Vérifiez que le support SRT est présent :

ffmpeg -protocols 2>&1 | grep srt

Vous devez voir srt dans la liste des protocoles d’entrée et de sortie. Si ce n’est pas le cas, vous devrez compiler FFmpeg depuis les sources avec --enable-libsrt. Sur Bookworm, le paquet standard inclut SRT par défaut.

Configurer un listener SRT sur le Pi

Le scénario le plus simple : le Pi écoute sur un port SRT et attend qu’un encodeur (caller) se connecte pour envoyer son flux.

Avec srt-live-transmit

srt-live-transmit "srt://:9000?mode=listener&latency=500" \
  "srt://:9001?mode=listener&latency=500" -v

Cette commande crée un relais : elle écoute sur le port 9000 (entrée) et met le flux à disposition sur le port 9001 (sortie). Un encodeur se connecte au port 9000 en mode caller, un lecteur ou une passerelle se connecte au port 9001 en mode caller.

Pour ajouter le chiffrement :

srt-live-transmit \
  "srt://:9000?mode=listener&latency=500&passphrase=MaCleSecurisee2026&pbkeylen=32" \
  "srt://:9001?mode=listener&latency=500&passphrase=AutreCleSecurisee2026&pbkeylen=32" -v

Vous pouvez utiliser des passphrases différentes en entrée et en sortie. C’est utile quand l’équipe terrain et l’équipe studio ont des clés distinctes.

Avec FFmpeg

FFmpeg offre plus de flexibilité si vous avez besoin de transcoder ou de modifier le flux au passage :

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy \
  -f mpegts "srt://:9001?mode=listener&latency=500"

Le -c copy signifie que FFmpeg ne transcode pas. Il reçoit le flux MPEG-TS, le démultiplexe et le remultiplexe en sortie. Le coût CPU est minimal. Si vous avez besoin de transcoder (par exemple, réduire le débit), remplacez -c copy par les paramètres d’encodage appropriés, mais sachez que l’encodage H.264 logiciel sur un Pi est limité à environ 720p30 sur un Pi 5.

Configuration en mode relais

Le cas d’usage principal d’un Pi SRT est le relais : recevoir un flux et le retransmettre vers une destination distante.

Relais caller-to-caller

Le Pi reçoit un flux d’un encodeur de terrain (le Pi est listener) et le pousse vers une passerelle distante (le Pi est caller) :

srt-live-transmit \
  "srt://:9000?mode=listener&latency=500" \
  "srt://passerelle.example.com:9000?mode=caller&latency=800" -v

La latence côté sortie est plus élevée (800 ms) car le trajet vers la passerelle distante traverse internet. Adaptez cette valeur selon votre RTT réel (mesurez-le avec ping et multipliez par 4). Consultez le guide d’optimisation de la latence SRT pour les détails.

Relais avec duplication

Pour envoyer le même flux vers deux destinations simultanément avec FFmpeg :

ffmpeg -i "srt://:9000?mode=listener&latency=500" \
  -c copy -f mpegts "srt://dest1.example.com:9000?mode=caller&latency=800" \
  -c copy -f mpegts "srt://dest2.example.com:9001?mode=caller&latency=800"

Le Pi 5 gère sans problème deux sorties SRT à 15 Mbps chacune en mode copie. Au-delà de trois sorties simultanées, surveillez la charge CPU et le débit réseau.

Service systemd

Pour que le relais démarre automatiquement au boot, créez un service systemd :

sudo tee /etc/systemd/system/srt-relay.service << 'EOF'
[Unit]
Description=SRT Relay Service
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/srt-live-transmit \
  "srt://:9000?mode=listener&latency=500&passphrase=MaCleSecurisee2026&pbkeylen=32" \
  "srt://passerelle.example.com:9000?mode=caller&latency=800&passphrase=ClePasSerelle2026&pbkeylen=32" \
  -v
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now srt-relay.service

Le Restart=always avec RestartSec=5 garantit que le relais redémarre automatiquement en cas de coupure de la connexion SRT.

Connexion à Vajra Cast

Vajra Cast fonctionne comme passerelle SRT centrale. Le Pi pousse son flux vers Vajra Cast en mode caller, Vajra Cast expose un listener SRT qui attend la connexion.

Côté Vajra Cast :

  1. Créez un Ingest SRT en mode Listener sur le port de votre choix (par exemple 9000)
  2. Activez le chiffrement AES-256 avec une passphrase
  3. Réglez la latence selon la distance réseau avec le Pi

Côté Pi :

srt-live-transmit \
  "srt://:9000?mode=listener&latency=300" \
  "srt://vajracast.example.com:9000?mode=caller&latency=800&passphrase=CleVajraCast2026&pbkeylen=32" -v

Une fois connecté, Vajra Cast affiche les statistiques SRT du flux en temps réel : RTT, perte de paquets, taux de retransmission, débit. Vous pouvez ensuite router ce flux vers des sorties multiples (RTMP, HLS, SRT) directement depuis l’interface. Consultez le guide de configuration SRT pour les détails sur les paramètres d’ingest.

Pour les déploiements multi-sites, chaque Pi terrain pousse vers la même instance Vajra Cast sur des ports distincts. La passerelle centralise la réception, la surveillance et la redistribution de tous les flux.

Optimisation des performances

Paramètres réseau du noyau

Le noyau Linux par défaut n’est pas optimisé pour le trafic UDP à haut débit. Augmentez les tampons réseau :

sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.wmem_max=26214400
sudo sysctl -w net.core.rmem_default=1048576
sudo sysctl -w net.core.wmem_default=1048576

Pour rendre ces changements permanents :

echo -e "net.core.rmem_max=26214400\nnet.core.wmem_max=26214400\nnet.core.rmem_default=1048576\nnet.core.wmem_default=1048576" | sudo tee /etc/sysctl.d/90-srt.conf
sudo sysctl --system

Gestion thermique

Sous charge réseau soutenue, le Pi 5 peut atteindre 75-80°C sans refroidissement actif. Au-delà de 85°C, le CPU throttle et les performances du relais se dégradent. Utilisez un boîtier avec ventilateur ou un dissipateur thermique surdimensionné. Surveillez la température :

vcgencmd measure_temp

Si vous déployez le Pi dans un environnement chaud (armoire technique, extérieur en été), le ventilateur actif est obligatoire.

Priorité CPU

Donnez la priorité au processus SRT pour éviter que d’autres tâches système ne provoquent des interruptions :

sudo nice -n -10 srt-live-transmit "srt://:9000?mode=listener" "srt://dest:9000?mode=caller" -v

Ou ajoutez Nice=-10 dans la section [Service] de votre fichier systemd.

Cas d’usage réels

Noeud SRT déporté en régie mobile

Une équipe de production mobile place un Pi 5 dans chaque régie mobile de stade. Le Pi reçoit le flux du mélangeur local en SRT via le réseau LAN, le chiffre en AES-256 et le pousse vers la passerelle SRT Vajra Cast au studio central. Coût par point : moins de 100 EUR de matériel. Le Pi tourne 24h/24, sans maintenance.

Encodeur de backup léger

Un Pi 5 équipé d’une carte d’acquisition USB HDMI (type Elgato Cam Link ou équivalent à 20 EUR) peut encoder un flux 1080p30 en H.264 à 5-8 Mbps avec FFmpeg :

ffmpeg -f v4l2 -video_size 1920x1080 -framerate 30 -i /dev/video0 \
  -c:v libx264 -preset ultrafast -tune zerolatency -b:v 5M \
  -f mpegts "srt://passerelle:9000?mode=caller&latency=800"

Ce n’est pas un encodeur de production principal, mais c’est un backup acceptable pour un coût dérisoire.

Réseau de monitoring distribué

Plusieurs Pi déployés sur différents sites reçoivent chacun un flux SRT local et le relaient vers une instance Vajra Cast centralisée. L’opérateur surveille tous les flux depuis un tableau de bord unique. C’est l’architecture typique des réseaux de diffusion régionaux ou des campus multi-bâtiments. Consultez le guide sur les protocoles SRT pour comprendre les modes de connexion dans ce type d’architecture distribuée.

Limites

Le Raspberry Pi n’est pas un serveur. Connaître ses limites évite les mauvaises surprises en production.

Encodage matériel limité. Le VideoCore du Pi ne supporte pas l’encodage H.264 via FFmpeg de manière fiable à haute résolution. L’encodage se fait en logiciel sur les cœurs ARM, ce qui limite la qualité et la résolution. Pour un encodage sérieux, utilisez un vrai serveur ou un encodeur dédié.

Pas de redondance native. Un Pi est un point de défaillance unique. Si la carte SD lâche ou si le noyau plante, le relais tombe. Pour les productions critiques, prévoyez un second Pi en standby ou utilisez directement Vajra Cast sur un serveur avec les mécanismes de basculement automatique.

Débit plafonné. En mode relais pur (copie sans transcodage), le Pi 5 gère environ 100-120 Mbps de débit SRT agrégé. C’est largement suffisant pour un ou deux flux HD, mais insuffisant pour du multi-flux 4K.

Pas d’interface de gestion. Contrairement à Vajra Cast qui offre un tableau de bord web complet avec métriques en temps réel, le Pi avec srt-live-transmit ne fournit qu’une sortie console. Pour un monitoring correct, redirigez les logs vers un système de collecte ou utilisez Vajra Cast comme point de terminaison qui vous donne la visibilité.

Alimentation. Le Pi est sensible aux micro-coupures d’alimentation. Utilisez une alimentation de qualité et, en déploiement terrain, un petit UPS USB pour absorber les coupures brèves.

Malgré ces limites, un Raspberry Pi configuré correctement est un noeud SRT fiable pour le relais et les cas d’usage légers. Pour tout ce qui dépasse le simple relais mono-flux, Vajra Cast sur un serveur dédié reste la solution de référence.