Pourquoi nous sommes passés de Remotion à HyperFrames pour la génération vidéo IA

Construire des pipelines vidéo automatisés sur l'automatisation d'un navigateur web semble élégant sur le papier. Des composants React composent les scènes visuelles, les styles CSS gèrent les transitions, et une instance Chromium headless transfère chaque trame vers FFmpeg. Nous avons fait tourner ce pipeline en production pendant plusieurs mois sur des dizaines de lots de vidéos internes et clientes.

Cependant, au début de cette semaine, une série de mesures précises sur notre vidéo de lancement de 38,8 secondes a imposé une révision immédiate de notre architecture.

Le pipeline Remotion nécessitait 74,2 secondes pour produire le fichier MP4 final, générant un document de 21,0 Mo. La même composition réécrite pour HyperFrames a terminé son rendu en 22,4 secondes, pour une taille de 11,2 Mo, tout en obtenant une note de 8,6 sur 10 lors de notre audit visuel automatique sur 18 trames.

Il s'agit d'une accélération de 3,3 fois et d'une réduction de 47 % du poids du fichier, sans aucune perte de netteté typographique ni de décalage sonore. Voici l'explication technique détaillée des limites du navigateur sans tête en production vidéo, et comment le rendu direct sur GPU transforme les coûts de fabrication.

La charge cachée de Chromium headless#

Pour comprendre pourquoi Remotion ralentit lors des rendus en série, il faut analyser comment Chromium transforme du code en trames vidéo.

Remotion ne traite pas le navigateur comme un affichage en temps réel. Il avance virtuellement dans le temps, trame après trame. Pour une vidéo de 38,8 secondes à 30 images par seconde, le calcul est implacable :

38,8 secondes × 30 fps = 1 164 trames

Pour chacune de ces 1 164 trames, le moteur applique la séquence suivante :

1. Avancement du temps virtuel dans le runtime React.
2. Calcul des modifications de mise en page React et recalcul des styles CSS.
3. Rastérisation du DOM dans la couche de composition de Chromium.
4. Capture du tampon de pixels via le protocole DevTools.
5. Transfert des pixels bruts via communication inter-processus (IPC) vers FFmpeg.
6. Encodage de la trame en vidéo H.264.

Même avec une exécution en parallèle sur plusieurs cœurs, cette architecture consacre la majorité de ses cycles processeur à sérialiser et désérialiser des données entre processus distincts. Des instances complètes de navigateurs sont lancées uniquement pour extraire des images fixes. Le processeur passe plus de temps à gérer des mémoires tampons IPC et à recalculer des mises en page web qu'à encoder la vidéo.

Sur des serveurs cloud mutualisés, cette surcharge s'aggrave rapidement. L'empreinte mémoire atteint 1,5 Go par processus de rendu, la concurrence entre fils d'exécution dégrade la régularité du rendu, et les files d'attente s'allongent.

Le rendu GPU direct : l'approche HyperFrames#

HyperFrames aborde la programmation vidéo depuis le pipeline graphique plutôt que par la couche d'automatisation de navigateur.

Au lieu d'exécuter un moteur de navigation complet pour récupérer des images via un pont de débogage à distance, HyperFrames compile directement un arbre de composition déclaratif en instructions de dessin graphique. Textes, tracés SVG, images et pistes audio résident sur une chronologie déterministe unique et navigable à l'image près.

Lorsque vous lancez la compilation, chaque trame est évaluée directement :

# Commande de rendu SceneVerso
hyperframes render \
  --project ./timeline \
  --out ./out/render.mp4 \
  --width 1920 \
  --height 1080 \
  --fps 30

En éliminant l'isolation de processus de Chromium et les allers-retours de capture de DevTools, le goulet d'étranglement de l'IPC disparaît totalement. Le moteur lit l'état de la composition directement en mémoire vive, applique des transformations avec accélération matérielle, et transmet le flux directement à l'encodeur vidéo.

Les mesures comparatives sur le terrain#

Nous avons testé les deux moteurs sur un contenu strictement identique : 38,80 secondes de vidéo comprenant 4 scènes narratives, de la typographie cinétique calée au millième, des pictogrammes SVG, une nappe audio avec atténuation automatique et 11 coupes visuelles.

Voici les données enregistrées directement sur nos serveurs de calcul :

Le facteur temps réel constitue un seuil décisif pour les outils de développement. Un système fonctionnant à 0,52× oblige à attendre deux secondes pour chaque seconde de vidéo produite. À 1,73×, la génération dépasse la vitesse de lecture normale : un clip de 30 secondes se calcule en moins de 18 secondes.

La diminution de la taille du fichier est également un résultat marquant. Les deux outils étaient configurés pour produire du H.264 standard en 1080p. Cependant, HyperFrames contrôle directement les espaces de couleurs et le mélange alpha avant la phase d'encodage, ce qui élimine les artefacts de lissage du navigateur sur les contours vectoriels. Des plans rastérisés plus nets se compressent beaucoup mieux avec un facteur de qualité constant standard (CRF 18).

Les cas d'usage où nous conservons Remotion#

Tout choix d'ingénierie repose sur des compromis. Remplacer Remotion comme moteur principal ne signifie pas l'abandonner.

Remotion reste particulièrement efficace pour deux catégories de tâches que SceneVerso continue de prendre en charge en seconde option :

1. Les graphiques mathématiques et les mises en page dynamiques complexes : Lorsqu'un projet nécessite un retour automatique à la ligne complexe en flexbox, des tableaux adaptatifs ou le suivi précis de trajectoires SVG reposant sur les API de mesure de texte du navigateur (comme measureText), le moteur de rendu de Chromium offre des garanties géométriques difficiles à égaler.
2. L'écosystème de composants React existants : Si vous intégrez des bibliothèques de composants React complexes (comme des tableaux de bord interactifs ou des cartes géographiques), les exécuter dans leur environnement React d'origine reste le choix le plus direct.

Pour ces cas spécifiques, SceneVerso permet de sélectionner le moteur directement dans le fichier manifeste du projet :

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

Par défaut, l'outil utilise HyperFrames pour les vidéos narratives, les formats courts et les présentations de produit.

Les répercussions sur les coûts de SceneVerso#

Cette transition transforme directement la rentabilité de notre chaîne de production automatisée.

SceneVerso applique une règle stricte : vous vérifiez et validez le manifeste de production avant qu'un seul centime ne soit engagé auprès de modèles vocaux externes ou d'API cloud. Notre objectif économique se situe entre 0,13 $ et 0,16 $ par minute de vidéo finalisée :

• Synthèse vocale ElevenLabs : environ 0,09 $ par minute (modèles Voice DNA personnalisés)
• Droits audio de la musique : environ 0,04 $ par minute
• Calcul du rendu vidéo : environ 0,01 $ par minute (sur nos serveurs dédiés)

Quand chaque rendu durait 74 secondes, les serveurs saturaient très vite lors des traitements par lots. À 22 secondes par vidéo, une seule machine dédiée peut produire plus de 150 vidéos terminées par heure sans surchauffe ni saturation de mémoire.

Pour les chaînes marketing automatisées, la vitesse n'est pas un simple confort. C'est ce qui distingue une commande de terminal réactive d'une tâche de fond lente.