Server de streaming RTMP: profesional vs Nginx propio

RTMP en 2026: ¿sigue siendo el estándar de ingesta?

Adobe publicó la Real-Time Messaging Protocol Specification en 2009. Diecisiete años después, RTMP sigue siendo el protocolo de ingesta dominante del planeta a pesar de que YouTube anunció en 2024 que migra parcialmente a SRT y WebRTC, y a pesar de que Flash (su carcasa histórica) lleva muerto desde diciembre de 2020. ¿Cómo puede ser?

La respuesta tiene tres capas. Primero, RTMP de ingesta sigue siendo universalmente soportado: OBS Studio, vMix, Wirecast, Larix Broadcaster, FFmpeg, Restream Studio, encoders hardware Teradek y AJA, todos hablan RTMP nativo desde el día uno. Segundo, todas las plataformas de destino (YouTube Live, Facebook Live, Twitch, Kick, TikTok Live) aceptan RTMP como entrada. Tercero, RTMP funciona razonablemente bien sobre TCP en redes con latencia y jitter moderados, lo cual cubre el 95% de los escenarios de streaming amateur y semi-pro.

Lo que ha cambiado

• RTMP de distribución (de server a viewer) está casi muerto. Ya no hay Flash Player; los viewers reciben HLS, DASH o WebRTC.
• RTMPS (RTMP sobre TLS, puerto 443) reemplazó a RTMP plano en Facebook, X y TikTok desde 2019.
• Aparecieron alternativas: SRT (mejor en redes inestables), RIST (broadcast-grade), WHIP (WebRTC HTTP Ingestion Protocol) ganando tracción.

Datos duros del mercado

Según el Bitmovin Video Developer Report 2024, el 73% de los encoders de producción siguen usando RTMP como protocolo de ingesta primario. SRT subió del 11% al 23% entre 2022 y 2024. WebRTC ingest llegó al 8%. RTMP no se va a morir esta década.

Si entras a un proyecto nuevo de streaming en 2026 y te dicen "no uses RTMP porque es viejo", desconfía. Lo viejo no es lo malo. Lo malo es lo mal montado.

Nginx-RTMP: cómo funciona por dentro

El módulo nginx-rtmp-module fue creado por Roman Arutyunyan en 2012. Es un add-on para el servidor web Nginx que añade soporte de protocolo RTMP en el puerto 1935 y, opcionalmente, segmenta el stream entrante en HLS o DASH para servirlo via HTTP. Open-source, licencia BSD.

El flujo básico

1. OBS envía RTMP al puerto 1935 de tu VPS.
2. nginx-rtmp acepta la conexión, valida la stream key.
3. El módulo guarda los chunks en /tmp/hls como archivos .m3u8 + .ts.
4. El bloque http de Nginx sirve esos archivos por HTTP/HTTPS.
5. El player en el browser pide la playlist y descarga los segmentos.

Snippet mínimo de nginx.conf

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;
            hls on;
            hls_path /var/www/hls;
            hls_fragment 3;
            hls_playlist_length 60;

            # Validación de stream key
            on_publish http://127.0.0.1:8080/auth;

            # Restream a YouTube
            push rtmp://a.rtmp.youtube.com/live2/YOUR-KEY;
        }
    }
}

http {
    server {
        listen 80;
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /var/www;
            add_header Cache-Control no-cache;
            add_header Access-Control-Allow-Origin *;
        }
    }
}

Lo que esto te da

• Ingesta RTMP en menos de 50 ms de overhead.
• Salida HLS lista para cualquier player web/mobile.
• Restream básico via "push" a otros endpoints RTMP.
• Stat module para monitoreo (URL /stat con XML/XSL).

Lo que NO te da

• Multibitrate adaptativo (ABR): solo emite la calidad que llega; si quieres 480p + 720p + 1080p simultáneo, necesitas FFmpeg externo transcodeando.
• Soporte de SRT, WebRTC, DASH (sin fork).
• Panel de administración: todo es archivos de configuración.
• Soporte de Roman Arutyunyan: no actualiza el repo desde 2019. Hay forks comunitarios pero el original está en hibernación.

