Montar un servidor de streaming: una subida para cualquier número de espectadores

Quien transmite sin un servidor propio envía su imagen a cada espectador por separado. Diez espectadores significan diez veces los mismos datos; cien espectadores, cien veces. La subida de casa o de la oficina se satura así con muy pocos espectadores, y la imagen empieza a cortarse aunque el ordenador apenas tenga trabajo.

Un servidor de streaming le da la vuelta a esto: tú envías exactamente un stream al servidor, y el servidor abastece con él a todos los espectadores. Tu propia línea soporta por eso siempre una única subida, da igual que estén mirando diez personas o diez mil. Este artículo muestra por qué funciona tan bien, cómo montas un servidor así, qué retardo cuesta cada protocolo y cuánto tráfico se junta de verdad.

El problema: tu subida es el cuello de botella

El vídeo es un flujo continuo. Un stream en 1080p con 60 imágenes por segundo necesita, según el contenido, entre 4,5 y 8 Mbit/s; 720p se queda en 3 a 5 Mbit/s. Ese bitrate circula por espectador, todo el tiempo, sin pausa.

Una conexión doméstica media en Alemania alcanza entre 10 y 50 Mbit/s de subida, e incluso muchas conexiones de fibra se quedan entre 50 y 100 Mbit/s de subida. Por eso la cuenta se acaba enseguida:

A esto se añade un segundo problema que se pasa por alto a menudo: tu conexión comparte esa línea con todo lo demás de la casa o de la oficina. En cuanto alguien sube un archivo grande o arranca una copia de seguridad, el stream se hunde. Un servidor en el centro de datos no tiene ese problema, allí el enlace está a tu disposición en exclusiva.

El principio: una sola subida, muchas bajadas

El montaje consta de tres partes:

• El emisor, es decir OBS, ffmpeg o una caja de hardware, envía un stream al servidor. Eso se llama ingest.
• El servidor acepta ese único stream, lo convierte al formato de entrega que quieras y lo mantiene disponible.
• Los espectadores recogen el stream del servidor. Eso se llama egress y es la parte que crece con el número de espectadores.

Lo decisivo es la asimetría: el camino de ti al servidor se recorre una vez, el camino del servidor a los espectadores mil veces. Por eso tu conexión solo necesita tanta subida como un único stream, mientras que el servidor necesita un enlace que aguante el ritmo del público.

Cuánto tráfico se junta de verdad

El ancho de banda es solo la mitad de la cuenta. Más interesante es el volumen, porque es lo que facturan muchos proveedores. La fórmula es sencilla:

Volumen en GB = bitrate en Mbit/s × segundos × espectadores ÷ 8000

Unos cuantos ejemplos realistas:

Las cifras de la última columna son la razón por la que el streaming y la facturación por volumen encajan mal. Una sola retransmisión bien seguida puede agotar el volumen incluido de un mes entero, y cada terabyte adicional se cobra después aparte. Con una tarifa de tráfico ilimitado esa cuenta desaparece por completo: el precio mensual es fijo, da igual que pasen 200 GB o 50 TB por la línea.

Qué software te conviene

Para empezar, nginx con el módulo RTMP es la elección más evidente: está disponible en todas partes, está bien documentado y luego puedes usar el mismo servidor, sin reformas, como servidor web para la página de los espectadores.

Montar un servidor de streaming con nginx y RTMP

Instalar

En Debian y Ubuntu, el paquete libnginx-mod-rtmp ya trae el módulo, no tienes que compilar nada tú mismo:

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

En AlmaLinux y Rocky Linux, el módulo viene del repositorio EPEL:

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

Configurar

La parte RTMP va en nginx.conf fuera del bloque http, y ese es el error de principiante más frecuente. Una versión ligera y funcional tiene este aspecto:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS para los espectadores normales
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # solo se puede emitir desde la propia dirección
            allow publish 203.0.113.10;
            deny publish all;

            # ver puede cualquiera
            allow play all;
        }
    }
}

Los archivos HLS los entrega después el servidor web normal. Para eso basta un pequeño bloque en la parte http:

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 *;
    }
}

Crear el directorio, comprobar la configuración, reiniciar:

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

Abrir los puertos

RTMP trabaja en el puerto 1935, la entrega va por 80 y 443. Con nftables o ufw:

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

Fíjate en la primera línea: el puerto de emisión está abierto solo para tu propia dirección. Un puerto RTMP abierto al mundo se encuentra en pocos días, porque hay rangos de direcciones enteros que se rastrean de forma automática, y entonces es otro el que emite por tu línea.

Emitir con OBS

En OBS, en Ajustes, Emisión, elige el servicio "Personalizado":

En Salida ajustas el bitrate. Como referencia: 1080p60 con 6000 kbit/s, 1080p30 con 4500 kbit/s, 720p30 con 3000 kbit/s. Pon la distancia entre fotogramas clave en 2 segundos, porque si no, con HLS salen segmentos irregulares y el reproductor se atasca al cambiar.

