Monta tu propio relay de streaming IRL, en un VPS o en casa

Actualizado: agosto de 2026. Escrito por el equipo de Enhanced IRL, incluidas las partes que hacen del autohospedaje una mala idea para algunas personas y las partes en las que sale mejor que pagarnos. Versiones usadas: MediaMTX v1.20.1 y NOALBS v2.19.1.

Qué necesitas

• Un VPS, y no grande. Un relay puro remultiplexa paquetes, no recodifica vídeo, así que apenas usa CPU. Con 2 vCPU y 2 GB de RAM te sobra para varias emisiones. No compres una máquina con GPU para esto: es otro problema, lo ves más abajo.
• Una ubicación cerca de ti. La latencia hasta el relay es la parte que controlas. Un servidor en el país desde el que emites gana siempre a uno más barato a tres fronteras de distancia.
• Tráfico de salida holgado. Tus bytes entran una vez y vuelven a salir. A 6 Mbps son unos 2,7 GB por hora en cada sentido. Cien horas al mes rondan los 270 GB de salida: dentro de casi cualquier cuota de VPS, pero mira la tuya antes de llevarte una factura de sorpresa.
• MediaMTX. Un único binario de código abierto que habla RTMP y SRT, tanto para recibir como para entregar la emisión. Es el núcleo del montaje y la parte fácil.
• Un receptor SRTLA, solo si haces bonding. Si juntas varios módems con una BELABOX o con Moblin, necesitas además algo que hable SRTLA y lo deshaga en SRT normal. El srtla_rec de BELABOX, o un fork mantenido, hace eso. Esta es la parte delicada.
• NOALBS, y un OBS al que apuntarlo. El cambio de escenas automático no forma parte del relay. Es una herramienta de código abierto aparte que vigila tu bitrate y maneja OBS. Sin ella, una conexión mala se traduce en una imagen congelada hasta que vuelves a un teclado.
• Una forma de enterarte de que se ha roto. Monitorización del puerto de entrada. Sin ella te enteras de que estás caído porque te lo dice el chat.

Cómo encaja todo

La forma del sistema, en el orden en que se construye. El resto de la página es cada paso entero:

1. Instala MediaMTX en el servidor. Déjalo como servicio para que vuelva solo tras un reinicio. Su configuración es un único YAML: activas los listeners de RTMP y SRT y defines una ruta para tu emisión.
2. Abre los puertos, y ojo con el protocolo. RTMP es TCP 1935. SRT es UDP y por defecto el 8890. SRTLA también es UDP, por defecto el 5000. El fallo más común con diferencia es un cortafuegos o un proveedor que descarta UDP en silencio: si SRT no conecta pero RTMP sí, mira ahí primero.
3. Pon autenticación delante. Una entrada abierta es una invitación. MediaMTX puede comprobar credenciales desde su configuración o delegar en un endpoint HTTP tuyo. No te lo saltes, y no confíes en que el nombre de la emisión sea difícil de adivinar.
4. Añade SRTLA si haces bonding. El receptor escucha en su propio puerto UDP, recompone los enlaces agregados y reenvía SRT normal a MediaMTX conservando el identificador de la emisión. Tu encoder apunta entonces a una URL srtla:// en vez de srt://.
5. Decide quién consume la emisión. O tu OBS de casa lee del relay y publica en Twitch, o el relay reenvía a Twitch directamente. Lo primero te da escenas y overlays; lo segundo es más simple, pero sale lo que manda la cámara y sin producción encima.
6. Añade NOALBS para que una mala conexión no sea un directo muerto. Consulta al relay tu bitrate actual y cambia de escena en OBS cuando cae. Este es el paso que separa un relay que funciona en tu escritorio de uno que funciona en la calle.
7. Ajusta la latencia de SRT. El parámetro de latencia es el colchón que esconde la pérdida de paquetes. Muy bajo y cada paquete perdido se ve; muy alto y añades retardo para nada. Un punto de partida habitual es entre dos y cuatro veces tu tiempo de ida y vuelta, y a partir de ahí se ajusta contra una conexión real, no en una prueba de escritorio.

