Streaming en directo propio para Asia: origen SRS en un servidor de Hong Kong, Tokio o Singapur con CDN

Para montar streaming en directo autoalojado para audiencias en Asia, coloca un origen SRS (o nginx-rtmp) en un servidor dedicado en Hong Kong, Tokio o Singapur, recibe la señal por RTMP o SRT, entrega HLS y WebRTC y deja que una CDN reparta el flujo a los espectadores. IMIDC aporta todas las piezas: servidores dedicados en Hong Kong desde $139/mes con ruta CN2 GIA a China continental, dedicados en Japón, servidores en Singapur bajo pedido, uplinks de 10 Gbps, protección DDoS y la CDN de IMIDC.

Cómo encaja una plataforma de streaming en directo propia

Una plataforma en directo tiene cuatro etapas: ingesta, origen/empaquetado, distribución y reproducción.

1. Ingesta: OBS, vMix o un codificador hardware del presentador envía RTMP o SRT al origen.
2. Origen: SRS recibe el flujo, opcionalmente lo transcodifica a varios bitrates, genera segmentos HLS, sirve WebRTC y graba en disco.
3. Distribución: una CDN extrae el HLS del origen y cachea los segmentos cerca de los espectadores.
4. Reproducción: hls.js, Video.js o reproductores nativos para HLS; un reproductor WebRTC para sesiones interactivas de menos de un segundo.

Los casos típicos son webinars y reuniones corporativas, clases de e-learning, lanzamientos y eventos, y streams de videojuegos o esports en los que quieres marca propia, control de acceso y grabaciones en lugar de depender de una plataforma de terceros.

Elegir protocolos de ingesta y reproducción

Usa RTMP o SRT para la entrada, HLS para escalar y WebRTC solo donde importe la interactividad.

SRS maneja RTMP, SRT, HLS, HTTP-FLV y WebRTC en un solo proceso. Si necesitas específicamente LL-HLS con segmentos parciales, comprueba que tanto tu empaquetador como tu CDN lo soportan antes de prometer baja latencia.

Desplegar SRS con Docker en un servidor dedicado

SRS funciona muy bien en Docker; lo único que hay que acertar son los puertos, la IP candidata de WebRTC y las carpetas persistentes.

mkdir -p /opt/srs/conf /opt/srs/html /opt/srs/record
# put srs.conf (below) into /opt/srs/conf/srs.conf, then:
docker run -d --name srs --restart unless-stopped \
  -p 1935:1935 -p 1985:1985 -p 8080:8080 \
  -p 8000:8000/udp -p 10080:10080/udp \
  -e CANDIDATE=203.0.113.20 \
  -v /opt/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf \
  -v /opt/srs/html:/usr/local/srs/objs/nginx/html \
  -v /opt/srs/record:/usr/local/srs/objs/record \
  ossrs/srs:5 ./objs/srs -c conf/srs.conf

docker logs -f srs          # watch publish / play events
ufw allow 1935/tcp; ufw allow 8000/udp; ufw allow 10080/udp

Un srs.conf orientado a producción con HLS, HTTP-FLV, WebRTC, SRT, grabación y un hook de publicación:

listen              1935;
max_connections     3000;
daemon              off;
srs_log_tank        console;

http_api    { enabled on; listen 1985; }
http_server { enabled on; listen 8080; dir ./objs/nginx/html; }
rtc_server  { enabled on; listen 8000; candidate $CANDIDATE; }
srt_server  { enabled on; listen 10080; }

vhost __defaultVhost__ {
    hls {
        enabled         on;
        hls_fragment    2;
        hls_window      12;
        hls_path        ./objs/nginx/html;
        hls_m3u8_file   [app]/[stream].m3u8;
        hls_ts_file     [app]/[stream]-[seq].ts;
        hls_cleanup     on;
    }
    http_remux { enabled on; mount [vhost]/[app]/[stream].flv; }
    rtc        { enabled on; rtmp_to_rtc on; rtc_to_rtmp on; }
    srt        { enabled on; srt_to_rtmp on; }
    dvr {
        enabled     on;
        dvr_plan    session;
        dvr_path    ./objs/record/[app]/[stream]/[2006]-[01]-[02]_[15][04][05].mp4;
    }
    http_hooks {
        enabled     on;
        on_publish  http://127.0.0.1:8085/api/streams/on_publish;
    }
    play { gop_cache on; }
}