Ver el stream

El stream queda después en https://stream.example.com/hls/kanal1.m3u8 y se puede abrir con cualquier reproductor compatible con HLS, en el navegador por ejemplo con hls.js o Video.js. Para una comprobación rápida basta VLC con "Abrir ubicación de red".

Emitir a varias plataformas a la vez

Esta es la segunda gran ventaja de un servidor propio. En lugar de reventar tu línea con tres subidas en paralelo, envías una vez al servidor y él reparte a partir de ahí. Para eso añades en el bloque application una línea por destino:

application live {
    live on;
    record off;

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

Tu subida se queda mientras en un único stream. La multiplicación la hace el servidor, y ahí el ancho de banda es precisamente aquello para lo que está.

Retardo: qué protocolo para qué

El retardo se produce casi por completo en la entrega, no en la emisión. Es importante entenderlo, porque mucha gente busca en el sitio equivocado:

Cuanto más bajo es el retardo, más caro sale cada espectador. HLS es lo más barato, porque consiste en archivos simples que cualquier servidor web y cualquier caché pueden entregar. WebRTC, en cambio, mantiene una conexión propia abierta por espectador y cuesta por eso bastante más potencia de cálculo. Usa el retardo bajo solo donde de verdad lo necesites.

Transcodificación: cuándo vale la pena

Mientras el servidor solo pasa el stream, apenas necesita potencia de cálculo. Un único núcleo moderno atiende de esa forma a varios cientos de espectadores, y el cuello de botella es únicamente el enlace.

En cuanto quieres ofrecer varios niveles de calidad, para que también puedan ver los espectadores con mala conexión, eso cambia. Cada nivel adicional hay que calcularlo:

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

Cuenta con dos a cuatro núcleos por nivel. Tres niveles ocupan ya de ocho a doce núcleos de forma permanente. Piensa por eso bien si los necesitas: para un público que está sobre todo en el ordenador o en wifi, suele bastar un único nivel bien elegido.

Asegurar el servidor: quién puede emitir

Un servidor de streaming es visible desde fuera y se encuentra. Para el día a día bastan tres medidas:

• Firewall en el puerto de emisión. Solo tu propia dirección puede entrar en el 1935. Si tu dirección cambia, usa en su lugar un acceso VPN al servidor.
• Comprobar la clave de stream. Con on_publish, nginx llama en cada intento de emisión a un pequeño script que compara la clave con una lista y la rechaza si no coincide.
• Protección básica contra la sobrecarga. Un servidor de streaming es un objetivo rentable, porque una caída se ve al instante. En KernelHost, cada servidor lleva una protección antifloods con 3,2 Tbps de capacidad, sin que tengas que configurar nada. Más sobre esto en la página de la protección DDoS.

Elección de la ubicación y varios servidores

El servidor no va cerca de ti, sino cerca de tus espectadores. Tu propia conexión al servidor se establece una vez y funciona después de forma estable, incluso a través de medio continente. La conexión con los espectadores, en cambio, decide el tiempo de carga y la tasa de abandono.

Si tu público está sobre todo en Europa, una ubicación en Alemania es la correcta. Si se reparte por varios continentes, vale la pena un segundo servidor y un reparto por DNS, de forma que cada espectador acabe en el más cercano. KernelHost ofrece para eso ubicaciones en Alemania, en la costa oeste de EE. UU., en la costa este de EE. UU. y además en Singapur y Corea del Sur; encontrarás un resumen en Ubicaciones de servidores.

Si lo que reparte son archivos en vez de imagen en directo, es decir actualizaciones, imágenes o archivos de vídeo, la herramienta adecuada no es un servidor de streaming, sino una caché por delante. Cómo funciona eso está en el artículo Montar un servidor CDN propio.

Qué servidor encaja

Para un servidor de streaming cuenta un orden distinto que para un servidor web:

1. Enlace y tráfico. Ese es el cuello de botella, y siempre lo es. Un enlace gigabit real sin limitación soporta unos 160 espectadores a 6 Mbit/s.
2. Tráfico ilimitado. Las tarifas por volumen son poco calculables para el streaming, porque una sola noche con éxito agota el volumen del mes.
3. CPU. Secundaria, mientras no transcodifiques. Con la transcodificación se convierte en el segundo cuello de botella.
4. RAM y disco. Lo menos crítico. El espacio en disco solo se vuelve un tema cuando guardas grabaciones.

Justo para este caso están pensados nuestros servidores root con tráfico ilimitado: enlace real de 2 × 1 Gbit/s por servidor, volumen ilimitado sin limitación de velocidad, un precio mensual fijo independiente de la cantidad transferida y 3,2 Tbps de protección antifloods de serie. El servidor está listo en menos de 30 segundos, con acceso root completo, IPv4 y una red IPv6 /64. La facturación es de prepago y cancelable mensualmente, así que puedes empezar con una tarifa pequeña y crecer cuando crezca tu público.