VPS o tu propia máquina en casa

El software es idéntico en los dos casos. Lo que cambia es la red, y la red es todo.

• En un VPS tienes IP pública. Tu encoder llega desde cualquier sitio con una SIM, el enrutado es problema de un centro de datos y la máquina no se reinicia porque alguien ha desenchufado algo.
• En casa probablemente no. Casi todas las conexiones domésticas están detrás de NAT, así que necesitas abrir puertos en el router (TCP 1935, UDP 8890 y UDP 5000 si haces bonding) y además un nombre de DNS dinámico, porque tu dirección cambia.
• Con CGNAT se acaba la conversación. Muchas fibras y todas las conexiones móviles te ponen detrás de un CGNAT, donde no te llega ninguna conexión entrante y no hay ajuste del router que lo arregle. Pide a tu operador una IPv4 pública; si la respuesta es no, el relay en casa no es una opción.
• Tu subida de casa pasa a ser el techo. Una emisión que llega desde la calle entra por tu bajada y vuelve a salir por tu subida, compartiendo línea con todo lo demás de la casa. Un centro de datos te da ancho de banda simétrico; una línea doméstica suele darte 30 Mbps de subida, menos lo que consuman los demás.
• Estás publicando la IP de tu casa. Quien la averigüe sabe dónde está tu casa en internet, y una línea residencial no tiene nada del filtrado que un proveedor pone delante de un ataque.
• El montaje local sirve de verdad para dos cosas. Aprender todo el stack sin pagar un mes de servidor, y emitir con el encoder en la misma red local que el relay: un montaje fijo en casa, gameplay, una segunda cámara en la habitación de al lado.

Donde el relay local no sirve es justo para lo que más gente lo quiere: emitir desde la calle contra tu propia casa. Estás apuntando una conexión móvil inestable a una línea residencial con peor enrutado, sin redundancia, con un router que se reinicia cuando le apetece y a un corte de luz de quedarte sin directo, mientras tú estás fuera y no puedes tocar nada. Móntalo en local para aprenderlo y luego lleva el relay a un sitio con IP pública antes de que importe.

Instalar MediaMTX

MediaMTX se distribuye como un único binario estático sin dependencias. Descarga la versión de tu arquitectura, deja el binario en el path y la configuración donde el binario la busca. Esto es Debian o Ubuntu sobre x86-64; cambia el nombre del fichero si vas en arm64.

# Última versión al escribir esto. Comprueba si hay una más nueva antes de copiar.
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

Ejecutar el binario desde una sesión SSH vale para la primera prueba y para nada más: se muere al cerrar el terminal y no vuelve tras un reinicio. Dale un servicio de systemd en /etc/systemd/system/mediamtx.service.

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

[Service]
# Todos los puertos que abre están por encima del 1024, así que no necesita root.
User=mediamtx
Group=mediamtx
ExecStart=/usr/local/bin/mediamtx /etc/mediamtx/mediamtx.yml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

# La cuenta sin privilegios con la que corre el servicio.
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 busca su configuración en una lista de ubicaciones, entre ellas /etc/mediamtx/mediamtx.yml, y el servicio de arriba le pasa la ruta explícitamente de todas formas. El fichero que viene con la release es largo porque documenta todas las opciones; casi todo son valores por defecto que no vas a tocar. Esto es lo que importa para un relay:

logLevel: info

# Apaga lo que no vas a usar. Menos puertos abiertos, menos problemas.
rtsp: false
hls: false
webrtc: false
moq: false

# Entrada 1: RTMP, sobre TCP.
rtmp: true
rtmpAddress: :1935

# Entrada 2: SRT, sobre UDP.
srt: true
srtAddress: :8890

