Des rendus qu'aucune mise en ligne n'interrompt

Un rendu PageToVid est un travail lourd. Un vrai navigateur Chromium filme le site, ffmpeg découpe et encode les clips, et Remotion décode chaque image pour assembler le MP4 final. Jusqu'ici, tout cela tournait dans le même serveur que celui qui affiche les pages web.

Or ce serveur a d'autres tâches. Il est mis à jour à chaque livraison, il se réduit quand le trafic est calme, et on peut lui demander deux films à la fois. Nous voulions qu'un film en cours soit intouchable, quoi qu'il se passe autour : une nouvelle version qui part, une nuit tranquille ou un lot de plusieurs vidéos commandées ensemble.

La veille, nous avions déjà rendu l'attente plus douce : la voix et le calage des mots tournent maintenant en parallèle de l'enregistrement, et le moteur vidéo se prépare dès le démarrage du serveur. Aujourd'hui, nous avons changé l'endroit où vit le travail.

Chaque rendu tourne désormais dans sa propre exécution Cloud Run Job. Quand vous lancez un film, le service web fait une seule petite chose : il demande une nouvelle tâche, un appel d'environ 200 millisecondes. Cette tâche reçoit une large mémoire pour elle seule, rend exactement un film du début à la fin, puis s'arrête.

Le service web revient à ce qu'il fait bien, servir les pages et répondre à la barre de progression, et il peut le faire sur une machine plus petite. Le gros du travail est parti vers un endroit conçu pour lui.

Sur l'ordinateur d'un développeur, il n'y a pas de service de tâches : la même chaîne tourne simplement dans le même processus qu'avant. Un seul chemin de code, deux endroits pour l'exécuter.

La différence ne se voit pas dans le film lui-même, et c'est tout l'intérêt. Ce qui change, c'est tout ce qui pouvait se mettre en travers de sa route :

• Les mises en ligne n'atteignent plus les rendus. Nous pouvons livrer une nouvelle version du site pendant que des films se rendent ; les tâches déjà lancées continuent sans être touchées.
• Les lots tournent côte à côte. Commandez plusieurs vidéos à la fois et chacune a sa propre tâche : elles se rendent en parallèle au lieu de faire la queue sur la même machine.
• Chaque film a de l'espace. Aucun film ne partage sa mémoire avec un autre, donc une page longue ou un storyboard dense dispose de toute la machine.
• Une tâche qui échoue peut être relancée. La plateforme sait redémarrer une tâche, ce qu'une requête dans un serveur web n'a jamais su faire.

Nous avons aussi fait en sorte que la livraison déploie la tâche de rendu à partir de l'image même qu'elle vient de construire pour le site. La page que vous voyez et le programme qui fabrique votre film tournent toujours sur le même code, et ce programme a sa propre commande de démarrage de production, vérifiée dès son premier jour.

L'isolement nous a aussi permis de rendre l'attente plus honnête. Un film qui ne progresse plus pendant plus de huit minutes est désormais marqué en échec au lieu de laisser la barre figée, et vous obtenez un bouton pour réessayer. Le même garde-fou protège l'état exposé par l'API publique : un développeur qui interroge un film reçoit la même réponse claire.

Quand un film échoue, son crédit revient automatiquement, une seule fois, que l'échec vienne de la chaîne, d'un nouveau rendu d'un storyboard modifié ou du garde-fou. Un échec traité termine proprement la tâche, pour que la plateforme ne la relance pas par erreur.

L'examen qualité par IA qui note chaque film attend lui aussi d'avoir fini avant que la tâche s'arrête. Votre film est livré d'abord ; la tâche reste simplement quelques secondes de plus pour écrire sa note.

Déplacer les rendus nous a donné l'occasion de revoir toute la chaîne, et une série de petites améliorations est partie avec :

• Les images du web dont dépend une scène graphique sont vérifiées avant le rendu : une image disparue devient une scène de texte propre plutôt qu'un arrêt près de la fin.
• Un calage des mots qui couvre moins des trois quarts du script est écarté, car un calage partiel comprimait des scènes en éclairs d'une demi-seconde.
• Le surlignage des sous-titres est désormais compté de façon cumulative, et reste donc synchrone avec la voix sur un long storyboard.
• Les clips sont coupés au moment où l'action a vraiment lieu, mesuré pendant l'enregistrement : plus d'attente figée au début ni de fin tronquée.
• Chaque page a un temps de chargement borné : un site rempli de scripts de suivi ne peut plus bloquer une scène pendant une minute et demie.
• La progression est enregistrée une fois par pourcentage visible, et non plus à chaque image.

Ensemble, elles rendent un rendu plus court, plus calme et plus prévisible. Vous pouvez voir ce qui en sort sur la page des vidéos.