J'ai livré un second moteur de rendu pour que l'aperçu corresponde à l'export. Ça a empiré les choses.

Katto est un outil de découpage vidéo par IA. Vous déposez une vidéo longue, il en extrait les bons moments sous forme de shorts verticaux, et un éditeur vous laisse ajuster le cadrage, les sous-titres et la mise en page avant l'export. Je le développe seul, en public. Voici l'histoire d'une erreur que j'ai commise dans cet éditeur, et ce que sa correction m'a appris sur le principe du "ce que vous voyez est ce que vous obtenez".

Le problème que je cherchais à résoudre

Un éditeur de clips vit ou meurt sur une seule promesse. Ce que vous voyez dans l'aperçu est exactement ce que vous téléchargez. Si le sous-titre se retrouve un pixel plus haut à l'export, si le recadrage dérive, si une couleur est fausse, l'utilisateur cesse de faire confiance à l'outil. Et la confiance, c'est tout le produit.

Mon aperçu est une composition React rendue dans le navigateur. Mes exports, eux, étaient rendus sur le serveur avec FFmpeg. Deux moteurs de rendu différents dessinant le même clip. Ils divergeaient, comme on pouvait s'y attendre. Les polices des sous-titres, le rendu des emojis, le recadrage exact d'un écran partagé. Le classique "l'aperçu ne correspond pas à l'export".

La correction qui semblait juste (et qui ne l'était pas)

Alors j'ai fait la chose évidente. J'ai fait en sorte que la même composition React qui dessine l'aperçu du navigateur rende aussi l'export sur le serveur, via un Chromium headless (Remotion). Un seul composant, une seule source de vérité. Aperçu égal export, garanti.

Ce n'est pas une critique de Remotion. Il est excellent pour ce à quoi il est destiné. L'erreur était la mienne. Je l'ai greffé comme un second moteur d'export à côté d'une pipeline FFmpeg existante.

Mes clips initiaux, ceux que l'IA génère avant même que vous n'ouvriez l'éditeur, étaient toujours rendus par FFmpeg. C'est rapide, c'est éprouvé, ça fait tourner toute la pipeline. Je n'allais pas arracher ça.

Je me retrouvais donc avec deux moteurs produisant des fichiers. FFmpeg pour le clip généré, Chromium et Remotion pour le ré-export édité. La divergence exacte que je voulais éliminer était désormais pire. Le clip que vous voyiez dans votre liste de résultats (FFmpeg) et le même clip ré-exporté après une petite retouche (Remotion) pouvaient sortir subtilement différents. J'avais transformé un moteur de rendu en deux et appelé ça de la parité.

En plus de ça, le rendu Chromium était lent. Trois à quatre minutes par clip, contre environ 30 secondes pour FFmpeg. Et il échouait de temps en temps. Quand il échouait, il basculait silencieusement sur FFmpeg et remettait à l'utilisateur un fichier dont les retouches avaient discrètement disparu. Le pire échec possible. Faux, et silencieux.

Le déclic

"Aperçu égal export" ne s'obtient pas en faisant de l'aperçu le moteur de rendu. Il s'obtient en ayant une seule source de vérité pour le rendu, et en laissant l'aperçu en être une approximation fidèle.

Un Player de navigateur fait un excellent aperçu. Il n'aurait jamais dû devenir un second moteur d'export. À l'instant où il l'est devenu, je me suis retrouvé avec deux implémentations de la même géométrie, divergeant à chaque changement.

Ce que j'ai fait

• FFmpeg est le seul moteur qui produit des fichiers. La génération et le ré-export passent par la même pipeline. Les exports d'un clip typique de moins de 60s sont tombés à environ 30 secondes (j'ai mesuré 32s), contre les trois à quatre minutes que prenait le chemin Chromium.
• Le Player du navigateur est revenu à ce qu'il fait de mieux, l'aperçu interactif. Il ne rend rien de ce qui est livré.
• J'ai porté vers FFmpeg les fioritures que seul le navigateur savait faire, les sous-titres aux couleurs qui défilent mot par mot et le ratio de partage ajustable de la mise en page empilée, pour que le chemin rapide couvre les cas courants.
• Le fallback silencieux est mort. Si un rendu ne peut pas être produit fidèlement, l'utilisateur reçoit une erreur visible, jamais un fichier discrètement faux.
• Un seul jeu de coordonnées, la dernière pièce que je suis en train de terminer. Quand vous déplacez un recadrage dans l'aperçu, ces rectangles exacts devraient être ceux que FFmpeg utilise, et non une seconde géométrie que le serveur recalcule de son côté. C'est le point subtil. Même après avoir unifié le moteur, l'aperçu calculait les rectangles de recadrage d'une façon et l'export les calculait d'une autre. Je suis en train de refermer ça, en faisant consommer à FFmpeg les rectangles exacts issus de l'état de l'éditeur, car la leçon est la même un cran plus bas. Tout second calcul de la même chose est une source de divergence.

Les leçons

1. "Faire de l'aperçu le moteur de rendu" est séduisant et généralement faux. Vous vous retrouvez avec deux moteurs de rendu le jour où vous avez un autre chemin de rendu. Une seule source de vérité pour la sortie. L'aperçu l'approxime.
2. Un second moteur "pour la parité" devient une troisième source cachée de divergence. Si deux chemins de code calculent la même géométrie ou le même format, ils divergeront. La seule question, c'est quand.
3. Les fallbacks silencieux sont le péché capital. Un fichier légèrement faux sans avertissement coûte plus de confiance qu'une erreur honnête. Échouez bruyamment.
4. Vérifiez l'artefact, pas les logs. Mes logs disaient "mise en page empilée rendue". Je n'ai trouvé le vrai bug qu'en récupérant le MP4 réellement exporté depuis le stockage et en regardant une image. Les pixels sont la vérité.

Je suis un founder solo qui livre vite, en public. Celle-ci m'a coûté un détour bien intentionné. Si vous construisez un éditeur avec un aperçu et un export, le chemin le plus court vers la confiance est ennuyeux. Un seul moteur de rendu, des erreurs honnêtes, et on vérifie les images.

Katto se trouve sur katto.tech. Si vous construisez des outils vidéo, j'adorerais vraiment comparer nos notes sur la parité entre aperçu et export.