Monte ton propre relais de streaming IRL, sur un VPS ou chez toi

Mis à jour : août 2026. Écrit par l'équipe d'Enhanced IRL, y compris les parties qui font de l'auto-hébergement une mauvaise idée pour certains, et celles où ça vaut mieux que de nous payer. Versions utilisées : MediaMTX v1.20.1 et NOALBS v2.19.1.

Ce qu'il te faut

• Un VPS, et pas un gros. Un relais pur remultiplexe des paquets, il ne réencode pas la vidéo : il utilise donc à peine le processeur. 2 vCPU et 2 Go de RAM suffisent pour plusieurs flux. N'achète pas une machine avec GPU pour ça : c'est un autre problème, voir plus bas.
• Un emplacement près de toi. La latence jusqu'au relais est la partie que tu contrôles. Un serveur dans le pays d'où tu diffuses bat toujours un serveur moins cher à trois frontières de là.
• Du trafic sortant généreux. Tes octets entrent une fois et ressortent. À 6 Mbps, ça fait environ 2,7 Go par heure dans chaque sens. Cent heures par mois tournent autour de 270 Go en sortie : dans la plupart des quotas VPS, mais vérifie le tien avant la facture surprise.
• MediaMTX. Un seul binaire open source qui parle RTMP et SRT, aussi bien en entrée qu'en sortie. C'est le cœur du montage, et la partie facile.
• Un récepteur SRTLA, seulement si tu fais du bonding. Si tu agrèges plusieurs modems avec une BELABOX ou Moblin, il te faut en plus quelque chose qui parle SRTLA et le défasse en SRT classique. Le srtla_rec de BELABOX, ou un fork maintenu, fait ça. C'est la partie délicate.
• NOALBS, et un OBS à piloter. Le changement de scènes automatique ne fait pas partie du relais. C'est un outil open source à part qui surveille ton bitrate et pilote OBS. Sans lui, une mauvaise connexion se traduit par une image figée jusqu'à ce que tu retrouves un clavier.
• Un moyen de savoir que c'est cassé. De la supervision sur le port d'entrée. Sans ça, tu apprends que tu es hors ligne parce que le chat te le dit.

Comment tout s'emboîte

La forme du système, dans l'ordre où on le construit. Le reste de la page, c'est chaque étape en détail :

1. Installe MediaMTX sur le serveur. Lance-le comme service pour qu'il revienne après un redémarrage. Sa configuration tient dans un seul YAML : tu actives les écouteurs RTMP et SRT et tu définis un chemin pour ton flux.
2. Ouvre les ports, et attention au protocole. RTMP c'est TCP 1935. SRT c'est de l'UDP, 8890 par défaut. SRTLA aussi, 5000 par défaut. La panne la plus fréquente de loin, c'est un pare-feu ou un hébergeur qui jette l'UDP en silence : si SRT ne connecte pas mais que RTMP passe, regarde là en premier.
3. Mets de l'authentification devant. Une entrée ouverte est une invitation. MediaMTX peut vérifier des identifiants depuis sa configuration ou déléguer à un point d'accès HTTP à toi. Ne saute pas cette étape et ne compte pas sur un nom de flux difficile à deviner.
4. Ajoute SRTLA si tu fais du bonding. Le récepteur écoute sur son propre port UDP, recompose les liens agrégés et transmet du SRT classique à MediaMTX en conservant l'identifiant du flux. Ton encodeur pointe alors vers une URL srtla:// au lieu de srt://.
5. Décide qui consomme le flux. Soit ton OBS à la maison lit depuis le relais et publie vers Twitch, soit le relais retransmet vers Twitch directement. Le premier te donne scènes et overlays ; le second est plus simple, mais il sort ce que la caméra envoie, sans production par-dessus.
6. Ajoute NOALBS pour qu'une mauvaise connexion ne tue pas le direct. Il interroge le relais sur ton bitrate courant et change de scène dans OBS quand il chute. C'est l'étape qui sépare un relais qui marche à ton bureau d'un relais qui marche dans la rue.
7. Règle la latence SRT. Le paramètre de latence est le tampon qui masque la perte de paquets. Trop bas, chaque paquet perdu se voit ; trop haut, tu ajoutes du délai pour rien. Un point de départ courant est deux à quatre fois ton temps d'aller-retour, puis on ajuste sur une vraie connexion, pas sur un test au bureau.

VPS ou ta propre machine à la maison

Le logiciel est identique dans les deux cas. Ce qui change, c'est le réseau — et le réseau, c'est tout :