Emite desde OBS o ffmpeg y prueba la reproducción:

# OBS (RTMP):  Server  rtmp://203.0.113.20/live   Stream key  event1?secret=YOUR_KEY
# SRT push from ffmpeg (OBS can also output SRT):
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -g 60 \
  -c:a aac -b:a 128k -f mpegts \
  "srt://203.0.113.20:10080?streamid=#!::r=live/event1,m=publish"

# Playback URLs
# HLS       http://203.0.113.20:8080/live/event1.m3u8
# HTTP-FLV  http://203.0.113.20:8080/live/event1.flv
# WebRTC    http://203.0.113.20:1985/rtc/v1/whep/?app=live&stream=event1   (WHEP)

• Configura el intervalo de fotogramas clave del codificador en 2 segundos para que coincida con hls_fragment 2.
• CANDIDATE debe ser la IP pública del servidor; si no, los reproductores WebRTC no conectarán.
• El hook on_publish permite a tu aplicación validar la clave de emisión: responde HTTP 200 con cuerpo 0 para permitir y cualquier otra cosa para rechazar.

Para bitrate adaptativo, añade un transcodificador ffmpeg que publique calidades adicionales y referéncialas desde una playlist maestra:

# simple ABR ladder: pull the source from SRS and publish 720p + 480p renditions
ffmpeg -i rtmp://127.0.0.1/live/event1 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 1280x720 -b:v 2500k -g 60 \
     -c:a aac -b:a 128k -f flv rtmp://127.0.0.1/live/event1_720 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 854x480 -b:v 1000k -g 60 \
     -c:a aac -b:a 96k  -f flv rtmp://127.0.0.1/live/event1_480

¿Prefieres nginx-rtmp? Cubre RTMP de entrada y HLS de salida con poco consumo, pero no tiene SRT ni WebRTC nativos:

# nginx-rtmp alternative (nginx.conf, top level)
rtmp {
    server {
        listen 1935;
        application live {
            live on;
            hls on;
            hls_path /var/www/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;
            on_publish http://127.0.0.1:8085/api/streams/on_publish;
        }
    }
}

Cálculo de ancho de banda: espectadores x bitrate

El tráfico de salida en pico es simplemente espectadores simultáneos por bitrate medio, más un 10 % aproximado de sobrecarga de protocolo.

Fórmula: GB por hora = Mbps x 3600 / 8 / 1000. Un solo origen con uplink de 10 Gbps puede servir directamente a unos cientos de espectadores con holgura; por encima de eso, sirve a la audiencia desde una CDN para que el origen solo alimente su caché. La ingesta es pequeña en comparación: 4-6 Mbps por cada presentador en 1080p.

Conectar el origen con la CDN de IMIDC

Deja que la CDN extraiga el HLS del origen por HTTPS, cachee los segmentos mucho tiempo y las playlists alrededor de un segundo.

# Nginx in front of SRS as the HTTPS origin for the CDN
server {
    listen 443 ssl;
    http2 on;
    server_name origin-live.example.com;
    ssl_certificate     /etc/nginx/ssl/origin-live.crt;
    ssl_certificate_key /etc/nginx/ssl/origin-live.key;

    location ~ \.m3u8$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=1" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
    location ~ \.(ts|m4s)$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=86400" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
}

• Apunta un nombre como origin-live.example.com al origen y configúralo como origen en la CDN de IMIDC; los espectadores usan el nombre de la CDN.
• Las playlists (.m3u8) cambian con cada segmento, así que cachéalas 1-2 segundos; los segmentos nunca cambian, cachéalos por mucho tiempo.
• Usa URLs firmadas o autenticación por token en la CDN para eventos de pago o privados.
• Mantén las sesiones WebRTC en el origen (o en unos pocos edges SRS regionales), porque las CDN HTTP no cachean WebRTC.

