← Retour au blog
IngénierieBuild in PublicVidéo

Mon correctif d'écran partagé a passé tous les tests. Il ne corrigeait que la moitié du bug.

Mon outil IA empile deux personnes en écran partagé vertical. Près d'un tiers de ces clips dupliquaient l'image. Mon 1er correctif n'en couvrait que la moitié.

11 octobre 2026

Mon correctif d'écran partagé a passé tous les tests. Il ne corrigeait que la moitié du bug.

Créé le 12 octobre 2026 · Mis à jour le 12 octobre 2026

Katto transforme les vidéos longues en clips verticaux. Je le construis seul, en public. Le 10 octobre, j'ai corrigé un bug de géométrie de l'écran partagé (split screen), je l'ai testé, déployé, et j'ai écrit « corrigé » dans le changelog. Le soir même, j'ai retrouvé le même bug, toujours là. Et même après l'avoir corrigé deux fois, l'écran partagé n'était toujours pas bon.

À quoi sert un écran partagé

Un podcast ou une interview est en général filmé en plan large : deux personnes à une table, une de chaque côté d'une image 16:9. Un short vertical, c'est du 9:16. Si on recadre au centre, on obtient la table et aucun visage. Si on suit la personne qui parle, l'autre disparaît chaque fois qu'elle répond.

Quand les deux personnes sont assez éloignées l'une de l'autre, Katto fait autre chose : il découpe une fenêtre autour de chaque personne et les empile, l'une au-dessus de l'autre. Deux panneaux de demi-hauteur, les deux visages visibles en permanence. C'est la réponse classique au plan à deux intervenants, et c'est ce que décrit la page de recadrage.

Ce qui n'allait pas

Chaque panneau a une largeur, et le code plafonnait cette largeur pour que les deux fenêtres ne se chevauchent pas. Ce plafond était calculé à partir de la distance entre les deux personnes. Ça paraît raisonnable, et ça mesure la mauvaise chose.

Voici un cas réel. Une source de 1920 pixels de large, les deux personnes à 1300 pixels l'une de l'autre. Le plafond tombait à 1235, la largeur du panneau à 1214, donc le plafond ne s'appliquait pas. Ensuite, chaque fenêtre était centrée sur sa personne, puis ramenée dans l'image là où elle dépassait du bord. La fenêtre de gauche s'est décalée de 358 pixels vers la droite, celle de droite de 236 pixels vers la gauche. L'une vers l'autre.

Deux fenêtres de 1214 pixels ont besoin de 2428 pixels pour tenir côte à côte. L'image en fait 1920. Quoi qu'on en fasse, au moins 508 pixels se retrouvent dans les deux panneaux à la fois.

Une image de 1920 pixels avec deux fenêtres de 1214 pixels : il leur faut 2428 pixels, donc au moins 508 pixels tombent dans les deux

À l'écran, ça donne une bande de la même image en bas du panneau du haut et en haut du panneau du bas : une épaule en double, un demi-visage en double, parfois la personne entière en double.

La règle dont j'aurais dû partir tient en une ligne : deux fenêtres de largeur W ne tiennent côte à côte que si 2W ne dépasse pas la largeur de l'image. La distance entre les personnes n'a rien à voir là-dedans.

À quelle fréquence c'est arrivé

J'ai repris les clips en écran partagé que Katto avait déjà livrés et j'ai lu le chevauchement directement dans leur géométrie enregistrée : le bord droit de la première fenêtre moins le bord gauche de la seconde.

31 % d'entre eux se chevauchaient. Parmi ceux-là :

ChevauchementPartCe qu'on voit
300 px ou plus18 %une personne ou un buste en double
150 à 299 px15 %un morceau de corps sur le bord intérieur
60 à 149 px36 %une bande de décor
moins de 60 px30 %rien qu'on remarquerait

Les pourcentages sont arrondis, d'où un total de 99. En gros, un tiers invisible, un tiers discret, un tiers franchement cassé. Le pire cas, c'étaient les 508 pixels ci-dessus.

Mon premier comptage donnait 23 %, pas 31. J'avais calculé le chevauchement à partir d'un champ absent sur certains clips plus anciens, et ces lignes avaient été ignorées sans le moindre avertissement. Le chiffre paraissait plausible, alors j'ai failli le garder.

Le correctif, et les tests qu'il a passés

Le nouveau plafond, c'est la règle en une ligne : chaque panneau fait au plus la moitié de l'image, et les deux fenêtres sont placées de façon à ne jamais pouvoir se croiser. Il ne s'applique que si le placement d'origine se chevauche réellement. Une version précédente recalculait la géométrie dans tous les cas et décalait d'un ou deux pixels une poignée de clips qui allaient très bien. Un correctif qui touche des clips sains, c'est un deuxième bug.

Ensuite, les vérifications. J'ai rejoué un lot de clips enregistrés avec le correctif désactivé puis activé : tout ce qui ne se chevauchait pas ressortait identique, et les seuls clips modifiés étaient exactement ceux qui se chevauchaient. Puis un nouveau job sur une vraie vidéo : 12 clips en écran partagé, le plafond appliqué sur 3, aucun chevauchement.

