Renders que ninguna nueva versión puede cortar

Un render de PageToVid es trabajo pesado. Un navegador Chromium real graba el sitio, ffmpeg corta y codifica los clips y Remotion decodifica cada fotograma para montar el MP4 final. Hasta ahora, todo eso corría dentro del mismo servidor que sirve las páginas web.

Pero ese servidor tiene otras tareas. Se actualiza cada vez que publicamos, se reduce cuando hay poco tráfico y puede recibir dos vídeos a la vez. Queríamos que un vídeo en marcha fuera intocable, pasara lo que pasara alrededor: una nueva versión saliendo, una noche tranquila o un lote de varios vídeos pedidos juntos.

El día anterior ya habíamos hecho la espera más llevadera: la voz y la sincronización de palabras corren ahora en paralelo con la grabación, y el motor de vídeo se prepara al arrancar el servidor. Hoy cambiamos el lugar donde vive el trabajo.

Cada render corre ahora en su propia ejecución de Cloud Run Job. Cuando inicias un vídeo, el servicio web hace una sola cosa pequeña: pide una tarea nueva, una llamada de unos 200 milisegundos. Esa tarea recibe mucha memoria solo para ella, renderiza exactamente un vídeo de principio a fin y termina.

El servicio web vuelve a lo que hace bien, servir páginas y responder a la barra de progreso, y puede hacerlo en una máquina más pequeña. El trabajo duro se ha ido a un lugar pensado para él.

En el portátil de un desarrollador no hay servicio de tareas, así que la misma cadena corre en el mismo proceso que antes. Un solo camino de código, dos sitios donde ejecutarlo.

La diferencia no se ve en el vídeo, y de eso se trata. Lo que cambia es todo lo que antes podía cruzarse en su camino:

• Las nuevas versiones ya no llegan a los renders. Podemos publicar una nueva versión del sitio mientras se renderizan vídeos; las tareas en marcha siguen sin que nada las toque.
• Los lotes corren en paralelo. Pide varios vídeos a la vez y cada uno tendrá su propia tarea, así que se renderizan a la par en vez de hacer cola en la misma máquina.
• Cada vídeo tiene espacio. Ningún vídeo comparte memoria con otro, de modo que una página larga o un guion gráfico denso disponen de toda la máquina.
• Una tarea que falla se puede reintentar. La plataforma sabe volver a lanzar una tarea, algo que una petición dentro de un servidor web nunca pudo hacer.

Además, el proceso de publicación despliega la tarea de render a partir de la misma imagen que acaba de construir para el sitio. La página que ves y el programa que hace tu vídeo siempre usan el mismo código, y ese programa tiene su propio comando de arranque de producción, comprobado desde su primer día.

El aislamiento también nos permitió que la espera fuera más honesta. Un vídeo que no avanza durante más de ocho minutos se marca ahora como fallido en vez de dejar la barra congelada, y te aparece un botón para reintentar. El mismo vigilante protege el estado que da la API pública, así que un desarrollador que consulta un vídeo recibe la misma respuesta clara.

Cuando un vídeo falla, su crédito vuelve automáticamente, una sola vez, tanto si el fallo viene de la cadena, de un nuevo render de un guion editado o del vigilante. Un fallo gestionado termina la tarea limpiamente, para que la plataforma no la relance por error.

La revisión de calidad con IA que puntúa cada vídeo también espera a terminar antes de que se cierre la tarea. Tu vídeo se entrega primero; la tarea solo se queda unos segundos más para escribir su puntuación.

Mover los renders nos dio motivo para revisar toda la cadena, y con ello llegaron varias mejoras pequeñas:

• Las imágenes de la web de las que depende una escena gráfica se comprueban antes del render, así que una que ya no existe se convierte en una escena de texto limpia en vez de una parada cerca del final.
• Una sincronización de palabras que cubre menos de tres cuartas partes del guion se descarta, porque una sincronización parcial comprimía escenas en destellos de medio segundo.
• El resaltado de subtítulos se cuenta ahora de forma acumulada, y así sigue el ritmo de la voz en un guion largo.
• Los clips se recortan al momento en que la acción ocurre de verdad, medido durante la grabación: sin arranque congelado ni final cortado.
• Cada página tiene un tiempo de carga limitado, así que un sitio lleno de scripts de seguimiento ya no puede retener una escena durante minuto y medio.
• El progreso se guarda una vez por cada porcentaje visible, no en cada fotograma.

Juntas, hacen que un render sea más corto, más tranquilo y más previsible. Puedes ver lo que sale al final en la página de vídeos.