Blog de StreamHousestreaming 24/7 vps

Streaming 24/7 en un VPS o en un servicio en la nube gestionado

Montar un directo 24/7 en un VPS con FFmpeg parece sencillo hasta que la lista de reproducción vuelve a empezar, el proceso muere de madrugada o un segundo destino duplica tu tráfico de salida. Esto es lo que implica de verdad hacerlo tú mismo y cuándo compensa más un servicio gestionado.

Lectura de unos 7 min

En esta página

Puedes hacer streaming 24/7 en un VPS con FFmpeg: subes tus vídeos a un servidor alquilado, escribes una lista de concatenación y la reproduces en bucle hacia la URL RTMP de una plataforma. Funciona, y puede ser un buen proyecto para aprender. El coste real es tu tiempo, que se va en codificación, recuperación tras caídas, monitorización y planificación del ancho de banda.

Aquí tienes lo que implica de verdad hacerlo por tu cuenta y cuándo un servicio gestionado es mejor inversión de tus horas.

Puntos clave

  • Un bucle básico de FFmpeg se monta rápido; lo difícil es mantenerlo funcionando durante meses.
  • Frame rates o marcas de tiempo que no coinciden pueden tumbar una lista en modo copia y devolverla al principio.
  • FFmpeg no se reinicia solo ni te avisa cuando falla.
  • Cada destino adicional suma su bitrate completo al tráfico de salida.

Cómo es un montaje casero en un VPS

La configuración autoalojada típica tiene cuatro piezas:

  1. Un VPS Linux con espacio en disco para tu biblioteca y transferencia de salida suficiente para un directo que nunca se detiene.
  2. Tus archivos de vídeo, subidos por SFTP o sincronizados desde un almacenamiento.
  3. Un archivo de lista de reproducción para el demuxer concat de FFmpeg.
  4. Un comando de FFmpeg que lee la lista en tiempo real, la repite en bucle y la envía a una URL de ingesta como rtmp://a.rtmp.youtube.com/live2 más tu clave.

La mayoría de los tutoriales usan el modo de copia de flujo (stream copy), en el que FFmpeg pasa el vídeo y el audio sin recodificarlos. El uso de CPU es mínimo, así que un servidor pequeño basta, y el primer directo se pone en marcha realmente rápido.

El problema: el modo copia solo funciona bien cuando todos los archivos son técnicamente coherentes, y ahí es donde se va el esfuerzo a largo plazo.

Codificación y marcas de tiempo: por qué se reinician las listas de FFmpeg

Con stream copy, FFmpeg une los archivos tal cual están, así que un solo archivo raro rompe las transiciones. Los culpables habituales:

  • Frame rates distintos, como una exportación a 29,97 fps junto a archivos de 30 fps, o una grabación de móvil con frame rate variable.
  • Resoluciones o formatos de audio diferentes, como un clip de 720p entre archivos de 1080p.
  • Timebases extraños o marcas de tiempo ausentes que dejan algunos editores y grabadores de pantalla.

Los síntomas van desde advertencias en el log hasta vídeo congelado o FFmpeg cerrándose. Cuando se reinicia, la lista vuelve a empezar desde el primer vídeo, así que los espectadores ven la misma primera hora una y otra vez.

La solución es recodificar todo a un único perfil antes de que entre en la lista: misma resolución, frame rate constante, mismo intervalo de fotogramas clave y mismo formato de audio. Consulta los ajustes de codificación para streaming 24/7.

Caídas, reinicios y monitorización por tu cuenta

FFmpeg es excelente, pero es un único proceso al que le da igual seguir vivo. Cuando la plataforma corta la conexión, la red tiene un microcorte o un archivo provoca un error, se cierra, y nada lo vuelve a levantar a menos que hayas montado:

  • Un supervisor, como un servicio de systemd con reinicio automático.
  • Seguimiento de la posición, para que un reinicio no empiece la lista desde arriba.
  • Comprobaciones de estado que confirmen que la plataforma recibe vídeo, porque un proceso en marcha puede seguir apareciendo como desconectado.
  • Alertas en tu móvil, para que una caída a las 3 de la madrugada no dure hasta el desayuno.

Luego está el mantenimiento: actualizaciones, reinicios del servidor, discos que se llenan de logs y claves de transmisión en scripts de texto plano. Nada de esto es difícil por separado; todo junto es un trabajo a media jornada. Consulta cómo monitorizar la salud y el uptime del directo para saber qué vigilar.