Si quieres el paso a paso, lo tenemos en cómo configurar un servidor RTMP propio.

Costo real de un Nginx-RTMP propio: TCO honesto

Aquí es donde se cae la idea de que "self-hosted es gratis". Vamos a calcular el costo total de propiedad (TCO) realista de un Nginx-RTMP que aguante 500 viewers concurrentes 8 horas al día con multibitrate 480p+720p+1080p.

Tabla de costos mensuales reales

Costos one-time olvidados

• Setup inicial: 16-24 horas de DevOps. A USD 35/h son USD 560-840 antes de emitir el primer frame.
• Certificado SSL: gratis con Let's Encrypt, pero hay que configurar renovación automática (otra hora).
• Testing de carga: replicar 500 viewers con Locust o k6 requiere otro VPS temporal por 1-2 días.

El costo invisible: tu tiempo cuando algo falla

Tres incidentes típicos que vemos en clientes que migran desde Nginx-RTMP propio:

• VPS sobrecargado mid-stream: el transcoding consume 100% CPU, frames empiezan a caerse, viewers ven buffering. Necesitas tirar el stream, escalar el VPS, levantar de nuevo. 25-40 minutos perdidos en vivo.
• Stream key filtrada: alguien adivina la key o la encontró en un cliente JavaScript mal configurado. Empieza a emitir contenido random. Tienes que rotar la key, actualizar el encoder, reconectar.
• Ataque DDoS al puerto 1935: el firewall del VPS no aguanta, el VPS se cae, hay que esperar reboot. Sin CDN protectora delante, eres carne fácil.

El 18% de las transmisiones que arrancan en setups Nginx-RTMP propios caen al menos una vez el primer mes según nuestros datos internos de migraciones recibidas. Para audiencia bajo 100 viewers concurrentes, el setup propio puede salir más barato. Sobre eso, la matemática cambia.

Limitaciones técnicas de Nginx-RTMP

Más allá del costo, hay límites técnicos duros que conviene conocer antes de comprometerse con un setup Nginx-RTMP propio.

Multibitrate (ABR) requiere ingeniería extra

Nginx-RTMP por sí solo no transcodifica. Emite la calidad que llega. Para generar 480p+720p+1080p tienes que disparar 3 instancias de FFmpeg que toman el stream desde el server, lo transcodean, y lo reemiten al mismo Nginx en una application diferente. Es factible, pero consume CPU brutalmente: 3 streams 720p en x264 medium preset usan ~6 vCPU al 90%.

Monitoreo: lo mínimo necesario

El módulo /stat te da un XML con métricas básicas: streams activos, bitrate, conexiones. Para algo serio necesitas:

• Exportar /stat a Prometheus con un exporter (no oficial).
• Configurar alertas en Grafana (CPU, RAM, frames dropped, bitrate inestable).
• Alertar a Slack/Telegram/PagerDuty cuando el stream cae.

Es construir una mini-plataforma alrededor del módulo. Esfuerzo de un sprint completo.

Redundancia: prácticamente inexistente

Nginx-RTMP no tiene clustering nativo. Si el VPS se cae, el stream se cae. Las soluciones caseras (DNS failover, segundo VPS con encoder dual) funcionan pero requieren más infraestructura y testing constante.

Seguridad

• Stream keys son texto plano por default. Hay que implementar on_publish con un endpoint HTTP de validación.
• Sin token signing de fábrica para URLs HLS. Cualquiera con el .m3u8 puede embeber tu stream donde quiera.
• Sin geo-blocking nativo: necesitas otro layer (Cloudflare, MaxMind GeoIP en Nginx).
• DRM: imposible sin solución externa cara (Widevine, FairPlay).

Soporte y comunidad

El repositorio original tiene 13.000 stars en GitHub pero el último commit del mantenedor original es de 2019. Hay forks activos (nginx-rtmp-module-arut, sergey-dryabzhinsky/nginx-rtmp-module) pero ninguno con dedicación full-time. Cuando algo se rompe, te quedas con StackOverflow y posts antiguos de blogs rusos.