• Sur un VPS, tu as une IP publique. Ton encodeur y accède depuis n'importe où avec une SIM, le routage est le problème d'un centre de données, et la machine ne redémarre pas parce que quelqu'un a débranché quelque chose.
• Chez toi, probablement pas. La plupart des connexions domestiques sont derrière du NAT : il faut ouvrir des ports sur la box — TCP 1935, UDP 8890, et UDP 5000 si tu fais du bonding — plus un nom DNS dynamique, parce que ton adresse change.
• Le CGNAT met fin à la discussion. Beaucoup de fibres et toutes les connexions mobiles te placent derrière un CGNAT, où aucune connexion entrante ne t'atteint et où aucun réglage de box n'y change rien. Demande une IPv4 publique à ton opérateur ; si c'est non, le relais à la maison n'est pas une option.
• Ton débit montant devient le plafond. Un flux qui arrive de la rue entre par ta descente et ressort par ta montée, sur la même ligne que tout le reste de la maison. Un centre de données donne du symétrique ; une ligne domestique donne souvent 30 Mbps en montée, moins ce que consomment les autres.
• Tu publies l'adresse IP de chez toi. Qui la découvre sait où se trouve ta maison sur internet, et une ligne résidentielle n'a rien du filtrage qu'un hébergeur place devant une attaque.
• Le local sert vraiment à deux choses. Apprendre toute la pile sans payer un mois de serveur, et diffuser quand l'encodeur est sur le même réseau local que le relais : une installation fixe à la maison, du gameplay, une deuxième caméra dans la pièce d'à côté.

Là où le relais local ne marche pas, c'est précisément le cas pour lequel on le veut le plus : diffuser depuis la rue vers ta propre maison. Tu pointes une connexion mobile instable vers une ligne résidentielle au routage moins bon, sans redondance, avec une box qui redémarre quand ça lui chante, et à une coupure de courant de perdre ton direct — pendant que tu es dehors, sans rien pouvoir toucher. Monte-le en local pour apprendre, puis déplace le relais là où il y a une IP publique avant que ça compte.

Installer MediaMTX

MediaMTX se distribue comme un unique binaire statique sans dépendances. Télécharge la version de ton architecture, place le binaire dans le path et la configuration là où le binaire la cherche. Ici c'est Debian ou Ubuntu sur x86-64 ; adapte le nom de fichier pour de l'arm64.

# Dernière version au moment d'écrire. Vérifie s'il y en a une plus récente avant de copier.
curl -L -o mediamtx.tar.gz \
  https://github.com/bluenviron/mediamtx/releases/download/v1.20.1/mediamtx_v1.20.1_linux_amd64.tar.gz
tar -xzf mediamtx.tar.gz

sudo install -m 755 mediamtx /usr/local/bin/mediamtx
sudo mkdir -p /etc/mediamtx
sudo mv mediamtx.yml /etc/mediamtx/mediamtx.yml

Lancer le binaire depuis une session SSH suffit pour un premier test et pour rien d'autre : il meurt quand tu fermes le terminal et ne revient pas après un redémarrage. Donne-lui une unité systemd dans /etc/systemd/system/mediamtx.service.

[Unit]
Description=MediaMTX
After=network-online.target
Wants=network-online.target

[Service]
# Tous les ports qu'il ouvre sont au-dessus de 1024 : il n'a pas besoin de root.
User=mediamtx
Group=mediamtx
ExecStart=/usr/local/bin/mediamtx /etc/mediamtx/mediamtx.yml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

# Le compte sans privilèges sous lequel tourne le service.
sudo useradd --system --no-create-home --shell /usr/sbin/nologin mediamtx

sudo systemctl daemon-reload
sudo systemctl enable --now mediamtx
sudo systemctl status mediamtx

MediaMTX cherche sa configuration dans une liste d'emplacements, dont /etc/mediamtx/mediamtx.yml, et l'unité ci-dessus lui passe le chemin explicitement de toute façon. Le fichier livré avec la release est long parce qu'il documente chaque option ; la quasi-totalité, ce sont des valeurs par défaut auxquelles tu ne touches pas. Voici ce qui compte pour un relais :

logLevel: info

# Coupe ce que tu ne vas pas utiliser. Moins de ports ouverts, moins de problèmes.
rtsp: false
hls: false
webrtc: false
moq: false

# Entrée 1 : RTMP, sur TCP.
rtmp: true
rtmpAddress: :1935

# Entrée 2 : SRT, sur UDP.
srt: true
srtAddress: :8890