Ancho de banda y varios destinos desde un solo servidor

Un directo sin pausa consume más datos de lo que la gente espera. Un solo stream de 6 Mbps funcionando durante 30 días envía aproximadamente 1,9 TB. Si lo mandas a tres plataformas, el servidor empuja unos 18 Mbps las 24 horas, cerca de 6 TB al mes. Revisa la transferencia de salida incluida en tu proveedor y las condiciones por exceso.

El FFmpeg con varios destinos tiene sus propias rarezas. Un proceso por plataforma significa varios procesos que supervisar. El muxer tee de FFmpeg envía una entrada a varias salidas, pero un solo destino que falle, por ejemplo una plataforma que rechaza una clave caducada, puede tumbar todo el proceso si no configuras cada salida para tolerar fallos.

Las particularidades de cada plataforma también son cosa tuya, como el límite de archivo de 12 horas de YouTube, que un bucle simple ignora.

Cuándo tiene sentido un directo casero en un VPS

Autoalojar encaja cuando se cumplen la mayoría de estos puntos:

  • Te manejas bien en la línea de comandos de Linux y disfrutas manteniendo sistemas.
  • Emites a un solo destino, o estás dispuesto a diseñar la gestión de fallos para varios.
  • Tu biblioteca es pequeña y estable, y controlas cómo se exporta cada archivo.
  • Que la lista se reinicie de vez en cuando desde el principio no es grave para tu audiencia.
  • Quieres aprender cómo funciona el streaming por dentro.

Un servicio gestionado tiene más sentido cuando el directo sostiene ingresos o una marca, añades vídeos a menudo, necesitas varias plataformas o tu tiempo rinde más creando contenido. La comparación justa es la factura del servidor más las horas de configuración y los arreglos de madrugada, frente a un servicio que ya ha resuelto esos problemas.

El mismo bucle 24/7, pero en StreamHouse

StreamHouse sustituye cada pieza de ese montaje. Los vídeos subidos se preparan de antemano con un único perfil de codificación coherente, lo que mantiene estables el bitrate y las marcas de tiempo, así que un archivo discordante no reinicia tu lista. Crea la lista de reproducción en el navegador, añade destinos como YouTube, Twitch, Rumble, Facebook, RTMP personalizado o SRT, y pulsa Iniciar o programa una hora.

El bucle funciona 24/7 en la nube y se reconecta automáticamente tras fallos de la plataforma o de la red. Añade, quita o reordena vídeos en pleno directo; los cambios se aplican en el siguiente vídeo. Los destinos adicionales no consumen más huecos de stream y, con un canal de YouTube conectado, la protección de grabación puede cerrar la primera emisión en el punto que elijas y continuar en una nueva sin reiniciar la lista.

Compara suscripciones y créditos de pago por uso en la página de precios.

Preguntas frecuentes

¿Puedo hacer un directo 24/7 en YouTube con FFmpeg en un VPS?

Sí. Un comando de FFmpeg en bucle apuntando a la URL RTMP de YouTube mantiene un canal en directo. Lo difícil es mantenerlo sano durante semanas: la codificación coherente, los reinicios automáticos, la monitorización y el archivo de emisiones largas corren de tu cuenta.

¿Por qué mi lista de FFmpeg vuelve a empezar desde el principio?

Normalmente porque un archivo no coincide con el resto: tiene otro frame rate, otra resolución u otro formato de audio. En modo copia se rompen las marcas de tiempo, FFmpeg se cierra y vuelve a empezar por el primer vídeo. Recodifica todos los archivos a un único perfil constante.

¿Cuánto ancho de banda consume un directo 24/7 al mes?

Unos 1,9 TB para un stream de 6 Mbps funcionando sin parar durante 30 días, y proporcionalmente más con bitrates mayores o destinos adicionales. Tres plataformas con ese bitrate suponen cerca de 6 TB, así que revisa antes la transferencia incluida en tu servidor.

¿Necesito un VPS potente para emitir 24/7?

No si precodificas los archivos y usas stream copy, que apenas necesita CPU. Codificar 1080p en tiempo real en el servidor es otra historia: requiere núcleos dedicados, y los planes compartidos pequeños a menudo no llegan a velocidad de tiempo real.

Siguientes pasos