Requisitos del servidor de retransmisión en directo en hardware dedicado Actualizado el 16 de marzo de 2026 por Sam Page 7 minutos y 33 segundos de lectura Transmitir en directo a través de Twitch o YouTube está bien hasta que necesitas un control que estas plataformas no te ofrecen: latencia personalizada, múltiples transmisiones simultáneas, enrutamiento específico para cada audiencia o una configuración en la que la plataforma no se lleve ninguna comisión por la monetización. La transmisión autohospedada en un servidor dedicado resuelve todos estos problemas, pero los requisitos de hardware y configuración son específicos. Conseguir… Índice Lo que realmente exige la retransmisión en directo a un servidor Requisitos de hardware según el caso de uso Una sola transmisión, hasta 500 espectadores simultáneos Varias transmisiones o entre 500 y 5.000 espectadores simultáneos Transmisión a gran escala (más de 5000 espectadores simultáneos) Configuración de Nginx en Linux Transmite a Twitch y YouTube al mismo tiempo a través de un servidor dedicado Optimización de la transcodificación con FFmpeg Configuración del cortafuegos para la transmisión en directo Espacio de almacenamiento para la grabación de transmisiones Lo que realmente exige la retransmisión en directo a un servidor Un servidor de retransmisión en directo realiza tres operaciones distintas, cada una con un perfil de recursos diferente: Ingesta: Recibe el flujo codificado desde tu software de retransmisión (OBS, Restream, vMix) a través de RTMP (Real-Time Messaging Protocol). No consume muchos recursos de la CPU: el servidor solo acepta una conexión de red y escribe en el disco o en la memoria. Transcodificación: recodifica el flujo entrante a varios niveles de calidad (1080p, 720p, 480p, 360p) para que los espectadores con diferentes anchos de banda puedan verlo sin que se cuelgue. Requiere mucha CPU. Aquí es donde la mayoría de los servidores llegan a sus límites. Transmisión: Envía los segmentos HLS (HTTP Live Streaming) o DASH a los espectadores a través de una CDN o directamente. Requiere mucho ancho de banda. Para 100 espectadores simultáneos a 4 Mbps cada uno, eso supone 400 Mbps de ancho de banda de salida constante. Tu servidor tiene que gestionar las tres cosas a la vez, posiblemente para varias transmisiones simultáneas. Requisitos de hardware según el caso de uso Una sola transmisión, hasta 500 espectadores simultáneos Configuración mínima necesaria: InMotion Essential (99,99 $ al mes, 64 GB de DDR4, 2×1,92 TB NVMe) A 1080p30 con transcodificación x264 en el perfil «medium» a tres niveles de calidad, se espera que se utilicen al máximo entre 4 y 6 núcleos de CPU durante la transmisión en directo. El procesador del servidor Essential lo gestiona sin problemas. Con 500 espectadores simultáneos recibiendo transmisiones de 4 Mbps, el ancho de banda de salida alcanza los 2 Gbps, dentro del límite de 10 Gbps con capacidad de picos. La memoria RAM no es el cuello de botella a esta escala: entre 8 y 16 GB son suficientes para la pila de streaming. Los 64 GB ofrecen margen para el sistema operativo y cualquier otro servicio que se ejecute junto con la transmisión. Varias transmisiones o entre 500 y 5.000 espectadores simultáneos Recomendado: InMotion Elite o Extreme (199,99-349,99 $ al mes) Las operaciones con múltiples transmisiones o con un gran número de espectadores requieren o bien más núcleos de CPU para la transcodificación simultánea, o bien suficiente RAM para almacenar en búfer los segmentos de transmisión de forma intensiva. Con 2000 espectadores simultáneos que reciben una transmisión HLS a 4 Mbps, se alcanza un ancho de banda sostenido de 8 Gbps, lo que se acerca al límite de picos y constituye un argumento de peso a favor de un ancho de banda garantizado de 10 Gbps sin restricciones. Los 16 núcleos y 32 hilos del AMD EPYC 4545P son ideales para cargas de trabajo de transcodificación simultánea. La transcodificación por software con libx264 o libvpx se adapta de forma lineal al número de núcleos: dos transmisiones simultáneas a 1080p consumen aproximadamente el doble de CPU que una sola. Transmisión a gran escala (más de 5000 espectadores simultáneos) A esta escala, el servidor dedicado se encarga de la ingesta y la transcodificación; una CDN se encarga de la distribución. El cálculo es sencillo: 5.000 espectadores a 4 Mbps suponen 20 Gbps de ancho de banda de distribución, lo que supera la capacidad real de cualquier servidor individual. Una CDN bien configurada descarga el flujo HLS de tu servidor una sola vez y lo distribuye a los espectadores; tu servidor solo ve un pequeño número de conexiones a los puntos de presencia (PoP) de la CDN, en lugar de 5.000 conexiones individuales de espectadores. Configuración de Nginx en Linux Nginx el módulo RTMP es el servidor de streaming de código abierto más habitual. En AlmaLinux o Ubuntu: # Ubuntu apt-get install nginx libnginx-mod-rtmp -y # AlmaLinux/Rocky dnf install nginx -y # Compile RTMP module or use community packages Basic Nginx configuration for ingest and HLS delivery: # /etc/nginx/nginx.conf rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # HLS delivery hls on; hls_path /var/www/html/hls; hls_fragment 3s; hls_playlist_length 60s; # Transcode to multiple qualities exec_push ffmpeg -i rtmp://localhost/$app/$name -c:v libx264 -b:v 3000k -s 1920x1080 -r 30 -c:a aac -b:a 128k -f flv rtmp://localhost/hls/$name_1080p -c:v libx264 -b:v 1500k -s 1280x720 -r 30 -c:a aac -b:a 128k -f flv rtmp://localhost/hls/$name_720p -c:v libx264 -b:v 600k -s 854x480 -r 30 -c:a aac -b:a 96k -f flv rtmp://localhost/hls/$name_480p; } application hls { live on; hls on; hls_path /var/www/html/hls; hls_fragment 3s; hls_nested on; } } } http { server { listen 80; location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } root /var/www/html; add_header Cache-Control no-cache; add_header Access-Control-Allow-Origin *; } } }# Ubuntu apt-get install nginx libnginx-mod-rtmp -y # AlmaLinux/Rocky dnf install nginx -y # Compile RTMP module or use community packages Basic Nginx configuration for ingest and HLS delivery: # /etc/nginx/nginx.conf rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # HLS delivery hls on; hls_path /var/www/html/hls; hls_fragment 3s; hls_playlist_length 60s; # Transcode to multiple qualities exec_push ffmpeg -i rtmp://localhost/$app/$name -c:v libx264 -b:v 3000k -s 1920x1080 -r 30 -c:a aac -b:a 128k -f flv rtmp://localhost/hls/$name_1080p -c:v libx264 -b:v 1500k -s 1280x720 -r 30 -c:a aac -b:a 128k -f flv rtmp://localhost/hls/$name_720p -c:v libx264 -b:v 600k -s 854x480 -r 30 -c:a aac -b:a 96k -f flv rtmp://localhost/hls/$name_480p; } application hls { live on; hls on; hls_path /var/www/html/hls; hls_fragment 3s; hls_nested on; } } } http { server { listen 80; location /hls { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } root /var/www/html; add_header Cache-Control no-cache; add_header Access-Control-Allow-Origin *; } } } Esta configuración acepta una transmisión RTMP desde OBS en el puerto 1935, la transcodifica a tres niveles de calidad mediante FFmpeg y sirve segmentos HLS a través de HTTP en el puerto 80. Configuración de transmisión de OBS: Servidor: rtmp://tu-ip-del-servidor/live Clave de transmisión: cualquier cadena (se convierte en el nombre de la transmisión) Codificador: x264 o NVENC (si hay GPU disponible) Velocidad de bits: 6.000 Kbps para una fuente de 1080p a 60 fps Transmite a Twitch y YouTube al mismo tiempo a través de un servidor dedicado Un servidor RTMP específico puede retransmitir a varias plataformas a la vez, lo que elimina la necesidad de contratar un servicio de retransmisión de pago. application live { live on; # Push to Twitch push rtmp://live.twitch.tv/app/YOUR_TWITCH_STREAM_KEY; # Push to YouTube push rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY; # Keep local HLS copy hls on; hls_path /var/www/html/hls; }application live { live on; # Push to Twitch push rtmp://live.twitch.tv/app/YOUR_TWITCH_STREAM_KEY; # Push to YouTube push rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY; # Keep local HLS copy hls on; hls_path /var/www/html/hls; } Tu emisor envía una transmisión a tu servidor dedicado; el servidor la distribuye simultáneamente a Twitch, YouTube y tu propio punto final HLS. Esto requiere un ancho de banda de salida igual a la suma de todas las velocidades de bits de destino, que suele oscilar entre 6.000 y 18.000 Kbps, dependiendo de los requisitos de cada plataforma. Optimización de la transcodificación con FFmpeg Los ajustes predeterminados de FFmpeg dan prioridad a la calidad frente al rendimiento de la CPU. Para las retransmisiones en directo, en las que se requiere un rendimiento en tiempo real, ajusta el perfil y los parámetros: ffmpeg -i rtmp://localhost/$app/$name \ -c:v libx264 \ -preset veryfast \ # Imprescindible para tiempo real: veryfast o ultrafast -tune zerolatency \ # Reduce el retraso de codificación -b:v 3000k \ -maxrate 3000k \ -bufsize 6000k \ -g 60 \ # Intervalo entre fotogramas clave (2x la velocidad de fotogramas para 30 fps) -sc_threshold 0 \ # Desactiva la detección de cambios de escena (añade latencia) -c:a aac \ -b:a 128k \ -f flv rtmp://localhost/hls/$name_1080pffmpeg -i rtmp://localhost/$app/$name \ -c:v libx264 \ -preset veryfast \ # Critical for real-time: veryfast or ultrafast -tune zerolatency \ # Reduces encoding delay -b:v 3000k \ -maxrate 3000k \ -bufsize 6000k \ -g 60 \ # Keyframe interval (2x framerate for 30fps) -sc_threshold 0 \ # Disable scene change detection (adds latency) -c:a aac \ -b:a 128k \ -f flv rtmp://localhost/hls/$name_1080p El ajuste «veryfast» reduce ligeramente la calidad de la codificación en comparación con los ajustes «slow» o «medium», pero reduce el uso de la CPU entre un 60 % y un 70 %, lo cual es esencial para la transcodificación en tiempo real en una CPU que gestiona varias secuencias u otras cargas de trabajo al mismo tiempo. La guía de codificación de FFmpeg explica con detalle las ventajas y desventajas de los distintos valores preestablecidos. Configuración del cortafuegos para la transmisión en directo Abre los puertos que necesita tu sistema de streaming: # Permitir la ingesta RTMP de emisoras nft add rule inet filter input tcp dport 1935 accept # Permitir la entrega HTTP de segmentos HLS nft add rule inet filter input tcp dport 80 accept nft add rule inet filter input tcp dport 443 accept # Restringir la ingesta RTMP a las direcciones IP de emisoras conocidas, si es posible # Sustituye por la IP real del emisor nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 1935 accept nft add rule inet filter input tcp dport 1935 drop# Allow RTMP ingest from broadcasters nft add rule inet filter input tcp dport 1935 accept # Allow HTTP delivery of HLS segments nft add rule inet filter input tcp dport 80 accept nft add rule inet filter input tcp dport 443 accept # Restrict RTMP ingest to known broadcaster IPs if possible # Replace with actual broadcaster IP nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 1935 accept nft add rule inet filter input tcp dport 1935 drop Si dejas el RTMP abierto a Internet, cualquiera puede transmitir a tu servidor. Restringir el puerto de ingesta por IP evita el uso no autorizado del ancho de banda de tu servidor. Espacio de almacenamiento para la grabación de transmisiones Las transmisiones grabadas a 1080p consumen aproximadamente 1 GB por cada 10 minutos de grabación a una velocidad de entre 12 y 15 Mbps. Para las operaciones habituales de transmisión, planifica el almacenamiento en consecuencia: 2 horas de grabación al día: unos 12 GB al día, unos 360 GB al mes El servidor Essential de InMotion incluye 2 unidades NVMe de 1,92 TB NVMe lo que da para unas 3.000 horas de grabación antes de tener que pasar el material a archivo Configure Nginx-RTMP to record to a specific path: application live { live on; record all; record_path /var/recordings; record_suffix -%d%m%Y-%H%M%S.flv; record_max_size 1000M; # Split at 1GB to keep files manageable }Configure Nginx-RTMP to record to a specific path: application live { live on; record all; record_path /var/recordings; record_suffix -%d%m%Y-%H%M%S.flv; record_max_size 1000M; # Split at 1GB to keep files manageable } El almacenamiento de copias de seguridad Premier Care de InMotion (500 GB) ofrece una copia fuera del servidor de las grabaciones importantes. Para el archivo a largo plazo, configura rclone para que sincronice el directorio de grabaciones con un almacenamiento de objetos compatible con S3 de forma programada. Lecturas relacionadas: Optimización de la latencia de red para servidores dedicados | Optimización del servidor de origen de la CDN Comparte este artículo Artículos relacionados Los servidores ecológicos InMotion Hosting: ¿qué ofrece realmente el hardware empresarial reacondicionado? RAM DDR4 vs DDR5: Una comparación en profundidad AMD EPYC frente a Intel Xeon: lo que los compradores de alojamiento web realmente necesitan saber Alojamiento en servidor dedicado para Moodle: por qué los recursos compartidos merman el rendimiento del LMS Guía de decisión para agencias que evalúan la infraestructura de alojamiento Servidores dedicados bare metal: qué son y cómo evaluar a los proveedores Cómo elegir un plan de servidor dedicado: un marco basado en la carga de trabajo ¿Qué es IPMI y por qué es importante para la gestión de servidores dedicados? Procesamiento de datos de alta frecuencia en servidores dedicados Análisis del coste total de propiedad: propiedad de un servidor dedicado durante 3 años frente a 5 años