Mesurer plutôt que supposer : coût de rendu et mémoire sur iPhone

Dans un projet de génération vidéo, les hypothèses coûtent cher. On croit qu’un effet est gratuit, qu’un calque est léger, qu’un correctif a marché : puis on rend, on mesure, et le chiffre dit autre chose. Cet article rassemble les mesures réelles de MotionMaker, celles qui ont changé nos décisions. Aucun chiffre n’y est une estimation : ce sont ceux relevés sur le moteur en production.

Le coût de rendu : ce que pèse un film

Un film de 17 secondes à 30 images par seconde compte 516 images. Le rendu serveur d’un tel film a été mesuré à environ 10 minutes 30 avec une concurrence de 2, c’est-à-dire deux images calculées en même temps. Ce chiffre sert de repère : toute modification du moteur se juge par rapport à lui.

Pourquoi 2 et pas plus ? Le réglage par défaut du moteur de rendu utilisé est de 4, et à 4 il sature les huit cœurs de la machine. Or la machine est partagée avec d’autres sites : saturer le processeur les étrangle. La concurrence est donc plafonnée à 2, et la file de rendu remplace les rendus en attente d’une même cible plutôt que de les empiler. Une demande qui attend est remplacée par la plus récente au lieu de s’ajouter à la pile.

Le grain plein écran : 54 % du temps total

Le grain est un classique : une texture de bruit donne une matière au film et masque l’aspect lisse du numérique. L’ajouter à toute l’image était tentant. La mesure a montré que le grain plein écran avait coûté 54 % du temps de rendu total : plus de la moitié du temps passée à ajouter une seule texture.

Cette leçon a fixé une règle : toute nouvelle passe plein cadre (flou, grain, filtre) doit être mesurée avant d’être gardée. Pas après, pas « à peu près » : avant. Une passe sur chaque image multiplie son coût par le nombre d’images, et ce coût s’additionne à celui des autres passes.

La profondeur de champ et les transitions caméra : +15 %

Deux ajouts ont fait gagner en qualité de mouvement : la profondeur de champ (un objectif ne rend net qu’un seul plan à la fois ; tout rendre net à toutes les profondeurs fait « sentir le calque ») et les transitions conçues comme des mouvements de caméra, fouettés avec traînée ou traversées avec flou de profondeur, jamais de simples glissements. Mesurés ensemble, ils ont ajouté environ 15 % au temps de rendu.

Un surcoût de cet ordre se discute avec un chiffre à l’appui, ce qui n’aurait pas été possible sans mesure : c’est tout l’intérêt de mesurer avant de garder un effet. Pour comprendre ce que ces mouvements apportent côté artistique, lisez anticipation et chevauchement en motion design et les courbes d’accélération expliquées.

Quand le rendu dément l’hypothèse

Plusieurs hypothèses ont été départagées par le rendu et non par la discussion : l’anisotropie des textures contre le z-fighting (deux surfaces au même endroit qui se disputent l’affichage) pour un défaut d’image, l’étalonnage contre le grain pour le coût de rendu. Dans le second cas, c’est le grain qui pesait 54 %. Aucune de ces questions ne se tranchait à la relecture du code.

La méthode est donc devenue un réflexe : rendre une image seule avec la commande de rendu d’image fixe du moteur, puis produire des planches contact avec ffmpeg pour comparer côte à côte les variantes. Vérifier en rendant, pas en relisant.

La mémoire sur iPhone : un onglet tué

L’aperçu du film se joue dans le navigateur du visiteur, y compris sur mobile. Or Safari sur iOS tue un onglet qui dépasse environ 1 à 1,5 Go de mémoire. Un aperçu qui s’affiche correctement mais fait fuir la mémoire est donc un aperçu cassé : on a mesuré trois causes, toutes invisibles à la relecture.

Cause 1 : un élément tourné, arrondi, bordé et mobile

Un élément à la fois tourné, aux coins arrondis et bordé, dont la position change à chaque image, a fait fuir la mémoire graphique jusqu’à 5 Go en 20 secondes. C’était un plan que l’on appelait la profondeur en couches. Le correctif tient en une ligne : lui donner sa propre couche de composition avec la propriété will-change: transform.

Cause 2 : la composition rastérisée à la densité de l’écran

La composition fait 1080 par 1920 pixels. Sur l’écran d’un téléphone, elle est rastérisée à la densité de l’écran, soit trois fois. La seule réduction visuelle par transformation ne suffit pas : le navigateur calcule toujours la grande image. L’aperçu mobile est donc calculé plus petit, avec la propriété zoom, au lieu d’être seulement rétréci après coup.

Cause 3 : les effets coûteux, coupés sur mobile

Flous, lueurs, effet de verre, grain, étalonnage et WebGL sont désactivés sur mobile, famille par famille. Le rendu MP4 produit sur le serveur n’est jamais concerné : le fichier que vous téléchargez garde tous ses effets, seul l’aperçu dans le navigateur est allégé.

Comment on teste la mémoire

Regarder l’écran ne suffit pas : l’affichage peut être parfait pendant que le processus enfle. Le test utilise Playwright avec WebKit et un profil d’iPhone 13. Il rejoue une réponse enregistrée pour ne pas relancer de génération, échantillonne la mémoire résidente du processus du navigateur, et plafonne la consommation à 2 Go, car un gestionnaire de mémoire du serveur tuerait sinon d’autres processus de la machine partagée. Un nouveau type de plan doit passer ce test avant d’être livré.

Ce que ça change pour les films que vous créez

• Un rendu prévisible : le temps d’un film se compte en minutes, et une nouvelle fonction ne le double pas sans qu’on l’ait mesuré.
• Un aperçu qui tient sur téléphone : il est allégé, mais l’export MP4 garde tous les effets.
• Des effets qui se justifient : la profondeur de champ est là parce qu’elle apporte une image plus crédible, pas parce qu’elle est possible.

Les mêmes principes valent pour une vidéo de marque que vous destinez aux réseaux : voir la vidéo verticale 9:16, guide complet. Et pour retrouver l’ensemble du fonctionnement : créer une vidéo depuis un site web. Pour l’autre moitié de la fiabilité du moteur, lisez même seed, même vidéo, image par image.