# API de estadísticas, atada a localhost. NOALBS lee el bitrate de aquí.
api: true
apiAddress: 127.0.0.1:9997

# Sustituir esta lista elimina el usuario anónimo por defecto, que puede
# publicar y leer cualquier cosa. Ese valor está bien en un portátil y mal
# en un servidor.
authInternalUsers:
  # La cuenta con la que publica tu móvil o tu encoder.
  - user: irl
    pass: a-long-random-password
    permissions:
      - action: publish
        path: live
  # La cuenta con la que lee tu OBS.
  - user: obs
    pass: another-long-random-password
    permissions:
      - action: read
        path: live
  # Administrador local: permite a NOALBS consultar la API, solo desde esta máquina.
  - user: any
    pass:
    ips: ['127.0.0.1', '::1']
    permissions:
      - action: api

paths:
  # Una única ruta con nombre. La emisión vive en "live" y en ningún otro sitio.
  live:
    source: publisher

Dos cosas se tuercen con facilidad ahí. El path de cada permiso es lo que impide que un usuario publique con el nombre que se invente: si lo dejas vacío, la restricción desaparece. Y no hay contraseña por defecto que cambiar: sustituir authInternalUsers es todo el paso de seguridad, así que usa contraseñas generadas, no escritas a mano.

Abre los puertos en el cortafuegos y comprueba que el servicio está arriba y que los puertos escuchan de verdad antes de tocar nada más:

# Los dos puertos de entrada. RTMP es TCP y SRT es UDP: aquí el protocolo no es opcional.
sudo ufw allow 1935/tcp
sudo ufw allow 8890/udp

# ¿El servicio está corriendo y ha sobrevivido al fichero de configuración?
systemctl status mediamtx
journalctl -u mediamtx -f

# ¿Los puertos están escuchando de verdad?
ss -lntup | grep -E '1935|8890'

# ¿Responde la API en local?
curl -s http://127.0.0.1:9997/v3/paths/list

Qué se tuerce en este paso:

• El servicio no arranca. Nueve de cada diez veces es el YAML, y journalctl -u mediamtx te dice qué clave le molesta. Tabuladores en vez de espacios, y un espacio que falta después de los dos puntos, son los culpables habituales.
• Escucha en la dirección equivocada. srtAddress: :8890 escucha en todas las interfaces; 127.0.0.1:8890 escucha solo en la propia máquina y no le llegará nada de fuera. Es fácil hacerlo sin querer e invisible hasta que pruebas en remoto.
• El cortafuegos de la máquina no es el único cortafuegos. Casi todos los proveedores ponen además un grupo de seguridad delante de la instancia. Abre UDP también ahí, o ufw parecerá correcto mientras los paquetes mueren un salto antes.
• La API responde y nada más responde. Es el estado esperado antes de que los puertos sean accesibles desde fuera. No es un problema de MediaMTX.

Publicar en él y leerlo de vuelta

Las credenciales viajan de forma distinta en cada protocolo: RTMP las pasa como parámetros de consulta y SRT las lleva dentro del identificador de la emisión. Cambia SERVER por tu nombre de host o dirección, y las contraseñas por las que hayas puesto.

# RTMP. Los encoders que separan "servidor" y "clave" toman rtmp://SERVER:1935/
# como servidor y live?user=irl&pass=SECRET como clave.
rtmp://SERVER:1935/live?user=irl&pass=SECRET

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

# Una emisión de prueba desde cualquier PC, sin móvil de por medio. Si llega,
# la mitad de servidor del montaje está terminada.
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"

Mientras eso corre, la ruta pasa a estar lista. Compruébalo desde el servidor y luego añade la URL de lectura a OBS como fuente multimedia, con «archivo local» desmarcado:

# ready:true y un bytesReceived que sube significan que la emisión está llegando
# y que las credenciales se han aceptado.
curl -s http://127.0.0.1:9997/v3/paths/get/live