# API de statistiques, liée à localhost. NOALBS y lit le bitrate.
api: true
apiAddress: 127.0.0.1:9997

# Remplacer cette liste supprime l'utilisateur anonyme par défaut, qui peut
# publier et lire n'importe quoi. Ce défaut convient sur un portable et pas
# sur un serveur.
authInternalUsers:
  # Le compte avec lequel ton téléphone ou ton encodeur publie.
  - user: irl
    pass: a-long-random-password
    permissions:
      - action: publish
        path: live
  # Le compte avec lequel ton OBS lit.
  - user: obs
    pass: another-long-random-password
    permissions:
      - action: read
        path: live
  # Administrateur local : donne à NOALBS l'accès à l'API, depuis cette machine seulement.
  - user: any
    pass:
    ips: ['127.0.0.1', '::1']
    permissions:
      - action: api

paths:
  # Un seul chemin nommé. Le flux vit sur "live" et nulle part ailleurs.
  live:
    source: publisher

Deux choses se ratent facilement ici. Le path sous chaque permission est ce qui empêche un utilisateur de publier sous n'importe quel nom qu'il invente : laisse-le vide et la restriction disparaît. Et il n'y a pas de mot de passe par défaut à changer : remplacer authInternalUsers, c'est toute l'étape de sécurité — utilise donc des mots de passe générés, pas tapés à la main.

Ouvre les ports sur le pare-feu, puis vérifie que le service tourne et que les ports écoutent vraiment avant de toucher à autre chose :

# Les deux ports d'entrée. RTMP c'est TCP, SRT c'est UDP : ici le protocole n'est pas optionnel.
sudo ufw allow 1935/tcp
sudo ufw allow 8890/udp

# Le service tourne-t-il, et a-t-il survécu au fichier de configuration ?
systemctl status mediamtx
journalctl -u mediamtx -f

# Les ports sont-ils réellement ouverts ?
ss -lntup | grep -E '1935|8890'

# L'API répond-elle en local ?
curl -s http://127.0.0.1:9997/v3/paths/list

Ce qui casse à cette étape :

• Le service ne démarre pas. Neuf fois sur dix c'est le YAML, et journalctl -u mediamtx nomme la clé fautive. Des tabulations à la place d'espaces, et un espace manquant après les deux-points, sont les coupables habituels.
• Il écoute sur la mauvaise adresse. srtAddress: :8890 écoute sur toutes les interfaces ; 127.0.0.1:8890 n'écoute que sur la machine elle-même et rien ne lui arrivera de l'extérieur. Facile à faire par accident, invisible jusqu'au premier test à distance.
• Le pare-feu de la machine n'est pas le seul pare-feu. La plupart des hébergeurs placent aussi un groupe de sécurité devant l'instance. Ouvre l'UDP là aussi, sinon ufw aura l'air correct pendant que les paquets meurent un saut plus tôt.
• L'API répond, et rien d'autre. C'est l'état attendu tant que les ports ne sont pas joignables de l'extérieur. Ce n'est pas un problème MediaMTX.

Publier dessus, et le relire

Les identifiants voyagent différemment selon le protocole : RTMP les passe en paramètres d'URL, SRT les transporte dans l'identifiant de flux. Remplace SERVER par ton nom d'hôte ou ton adresse, et les mots de passe par les tiens.

# RTMP. Les encodeurs qui séparent « serveur » et « clé » prennent rtmp://SERVER:1935/
# comme serveur et live?user=irl&pass=SECRET comme clé.
rtmp://SERVER:1935/live?user=irl&pass=SECRET

# SRT.
srt://SERVER:8890?streamid=publish:live:irl:SECRET&pkt_size=1316

# Une diffusion de test depuis n'importe quel PC, sans téléphone. Si elle arrive,
# la moitié serveur du montage est terminée.
ffmpeg -re -f lavfi -i testsrc2=size=1280x720:rate=30 -f lavfi -i sine \
  -c:v libx264 -preset veryfast -b:v 3000k -g 60 -c:a aac -b:a 128k \
  -f mpegts "srt://SERVER:8890?streamid=publish:live:irl:SECRET&pkt_size=1316"

Pendant que ça tourne, le chemin devient prêt. Vérifie-le depuis le serveur, puis ajoute l'URL de lecture dans OBS comme source multimédia, en décochant « fichier local » :

# ready:true et un bytesReceived qui monte signifient que le flux arrive et que
# les identifiants ont été acceptés.
curl -s http://127.0.0.1:9997/v3/paths/get/live