Je l'ai déployé, et je l'ai noté comme corrigé dans le changelog.

Le soir même

Une vidéo de test de plus. Un clip est sorti avec un chevauchement de 44 pixels, correctif activé.

Il y avait deux fonctions. L'une gère le cas classique, deux personnes face à face à une table, et donne un gros plan à chacune. L'autre est le repli général, utilisé quand la première renonce : elle prend les visages le plus à gauche et le plus à droite dans chaque image et découpe à partir d'eux. Les deux produisent un clip en écran partagé avec leur propre paire de positions de fenêtres. Les deux avaient le même défaut, presque mot pour mot. J'avais corrigé la première et je n'avais jamais ouvert la seconde.

Le plus agaçant, c'est à quel point les preuves avaient l'air convaincantes. Ma mesure et mon lot de test mélangeaient les deux chemins de code, et je n'en avais aucune idée. Le premier correctif avait assez nettoyé l'échantillon pour que le résultat ait l'air complet. Une mesure faite sur des résultats enregistrés compte des symptômes. Elle ne dit pas combien d'endroits les produisent.

Le second correctif, c'est la même règle dans la seconde fonction. Rejoué sur le même lot : quatre clips de plus corrigés, des chevauchements de 56, 124, 230 et 340 pixels tous ramenés à zéro, rien d'autre n'a bougé. Celui de 56 pixels était passé intact à travers le correctif du matin. C'est la fuite, prise sur le fait.

Chercher s'il y en a un troisième

Avant d'écrire « corrigé » une deuxième fois, j'ai cherché dans le code tout ce qui fixe une position de fenêtre. Quatre endroits, pas un seul. Deux sont les fonctions ci-dessus, désormais corrigées toutes les deux. Le troisième construit les panneaux à partir d'une ligne de séparation qu'il a déjà trouvée et limite chaque panneau à l'espace de son côté de cette ligne, donc ses deux fenêtres ne peuvent pas se croiser par construction. Le quatrième ne fait que transmettre les valeurs du troisième.

Cette fois, l'affirmation est donc plus étroite : aucun écran partagé rendu depuis le 10 octobre ne met la même partie de l'image dans les deux panneaux. Les clips rendus avant gardent la géométrie avec laquelle ils ont été produits.

Ce qui ne va toujours pas

Ne plus dupliquer l'image, c'est un plancher, pas un bon écran partagé. Trois choses que je vois aujourd'hui sur de vraies vidéos :

Les panneaux sont trop larges pour les personnes qu'ils contiennent. Chaque panneau est dimensionné à partir de l'image, pas de la personne. Sur un plan large de studio, quelqu'un peut occuper un tiers de son panneau, le reste étant laissé au décor derrière lui. Deux panneaux à moitié vides peuvent rendre moins bien qu'un seul plan bien cadré, et c'est la raison pour laquelle je n'ai pas encore ouvert l'écran partagé à d'autres types de plans. Resserrer chaque panneau autour de sa personne, c'est le prochain chantier.

Un court échange au milieu d'un clip plus long n'est pas mis en écran partagé. La décision est prise pour le clip entier. Si une personne parle pendant quarante secondes et que la seconde intervient pendant cinq, le clip reste sur un seul cadrage et la réponse se passe hors champ.

Certains plans à deux personnes ne sont jamais reconnus comme tels. Le déclencheur compte les visages. De profil, de loin ou avec une mauvaise lumière, le détecteur de visages peut rater une personne que le détecteur de corps voit sur chaque image, et le clip se rabat sur un seul cadrage.

Aucun de ces défauts ne duplique quoi que ce soit. Ils font la différence entre un écran partagé qui n'est pas cassé et un écran partagé vraiment bon, et je préfère le dire plutôt que de laisser « corrigé » valoir pour les deux.

Ce que j'en retiens

Quand un correctif marche, cherchez les autres endroits qui produisent le même résultat. Pas seulement l'endroit où vous avez trouvé le bug : tous ceux qui peuvent émettre le même genre de résultat. Ici, c'était une seule recherche sur un seul nom de champ, et je l'ai lancée après le déploiement au lieu d'avant.

Un chiffre agrégé ne peut pas vous dire qu'un correctif est complet. Il a beaucoup baissé, et c'est justement une forte baisse qui donne envie d'arrêter de chercher.

Une métrique qui saute des lignes en silence est pire qu'une métrique qui plante. Un champ manquant a transformé 31 % en 23 sans le moindre avertissement.

Partez de la contrainte, pas d'un indicateur de substitution. Le plafond était calculé à partir de la distance entre deux personnes parce que ce chiffre était sous la main. La vraie limite, c'était la largeur de l'image, qui était elle aussi sous la main.

L'entrée du changelog (en anglais) disait « corrigé » le 10 octobre, quelques heures trop tôt. Elle raconte maintenant ce qui s'est passé.

Articles liés

Prêt à transformer vos vidéos en clips viraux ?

Katto découpe, sous-titre et recadre automatiquement vos vidéos longues en contenu court.

Essayer Katto gratuitement →
Mon correctif d'écran partagé a passé tous les tests. Il ne corrigeait que la moitié du bug. | Katto