Alternativas modernas a Nginx-RTMP

Si Nginx-RTMP te queda corto pero quieres seguir self-hosted, hay opciones más modernas. Algunas son herederas espirituales, otras superan al original por mucho.

MediaMTX (antes rtsp-simple-server)

Escrito en Go, single-binary, sin dependencias. Soporta RTSP, RTMP, RTMPS, HLS, WebRTC, SRT como ingesta y salida. La curva es plana: archivo YAML, levantas el binario, listo.

• + Multi-protocolo nativo (RTSP + RTMP + WebRTC en mismo server).
• + Configuración declarativa, fácil de versionar.
• + Comunidad activa, releases mensuales en 2025.
• - Sin transcoding ABR nativo: ABR requiere FFmpeg externo igualmente.
• - Sin panel UI (todo CLI/YAML).

Ant Media Server

Turco, dual-licensed (Community gratis, Enterprise USD 99-499/mes). Hace WebRTC scalable de verdad, con clustering origin-edge. Si necesitas WebRTC para 1.000+ viewers, Ant es de los pocos open-source serios.

• + Clustering nativo origin/edge.
• + WebRTC, SRT, RTMP, HLS, DASH todo en uno.
• + Panel web decente.
• - Community Edition limitada (sin transcoding adaptive, sin clustering).
• - Enterprise sube rápido en precio si escalas.

OvenMediaEngine (OME)

Coreano, open-source AGPL. Su selling point es Low Latency HLS y WebRTC con clustering. Lo recomendamos cuando un cliente necesita LL-HLS pero no quiere SaaS.

• + LL-HLS nativo, WebRTC scalable.
• + Transcoding integrado con NVIDIA NVENC y AMD AMF.
• + API REST completa.
• - Curva de aprendizaje moderada, docs mejorables.
• - AGPL puede complicar uso comercial cerrado.

SRS (Simple Realtime Server)

Chino, MIT license, monstruosamente performante. Maneja 10.000+ conexiones concurrentes en un solo nodo. Soporta RTMP, HTTP-FLV, HLS, SRT, WebRTC, GB28181 (vigilancia).

• + Rendimiento brutal, edge clustering CDN-like.
• + Docker oficial optimizado.
• - Comunidad principalmente en chino, foros y issues mixtos.
• - Sin transcoding ABR nativo.

Para más comparativas técnicas mira SRT vs RTMP.

Cuándo Nginx-RTMP tiene sentido (escenarios reales)

No todo es negativo. Hay casos donde montar un Nginx-RTMP propio es la decisión correcta. Los listamos honesto.

Caso 1: Testing y desarrollo

Estás desarrollando una app de streaming y necesitas un endpoint RTMP para apuntar OBS y probar. Nginx-RTMP en un Droplet de USD 6/mes es perfecto. Levantas, pruebas, tumbas. Cero compromiso.

Caso 2: Audiencia bajo 100 concurrentes

Un podcast en video con 30-60 espectadores en vivo. Un canal corporativo interno con 80 empleados. Aquí los números de Nginx-RTMP funcionan: un VPS de USD 24/mes basta. Si haces self-host bien, gastas menos que cualquier plan SaaS.

Caso 3: Red interna estricta (compliance)

Banca, salud, gobierno. Cuando políticas internas prohíben que la señal pase por infraestructura externa. Nginx-RTMP en datacenter on-prem o nube privada cumple compliance. El costo extra de DevOps lo absorbe el área de TI.

Caso 4: Aprender

Si tu trabajo es entender streaming de fondo, no hay mejor profesor que romper y arreglar tu propio Nginx-RTMP varias veces. Es el ejercicio educativo perfecto.

Caso 5: Restream básico hacia 2-3 destinos

Si lo único que necesitas es recibir RTMP de OBS y reemitir a YouTube + Facebook + Twitch sin más vueltas, Nginx-RTMP con el directive push hace el trabajo. No es bonito pero funciona.

Cuándo NO usar Nginx-RTMP, aunque te tiente