# URL pour la source multimédia d'OBS. 2000000 microsecondes = 2 secondes de tampon.
srt://SERVER:8890?streamid=read:live:obs:SECRET&latency=2000000

Le paramètre de latence dans une URL OBS ou ffmpeg s'exprime en microsecondes, alors que les applis mobiles le demandent en millisecondes. Taper 2000 dans OBS donne deux millisecondes de tampon et une image qui s'effondre au premier paquet perdu. Pars de deux à quatre fois ton temps d'aller-retour vers le serveur, puis ajuste sur une vraie connexion mobile.

SRTLA, seulement si tu agrèges des modems

SRTLA est le protocole de BELABOX qui répartit un flux SRT sur plusieurs modems et le recompose à l'arrivée. MediaMTX ne le parle pas : on place donc un récepteur devant, qui écoute sur son propre port UDP, recompose les liens et transmet du SRT classique à MediaMTX en localhost. C'est un proxy de transport : la poignée de main SRT — identifiant et identifiants compris — passe intacte, et un flux agrégé s'authentifie exactement comme un flux direct. À noter : le récepteur du dépôt BELABOX d'origine est documenté par ses propres auteurs comme non supporté et pas destiné à la production ; ce que la plupart des gens font tourner, c'est le fork maintenu ci-dessous.

# Le fork maintenu. Il se compile avec CMake et demande un compilateur C++11
# ainsi que les bibliothèques spdlog et argparse.
git clone https://github.com/OpenIRL/srtla.git
cd srtla && mkdir build && cd build
cmake .. && make

Pointe-le vers le port SRT sur lequel MediaMTX écoute déjà. Donne-lui sa propre unité systemd pour la même raison que MediaMTX : la forme de l'unité est identique, seule la ligne ExecStart change.

# Écoute les liens agrégés sur UDP 5000 et transmet du SRT classique à MediaMTX en localhost.
./srtla_rec --srtla_port 5000 --srt_hostname 127.0.0.1 --srt_port 8890

sudo ufw allow 5000/udp

# Dans Moblin ou BELABOX, le schéma d'URL et le port changent. L'identifiant, non :
#   URL :         srtla://SERVER:5000
#   identifiant : publish:live:irl:SECRET

Ce qui casse ici :

• L'encodeur pointe encore vers srt://. Autre protocole, autre port. Un client SRT qui parle au port SRTLA n'arrive nulle part, et l'erreur affichée ressemble le plus souvent à un échec d'authentification, ce qui t'envoie chercher dans le mauvais fichier.
• Un seul modem contribue. Le bonding exige que l'émetteur sorte chaque socket par une interface précise. Si le téléphone envoie tout par un seul lien, SRTLA n'agrège rien — et aucun log ne le dit.
• L'option « Big packets » de Moblin est activée. Avec elle, la connexion ne s'établit souvent pas du tout. Désactive-la : le symptôme ressemble à une clé refusée.
• MediaMTX voit désormais tous les flux venir de 127.0.0.1. C'est normal : du point de vue de MediaMTX, le client, c'est le récepteur. Cela veut aussi dire qu'une liste ips: sur l'utilisateur qui publie ne filtre plus rien d'utile.

NOALBS : changement de scènes automatique

Les scènes qu'il te faut dans OBS

NOALBS change de scène par leur nom, et les noms de la configuration doivent correspondre à ceux d'OBS caractère pour caractère. C'est de loin la raison la plus fréquente pour laquelle un montage qui a l'air correct ne fait rien du tout :

• Une scène normale. Ta vraie diffusion : le flux du relais en plein écran. Tout ce qui dépasse le seuil bas te met ici.
• Une scène de bitrate bas. Le même flux, cadré pour une image devenue molle : plus petite, recadrée, avec un overlay qui dit que la connexion peine. La diffusion continue et personne n'a à deviner ce qui se passe.
• Une scène hors ligne. Aucun flux. Un carton, une boucle d'attente, de la musique. C'est ce que voient les spectateurs dès que la source se déconnecte, et c'est la différence entre un mauvais moment et un direct mort.
• Des extras optionnels. Les scènes de début, de fin, de confidentialité et de rafraîchissement ont leurs propres commandes de chat si tu les configures. Aucune n'est nécessaire au basculement par bitrate.

Brancher OBS

Dans OBS, Outils → Paramètres du serveur WebSocket : active le serveur, mets un mot de passe et note le port, 4455 par défaut. OBS 28 et suivants embarquent WebSocket v5, ce qu'attend NOALBS v2. Si OBS et NOALBS tournent sur la même machine, laisse ce serveur sur localhost et n'expose le port à rien.

