Por qué cambiamos de Remotion a HyperFrames para la generación de vídeo con IA

Construir sistemas automatizados de vídeo sobre la automatización de navegadores web parece una solución atractiva sobre el papel. Componentes de React construyen las escenas visuales, las reglas de CSS gestionan las transiciones y una instancia headless de Chromium envía los fotogramas a FFmpeg. Mantuvimos nuestra infraestructura de producción con esta arquitectura durante meses a lo largo de docenas de proyectos internos y de clientes.

Sin embargo, a principios de esta semana realizamos pruebas de rendimiento exhaustivas sobre nuestro vídeo principal de 38,8 segundos. Los resultados exigieron un cambio inmediato en nuestra arquitectura técnica.

El sistema basado en Remotion tardó 74,2 segundos en generar el archivo MP4 final, con un peso de 21,0 MB. La misma composición visual adaptada para HyperFrames se completó en 22,4 segundos, pesó 11,2 MB y obtuvo una calificación de 8,6 sobre 10 en nuestra auditoría automática de calidad sobre 18 fotogramas.

Representa una aceleración de 3,3 veces y una reducción del 47 % en el tamaño del archivo, sin perder definición tipográfica ni sincronización con el audio. A continuación detallamos los motivos técnicos por los que los navegadores headless encuentran límites en la producción de vídeo y cómo el renderizado directo por GPU transforma la rentabilidad de los medios programáticos.

El coste computacional de Chromium headless#

Para comprender por qué Remotion se ralentiza durante las ejecuciones por lotes, es necesario seguir el proceso mediante el cual Chromium transforma código en fotogramas de vídeo.

Remotion no interactúa con el navegador como una pantalla en tiempo real. Avanza a través del tiempo virtual fotograma a fotograma. Para un vídeo de 38,8 segundos a 30 fotogramas por segundo, el cálculo es directo:

38,8 segundos × 30 fps = 1.164 fotogramas

En cada uno de esos 1.164 fotogramas, el sistema ejecuta la siguiente secuencia:

1. Envío del avance temporal virtual al entorno de React.
2. Cálculo de actualizaciones de diseño en React y recálculo de estilos CSS.
3. Rasterización del DOM en la capa de composición de Chromium.
4. Extracción del búfer de píxeles mediante DevTools Protocol o transferencia de canvas.
5. Envío de los píxeles sin comprimir mediante comunicación entre procesos (IPC) a FFmpeg.
6. Codificación del fotograma en bruto a vídeo H.264.

Incluso utilizando paralelismo en múltiples núcleos, esta arquitectura consume la mayor parte de sus ciclos procesando datos a través de los límites entre procesos. Se inician motores completos de navegación únicamente para capturar imágenes fijas. El procesador dedica más tiempo a gestionar búferes IPC y recalcular maquetas web que a codificar vídeo propiamente dicho.

En servidores en la nube de alta concurrencia, esta carga se multiplica. La memoria se eleva a 1,5 GB por proceso de trabajo, la contención entre hilos ralentiza la generación y las colas de procesamiento se saturan.

Renderizado directo en GPU: la propuesta de HyperFrames#

HyperFrames aborda la generación programática de vídeo desde el canal de gráficos en lugar de utilizar la capa de automatización de navegadores.

En lugar de ejecutar un navegador completo para extraer fotogramas a través de un puente de depuración, HyperFrames compila árboles declarativos de composición directamente en instrucciones gráficas. Textos, trazos SVG, imágenes y pistas de audio conviven en una línea temporal única, determinista y navegable fotograma a fotograma.

Al ejecutar la compilación, cada fotograma se procesa de forma nativa:

# Comando de renderizado en SceneVerso
hyperframes render \
  --project ./timeline \
  --out ./out/render.mp4 \
  --width 1920 \
  --height 1080 \
  --fps 30

Al prescindir del aislamiento de procesos de Chromium y de las transferencias de DevTools, el cuello de botella de la comunicación entre procesos desaparece por completo. El motor accede al estado de la composición directamente desde la memoria RAM, aplica transformaciones aceleradas por hardware y envía el flujo directamente al codificador.

Datos comparativos de telemetría#

Evaluamos ambos motores con entradas idénticas: 38,80 segundos de vídeo con 4 escenas narrativas, tipografía cinética ajustada al milisegundo, iconos vectoriales SVG, música de fondo con atenuación automática y 11 cortes visuales.

Estos son los registros obtenidos directamente en nuestras máquinas de compilación:

El factor de tiempo real es decisivo en herramientas dirigidas a desarrolladores. Un sistema que opera a 0,52× obliga a esperar unos dos segundos por cada segundo de vídeo generado. A 1,73×, la velocidad de procesamiento supera a la reproducción: un clip de 30 segundos se genera en menos de 18 segundos.

La disminución en el tamaño del archivo también resultó muy significativa. Ambos compositores se configuraron para generar vídeo estándar en 1080p H.264. Sin embargo, HyperFrames gestiona los espacios de color y las mezclas alfa antes de la codificación, eliminando los bordes difusos típicos del suavizado de fuentes en navegadores. Planos rasterizados más limpios se comprimen con mucha mayor eficiencia con un factor de calidad constante habitual (CRF 18).

Casos en los que conservamos Remotion#

Toda decisión técnica implica evaluar ventajas e inconvenientes. Cambiar el compositor por defecto no significa descartar Remotion.

Remotion continúa destacando en dos tareas concretas que SceneVerso mantiene como opción secundaria:

1. Gráficos matemáticos y composiciones dinámicas avanzadas: Cuando un proyecto requiere saltos de línea automáticos con flexbox, tablas adaptables o trazos de vectores SVG que dependen de las API de medición de texto del navegador (como measureText), Chromium aporta garantías de diseño difíciles de igualar.
2. Componentes del ecosistema React: Si un flujo incorpora bibliotecas complejas de React (como tablas de datos interactivas o mapas), ejecutarlas en su entorno nativo sigue siendo la alternativa más fiable.

Para estos casos específicos, SceneVerso permite definir el motor en el manifiesto del proyecto:

{
  "version": "1.0",
  "project": "architecture-diagram",
  "engine": "remotion",
  "scenes": [...]
}

Si no se especifica ningún motor, el sistema aplica automáticamente HyperFrames a vídeos narrativos, clips breves y presentaciones de producto.

Efectos en los costes de SceneVerso#

Esta evolución optimiza la estructura de costes de nuestra plataforma de vídeo automatizado.

SceneVerso se basa en un principio estricto: revisas y apruebas el manifiesto de producción antes de incurrir en costes con modelos de voz externos o APIs en la nube. Nuestro objetivo de costes unitarios se sitúa entre 0,13 $ y 0,16 $ por minuto de vídeo final:

• Síntesis de voz con ElevenLabs: ~0,09 $ por minuto (modelos Voice DNA a medida)
• Pistas de audio con licencia: ~0,04 $ por minuto
• Cómputo de renderizado: ~0,01 $ por minuto (en servidores dedicados)

Cuando cada clip requería 74 segundos, los servidores se saturaban rápidamente al procesar lotes de trabajo. Con 22 segundos por vídeo, un único nodo dedicado puede producir más de 150 vídeos finalizados por hora de forma continua y sin sobrecalentamiento ni saturación de memoria.

En la producción automatizada de contenidos, la velocidad no es solo una ventaja operativa. Marca la diferencia entre una herramienta de consola interactiva y un proceso en segundo plano lento.