• Tu negocio depende de no caer.
• Audiencias mayores a 200 concurrentes.
• Necesitas paywall, geo-blocking, DRM.
• No tienes DevOps disponible 24/7.
• Cobras a clientes por el servicio (SLA contractual).

La pregunta correcta no es "¿Nginx-RTMP es bueno?". Es "¿mi tiempo vale más en operar el server o en producir contenido?". Si la respuesta es lo segundo, paga por un gestionado.

Cuándo conviene migrar a gestionado

Hay señales claras de que un Nginx-RTMP propio te queda chico. Vemos las mismas cinco una y otra vez en clientes que llegan migrando.

Tabla de triggers de migración

El cálculo del breakeven

Hicimos el ejercicio para un cliente de Cali el año pasado. Tenían Nginx-RTMP en Hetzner por USD 38/mes de VPS, pero el CTO dedicaba 8 horas mensuales al server. A USD 60/h de costo cargado, eran USD 480/mes invisibles en su P&L. Total real: USD 518/mes para servir 700 viewers concurrentes 6 días a la semana.

Migrarlos a nuestro plan Pro (USD 199/mes) les ahorró USD 319/mes y liberó 8 horas del CTO para producto. La decisión se pagó sola en el primer mes. Y eso sin contar la caída del Black Friday 2024 que les costó 2 horas de no disponibilidad en plena promoción.

Tres preguntas para tomar la decisión

1. ¿Cuánto vale una hora de tu equipo técnico? Multiplica por horas/mes en el server.
2. ¿Cuánto te cuesta una hora de downtime en tu plataforma? Multiplica por probabilidad anual.
3. ¿Estás listo para responder un domingo a las 9 am cuando el server falla?

Si las tres respuestas no son cómodas, considera migrar. Hay opciones gestionadas con SLA que cubren ese hueco.

Cómo migrar desde Nginx-RTMP a un gestionado sin downtime

Migrar suena traumático. En la práctica, con un plan decente, son 2-3 días de trabajo sin interrumpir transmisiones programadas. Te dejamos el playbook que hemos usado 30+ veces en los últimos años.

Día 1: Setup paralelo

1. Crear cuenta en la plataforma gestionada (XtreamCast, Wowza Cloud, lo que decidas).
2. Configurar canal con mismas calidades que tu Nginx (480p+720p+1080p, mismos bitrates).
3. Probar emisión desde OBS apuntando al nuevo endpoint RTMP. Verifica que el HLS sale correctamente.
4. Embeber el nuevo player en una página de staging.

Día 2: Doble emisión

1. Configurar OBS con dos servidores RTMP simultáneos (output settings -> add server, o usar plugin OBS-multi-rtmp).
2. Emitir un evento real a ambos endpoints. Comparar latencia, estabilidad, calidad.
3. Validar restream multicanal en el gestionado (si aplica).
4. Si todo funciona: cambiar el embed en tu web de staging a producción, pero mantener el viejo URL como fallback.

Día 3: Switchover y monitoreo

1. Apuntar OBS solo al nuevo servidor.
2. Monitorear primera semana en paralelo: viewers, bitrate, errores reportados.
3. Mantener Nginx-RTMP viejo encendido como fallback durante 30 días.
4. Al mes, si no hubo necesidad de fallback, apagar VPS viejo. Ahorro inmediato.

Lo que más sale mal en migraciones

• URLs hardcodeadas en apps móviles: si tienes Android/iOS apps, hay que publicar nueva versión antes del switchover.
• Embed code obsoleto en sitios de terceros: revisa quién tiene tu player embebido (clientes, partners).
• Bookmarks de viewers en URLs HLS directas: los viewers heavy a veces guardan el .m3u8 directo. Setear redirects 301 ayuda.
• Stream keys distintas: documentar bien la nueva key y rotarla en todos los encoders.

Operamos servers de RTMP profesional desde 2011. Migrar a un gestionado no significa que el RTMP esté muerto. Significa que dejas que otro lo opere mientras tú haces lo que de verdad mueve la aguja: contenido. Más sobre nuestros servers RTMP gestionados.