Laisser NOALBS voir le relais

NOALBS doit lire l'API de MediaMTX, et la configuration ci-dessus a délibérément lié cette API à localhost sur le serveur. Ne défais pas ça : redirige plutôt le port en SSH depuis la machine qui fait tourner OBS. L'API reste injoignable depuis internet et NOALBS lui parle comme si elle était locale.

# À lancer sur le PC qui a OBS, et à laisser tourner pendant la diffusion.
ssh -N -L 9997:127.0.0.1:9997 you@SERVER

config.json

Une configuration minimale pour un serveur MediaMTX et sans intégration au chat. Le chat est optionnel : mets-le à null et NOALBS change toujours de scène, il ne répondra simplement pas aux commandes dans ton chat Twitch. Si tu le veux, le README du projet explique comment générer un jeton de bot et remplir le fichier .env.

{
  "user": { "id": null, "name": "yourname", "passwordHash": null },
  "switcher": {
    "bitrateSwitcherEnabled": true,
    "onlySwitchWhenStreaming": true,
    "instantlySwitchOnRecover": true,
    "autoSwitchNotification": false,
    "retryAttempts": 5,
    "triggers": { "low": 800, "rtt": 2500, "offline": 300, "rttOffline": 4000 },
    "switchingScenes": { "normal": "LIVE", "low": "LOW", "offline": "BRB" },
    "streamServers": [
      {
        "streamServer": {
          "type": "Mediamtx",
          "statsUrl": "http://127.0.0.1:9997/v3/paths/get/live"
        },
        "name": "relay",
        "priority": 0,
        "overrideScenes": null,
        "dependsOn": null,
        "enabled": true
      }
    ]
  },
  "software": {
    "type": "Obs",
    "host": "localhost",
    "port": 4455,
    "password": "your-obs-websocket-password"
  },
  "chat": null,
  "optionalScenes": {},
  "optionalOptions": {}
}

Ce qu'il vaut mieux savoir avant de commencer à régler les chiffres :

• Les seuils, c'est à toi de les trouver. low, offline et les déclencheurs RTT dépendent du bitrate auquel tu diffuses vraiment et de la façon dont ta connexion lâche. Les valeurs ci-dessus sont un point de départ, pas une recommandation. Règle-les en marchant dehors, pas à ton bureau.
• retryAttempts, c'est à peu près des secondes. NOALBS interroge une fois par seconde : 5, c'est environ cinq mauvaises lectures d'affilée avant de basculer. Baisse-le et chaque tunnel change ta scène ; monte-le et les spectateurs voient d'abord une image figée.
• Les déclencheurs RTT ne servent qu'en SRT. Avec un serveur MediaMTX, NOALBS lit le temps d'aller-retour dans les statistiques de la connexion SRT. En publiant en RTMP, il n'y a pas de RTT du tout : seuls les seuils de bitrate agissent.
• Le nom du chemin est dans statsUrl. Cette URL se termine par le chemin que tu as défini dans MediaMTX. Pointe-la vers un chemin inexistant et NOALBS verra un flux hors ligne pour toujours, sans la moindre erreur pour l'expliquer.
• onlySwitchWhenStreaming évite les surprises. Activée, elle empêche NOALBS de toucher à tes scènes tant qu'OBS ne diffuse pas réellement. Pratique pendant que tu construis encore ta mise en page.

Vérifie chaque pièce avant d'ajouter la suivante

Toutes les pannes de cette pile se ressemblent vues de l'extérieur : pas d'image. Le construire dans l'ordre et confirmer chaque couche, c'est ce qui ramène une session de débogage à quelques minutes au lieu d'une soirée :

1. MediaMTX est vivant. systemctl status dit active et journalctl n'affiche aucune erreur de configuration. Si ça échoue, rien de ce qui suit ne peut fonctionner.
2. Les ports répondent depuis l'extérieur. Depuis une autre machine, nc -zv SERVER 1935 couvre le TCP. L'UDP ne se teste pas comme ça : publie plutôt un vrai flux SRT de test et regarde le log du serveur.
3. Un flux de test arrive. Lance la commande ffmpeg, puis interroge le chemin de l'API avec curl. Un ready:true avec un bytesReceived qui monte prouve que l'entrée et les identifiants fonctionnent.
4. Ton téléphone arrive aussi. Seulement maintenant, essaie Moblin, BELABOX ou IRL Pro. Si ffmpeg passait et pas le téléphone, le problème est dans les réglages de l'encodeur ou le réseau mobile, pas sur le serveur.
5. OBS lit le flux. Ajoute l'URL de lecture comme source multimédia. Une image dans OBS signifie que tout le chemin fonctionne de bout en bout.
6. NOALBS réagit. Lance-le et regarde son log : il doit annoncer un bitrate chaque seconde. Coupe ensuite le flux de test et vérifie qu'OBS passe tout seul sur la scène hors ligne. Si rien ne bouge, les noms de scènes ne correspondent pas.