# URL para la fuente multimedia de OBS. 2000000 microsegundos = 2 segundos de colchón.
srt://SERVER:8890?streamid=read:live:obs:SECRET&latency=2000000

El parámetro de latencia en una URL de OBS o de ffmpeg va en microsegundos, mientras que las apps de móvil lo piden en milisegundos. Poner 2000 en OBS te da dos milisegundos de colchón y una imagen que se cae con el primer paquete perdido. Empieza por dos a cuatro veces tu tiempo de ida y vuelta hasta el servidor y ajústalo contra una conexión móvil real.

SRTLA, solo si haces bonding de módems

SRTLA es el protocolo de BELABOX que reparte una emisión SRT entre varios módems y la recompone al otro lado. MediaMTX no lo habla, así que pones un receptor delante: escucha en su propio puerto UDP, recompone los enlaces y reenvía SRT normal a MediaMTX por localhost. Es un proxy de transporte, así que el handshake de SRT (identificador y credenciales incluidos) pasa intacto y una emisión agregada se autentica igual que una directa. Ojo: el receptor del repositorio original de BELABOX está documentado por sus propios autores como no soportado y no apto para producción; lo que ejecuta casi todo el mundo es el fork mantenido de abajo.

# El fork mantenido. Se compila con CMake y necesita un compilador de C++11
# y las bibliotecas spdlog y argparse.
git clone https://github.com/OpenIRL/srtla.git
cd srtla && mkdir build && cd build
cmake .. && make

Apúntalo al puerto SRT en el que MediaMTX ya escucha. Dale su propio servicio de systemd por la misma razón por la que se lo diste a MediaMTX: la forma del servicio es idéntica, solo cambia la línea ExecStart.

# Escucha enlaces agregados en UDP 5000 y entrega SRT normal a MediaMTX en localhost.
./srtla_rec --srtla_port 5000 --srt_hostname 127.0.0.1 --srt_port 8890

sudo ufw allow 5000/udp

# En Moblin o BELABOX cambian el esquema de la URL y el puerto. El identificador no:
#   URL:            srtla://SERVER:5000
#   identificador:  publish:live:irl:SECRET

Qué se tuerce aquí:

• El encoder sigue apuntando a srt://. Otro protocolo y otro puerto. Un cliente SRT hablando al puerto de SRTLA no llega a ninguna parte, y el error que muestra suele parecer un fallo de autenticación, lo que te manda a buscar en el fichero equivocado.
• Solo aporta un módem. El bonding necesita que el emisor saque cada socket por una interfaz concreta. Si el móvil manda todo por un enlace, SRTLA no agrega nada, y no hay ningún log que te lo diga.
• Moblin tiene activado «Big packets». Con esa opción encendida, muchas veces la conexión ni siquiera se establece. Desactívala: el síntoma parece una clave rechazada.
• Ahora MediaMTX ve todas las emisiones viniendo de 127.0.0.1. Es lo esperado: para MediaMTX el cliente es el receptor. También significa que una lista ips: en el usuario que publica ya no filtra nada útil.

NOALBS: cambio de escenas automático

Las escenas que necesitas en OBS

NOALBS cambia de escena por nombre, y los nombres de la configuración deben coincidir con los de OBS carácter a carácter. Esta es, con diferencia, la razón más común de que un montaje que parece correcto no haga absolutamente nada:

• Una escena normal. Tu emisión de verdad: la señal del relay a pantalla completa. Todo lo que esté por encima del umbral bajo te deja aquí.
• Una escena de bitrate bajo. La misma señal, encuadrada para una imagen que se ha vuelto blanda: más pequeña, recortada, con un overlay que dice que la conexión va justa. La emisión sigue y nadie tiene que adivinar qué pasa.
• Una escena offline. Sin señal ninguna. Una tarjeta, un bucle de espera, música. Es lo que ve tu audiencia en cuanto la fuente se desconecta, y es la diferencia entre un mal rato y un directo muerto.
• Extras opcionales. Las escenas de inicio, cierre, privacidad y refresco tienen sus propios comandos de chat si las configuras. Ninguna hace falta para que el cambio por bitrate funcione.