Grabación y archivo en almacenamiento

Graba cada sesión en el origen y mueve los archivos terminados a almacenamiento de objetos para repeticiones y vídeo bajo demanda.

# move finished recordings to S3-compatible object storage every 10 minutes (cron)
*/10 * * * * rclone move /opt/srs/record s3store:live-archive --min-age 10m --delete-empty-src-dirs

La carpeta de grabación de la configuración anterior está fuera del directorio web público, así que nadie puede descargar las grabaciones originales adivinando URLs. Usa un servidor de almacenamiento o un bucket de objetos aparte para el archivo a largo plazo y transcodifica las repeticiones a una escalera HLS si las publicas.

Dónde ubicar el origen y protección DDoS

Coloca el origen cerca de los presentadores y de la audiencia principal, y protege los puntos públicos.

• Contrata la protección DDoS de IMIDC para el origen; los streams de videojuegos y esports atraen ataques con frecuencia.
• Expón solo lo necesario: 1935/10080 para ingesta (idealmente limitados a las IPs de los presentadores), 443 para la CDN y los puertos WebRTC.
• Rota las claves de emisión en cada evento y valídalas en el hook de publicación.
• Las emisiones dirigidas a espectadores de China continental deben tener contenido legal, y los servicios de audio y vídeo en directo allí pueden estar sujetos a licencias específicas; esto no es asesoramiento legal.

Qué configuración de IMIDC te conviene

Dimensiona el origen según presentadores, carga de transcodificación y cuánto tráfico absorbe la CDN.

• Webinars internos o clases de hasta unos cientos de espectadores: un dedicado en Hong Kong o un dedicado en Japón sirviendo HLS directamente.
• Eventos públicos y streams de videojuegos con miles de espectadores: origen dedicado con protección DDoS más la CDN de IMIDC.
• Plataforma multirregión: orígenes en Hong Kong y Tokio, Singapur bajo pedido vía ventas, con BGP y Anycast para la ingesta si tienes ASN propio.
• Nodos de transcodificación con GPU o muchos núcleos, discos grandes para archivo: pide una configuración a medida al equipo comercial de IMIDC.

Preguntas frecuentes

¿Cuál es la mejor ubicación de servidor para autoalojar streaming en directo para Asia?

Hong Kong es la elección habitual cuando muchos espectadores están en China continental, porque los servidores de IMIDC en Hong Kong usan China Telecom CN2 GIA. Tokio encaja con Japón y Corea, y Singapur con el Sudeste asiático; para audiencias mixtas, usa un origen más una CDN.

¿Cuánto ancho de banda necesito para 1.000 espectadores en directo?

A 3 Mbps por espectador necesitas unos 3 Gbps de salida en pico y alrededor de 1,35 TB por hora. Por eso las audiencias de ese tamaño deben servirse a través de una CDN y no directamente desde el origen.

¿Uso SRS o nginx-rtmp?

SRS admite RTMP, SRT, HLS, HTTP-FLV y WebRTC en un solo servidor y tiene API HTTP, así que es la opción más completa. nginx-rtmp es más ligero y suficiente para flujos sencillos de RTMP a HLS.

¿Puedo tener latencia inferior a un segundo para miles de espectadores?

La entrega en menos de un segundo requiere WebRTC, mucho más pesado por espectador que HLS y no cacheable por CDN convencionales. La mayoría de plataformas usan WebRTC para presentadores y participantes interactivos, y HLS o LL-HLS para el resto de la audiencia.

¿IMIDC ofrece protección DDoS para orígenes de streaming?

Sí. IMIDC ofrece protección DDoS que puede añadirse a los servidores usados como origen de streaming. Indica a ventas el tamaño previsto de tus eventos para ajustar la protección y los puertos a tu tráfico.

¿Estás planificando tu propia plataforma de streaming? Empieza con un dedicado en Hong Kong o un dedicado en Tokio y la CDN de IMIDC, o abre un ticket y el equipo de IMIDC te ayudará a dimensionar el origen.