Ce que ça coûte vraiment

Les parties vraiment difficiles

• SRTLA, pas SRT. Un relais SRT ou RTMP simple, c'est un projet de week-end. C'est le bonding qui mange le temps : monter le récepteur, le garder debout et comprendre pourquoi un modem n'apporte rien, c'est du vrai travail.
• L'UDP sur internet. Certains hébergements maltraitent ou jettent l'UDP, et certaines fonctions cloud le cassent de façons non documentées. Les IP réservées ou flottantes sont un classique. Quand SRT échoue et que RTMP marche, soupçonne le réseau avant le logiciel.
• Il n'y a pas d'anti-coupure. Un serveur, c'est un point de défaillance unique. S'il redémarre pour maintenance pendant ton direct, le direct s'arrête. Régler ça correctement demande une deuxième machine et quelque chose qui garde la connexion à la plateforme en vie, ce qui est un projet à part entière.
• La sécurité devient la tienne. Des ports d'entrée publics, des binaires open source à tenir à jour et une machine Linux sur internet. Rien d'exotique, mais c'est une corvée récurrente qui ne prévient jamais.
• Ça ne te donne pas Cloud OBS. Un relais déplace de la vidéo. Faire tourner OBS lui-même dans le cloud demande une machine avec GPU, une session de bureau et un moyen de la piloter à distance, et un GPU loué coûte plusieurs fois ce VPS. Si ce que tu veux, c'est diffuser sans PC à la maison, auto-héberger un relais ne t'y amène pas.

Quand auto-héberger et quand non

Il n'y a pas de réponse universelle. En gros :

• Auto-héberge si tu administres déjà des serveurs. Si une unité systemd et une règle de pare-feu sont un après-midi normal pour toi et que ça te plaît, tu obtiendras exactement ce que tu veux en payant moins.
• Auto-héberge si tu diffuses beaucoup d'heures. Les chiffres s'améliorent à mesure que tu utilises une machine que tu loues en permanence.
• Auto-héberge s'il te faut une région inhabituelle. Si tu diffuses depuis un endroit qu'aucun fournisseur ne couvre bien, un VPS près de toi bat un relais géré lointain, aussi bon soit le service.
• N'auto-héberge pas si tu diffuses quelques heures par semaine. Tu paies un mois entier de serveur pour en utiliser une poignée d'heures, et tu prends la maintenance en prime.
• N'auto-héberge pas s'il te faut du bonding et que ça ne t'amuse pas. SRTLA est la partie qui va te coûter des soirées. Si le bonding est essentiel à ton direct, sois honnête sur ton envie d'en faire ton problème.
• N'auto-héberge pas si tu veux arrêter de déboguer à 2 h du matin. Ce que vend vraiment un relais géré, ce n'est pas le serveur. C'est de ne pas être d'astreinte sur ton propre direct.

Vous hésitez encore à gérer tout cela vous-même ? Les trois voies, chiffrées côte à côte : Serveur de streaming IRL : ce que c'est et lequel choisir.

Questions fréquentes

Les projets sur lesquels tout ça repose

• MediaMTX, le serveur multimédia (bluenviron/mediamtx)
• NOALBS, changement de scènes automatique pour OBS, par 715209 et b3ck
• srtla, l'implémentation originale de BELABOX
• srtla, le fork maintenu du récepteur

Utile même en auto-hébergement

Ces guides font partie de notre documentation produit, mais les parties protocole, encodeur et changement de scènes valent pour n'importe quel relais, le nôtre ou le tien :

• Choisir un protocole : RTMP, SRT ou SRTLA
• Diffuser avec Moblin
• Diffuser avec BELABOX
• Changement de scènes automatique dans ton propre OBS
• Utiliser ton propre OBS avec un relais

À lire ensuite

• Comparer les services de streaming IRL : quoi vérifier avant de changer
• Enhanced IRL face à IRLToolkit, point par point