Conectar OBS

En OBS, Herramientas → Ajustes del servidor WebSocket: activa el servidor, pon una contraseña y apunta el puerto, el 4455 por defecto. OBS 28 y posteriores traen WebSocket v5, que es lo que espera NOALBS v2. Si OBS y NOALBS corren en la misma máquina, deja ese servidor en localhost y no expongas el puerto a nada.

Dejar que NOALBS vea el relay

NOALBS necesita leer la API de MediaMTX, y la configuración de arriba ató esa API a localhost en el servidor a propósito. No lo deshagas: redirige el puerto por SSH desde la máquina que ejecuta OBS. La API sigue siendo inalcanzable desde internet y NOALBS le habla como si fuera local.

# Ejecútalo en el PC que tiene OBS y déjalo corriendo mientras emites.
ssh -N -L 9997:127.0.0.1:9997 you@SERVER

config.json

Una configuración mínima para un servidor MediaMTX y sin integración con el chat. El chat es opcional: ponlo a null y NOALBS sigue cambiando de escena, solo que no responderá a comandos en tu chat de Twitch. Si lo quieres, el README del proyecto explica cómo generar un token de bot y rellenar el fichero .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": {}
}

Cosas que conviene saber antes de ponerte a afinar los números:

• Los umbrales los tienes que encontrar tú. low, offline y los disparadores de RTT dependen del bitrate al que emites de verdad y de cómo falla tu conexión. Los valores de arriba son un punto de partida, no una recomendación. Ajústalos andando por la calle, no en el escritorio.
• retryAttempts son más o menos segundos. NOALBS consulta una vez por segundo, así que 5 son unas cinco lecturas malas seguidas antes de cambiar. Bájalo y cada túnel te cambia de escena; súbelo y tu audiencia se come antes una imagen congelada.
• Los disparadores de RTT solo hacen algo con SRT. Con un servidor MediaMTX, NOALBS lee el tiempo de ida y vuelta de las estadísticas de la conexión SRT. Si publicas por RTMP no hay RTT: solo hacen algo los umbrales de bitrate.
• El nombre de la ruta va dentro de statsUrl. Esa URL termina con la ruta que definiste en MediaMTX. Apúntala a una que no exista y NOALBS verá una emisión offline para siempre, sin ningún error que lo explique.
• onlySwitchWhenStreaming evita sustos. Con esa opción activada, NOALBS no te toca las escenas hasta que OBS está emitiendo de verdad. Va bien mientras montas el layout.

Comprueba cada pieza antes de añadir la siguiente

Todos los fallos de este montaje se ven igual desde fuera: no hay imagen. Construirlo en orden y confirmar cada capa es lo que hace que depurar cueste minutos y no una tarde entera:

1. MediaMTX está vivo. systemctl status dice active y journalctl no muestra errores de configuración. Si esto falla, nada de lo que viene después puede funcionar.
2. Los puertos responden desde fuera. Desde otra máquina, nc -zv SERVER 1935 cubre el TCP. El UDP no se prueba así: publica una emisión SRT de prueba de verdad y mira el log del servidor.
3. Llega una emisión de prueba. Lanza el comando de ffmpeg y luego consulta la ruta de la API con curl. Un ready:true con bytesReceived subiendo demuestra que la entrada y las credenciales funcionan.
4. Y también llega tu móvil. Solo ahora prueba con Moblin, BELABOX o IRL Pro. Si ffmpeg funcionó y el móvil no, el problema está en los ajustes del encoder o en la red móvil, no en el servidor.
5. OBS lee la señal. Añade la URL de lectura como fuente multimedia. Imagen en OBS significa que el camino completo funciona de punta a punta.
6. NOALBS reacciona. Arráncalo y mira su log: debería reportar un bitrate cada segundo. Después corta la emisión de prueba y confirma que OBS se va solo a la escena offline. Si no pasa nada, los nombres de escena no coinciden.

Lo que cuesta de verdad

Las partes que son de verdad difíciles

• SRTLA, no SRT. Un relay de SRT o RTMP a secas es un proyecto de fin de semana. El bonding es donde se va el tiempo: montar el receptor, mantenerlo en pie y averiguar por qué uno de los módems no aporta nada es trabajo real.
• UDP por internet. Algunos alojamientos maltratan o descartan UDP, y ciertas funciones de nube lo rompen de formas que no están documentadas. Las IP reservadas o flotantes son un clásico. Cuando SRT falla y RTMP funciona, sospecha de la red antes que del software.
• No hay anti-caída. Un servidor es un único punto de fallo. Si se reinicia por mantenimiento mientras estás en directo, se acabó la emisión. Resolverlo bien significa una segunda máquina y algo que mantenga viva la conexión con la plataforma, que es un proyecto entero aparte.
• La seguridad pasa a ser tuya. Puertos de entrada públicos, binarios de código abierto que hay que ir parcheando y una máquina Linux en internet. Nada exótico, pero es una tarea recurrente que nunca avisa.
• Esto no te da Cloud OBS. Un relay mueve vídeo. Ejecutar OBS en la nube necesita una máquina con GPU, una sesión de escritorio y una forma de manejarlo en remoto, y una GPU alquilada cuesta varias veces lo que este VPS. Si lo que quieres es emitir sin un PC en casa, autohospedar un relay no te lleva ahí.

Cuándo autohospedar y cuándo no

No hay respuesta universal. A grandes rasgos:

• Autohospéda si ya administras servidores. Si un servicio de systemd y una regla de cortafuegos son una tarde normal para ti y además disfrutas, acabarás con exactamente lo que quieres y pagando menos.
• Autohospéda si emites muchas horas. Los números mejoran cuanto más uses una máquina que estás alquilando a todas horas.
• Autohospéda si necesitas una región rara. Si emites desde un sitio que ningún proveedor cubre bien, un VPS cerca de ti gana a un relay gestionado lejano por bueno que sea el servicio.
• No autohospedes si emites unas pocas horas a la semana. Pagas un mes entero de servidor para usar un puñado de horas, y encima cargas con el mantenimiento.
• No autohospedes si necesitas bonding y esto no te divierte. SRTLA es la parte que te va a costar tardes. Si el bonding es esencial en tu directo, sé sincero sobre si quieres que ese sea tu problema.
• No autohospedes si quieres dejar de depurar a las dos de la mañana. Lo que vende de verdad un relay gestionado no es el servidor. Es no estar de guardia de tu propia emisión.

¿Todavía dudando de si montarte tú algo de esto? Las tres rutas, con su coste, una al lado de otra: Servidor de streaming IRL: qué es y cuál necesitas.

Preguntas frecuentes

Los proyectos sobre los que se construye

• MediaMTX, el servidor multimedia (bluenviron/mediamtx)
• NOALBS, cambio de escenas automático para OBS, de 715209 y b3ck
• srtla, la implementación original de BELABOX
• srtla, el fork mantenido del receptor

Útil aunque te lo montes tú

Estas guías son parte de nuestra documentación de producto, pero lo de protocolos, encoders y cambio de escenas vale para cualquier relay, el nuestro o el tuyo:

• Elegir protocolo: RTMP, SRT o SRTLA
• Emitir con Moblin
• Emitir con BELABOX
• Cambio de escenas automático en tu propio OBS
• Usar tu propio OBS con un relay

Sigue leyendo

• Comparar servicios de streaming IRL: qué mirar antes de cambiar
• Enhanced IRL frente a IRLToolkit, punto por punto