Comment il décide

Le résultat, d'abord

Sur le jeu de validation — 7 références, 44 coupes, aucune n'ayant servi à régler un seuil

Appariement un-à-un — une détection ne peut valider qu'une seule coupe — avec une tolérance de ±100 ms. Le dénominateur du rappel est le nombre de coupes réellement présentes : 37 trouvées sur 44.

Ce n'est pas le meilleur chiffre que ce banc puisse produire, et c'est volontaire. Sur les 4 références de réglage, le rappel est de 100 % — il l'est par construction, puisque les seuils ont été développés dessus. En additionnant les deux jeux on obtient 91 %, et c'est ce nombre que cette page affichait. Le citer revenait à citer un examen qu'on avait rédigé soi-même.

Zéro faux positif est le chiffre qui compte le plus. Un montage qui coupe là où il n'y a rien à couper est irrécupérable ; un montage qui rate une coupe reste regardable.

Ce qu'il ne sait pas faire

Deux plans quasi identiques ne sont pas séparés. Sur la référence near-identical, le détecteur trouve 0 coupe sur 6. La méthode compare la luminance d'une grille entre deux instants : si deux plans successifs se ressemblent au point de ne produire aucun écart mesurable, il n'y a rien à détecter. Ce n'est pas un réglage à corriger, c'est la limite de la mesure choisie.

Elle est déclarée dans le banc, elle fait partie du score agrégé, et elle n'est pas exclue pour embellir le résultat. C'est la seule raison de croire les dix autres lignes.

Trois questions, trois méthodes

Où sont les coupes ? Le fichier est parcouru avec un positionnement sûr, une grille de luminance grossière est échantillonnée à chaque arrêt, et une distance image-à-image élevée vaut coupe. La grille plutôt que les pixels bruts : c'est ce qui empêche un mouvement de caméra ou du bruit de compression de passer pour un changement de plan. Le seuil est adaptatif — médiane et écart absolu médian sur une fenêtre glissante — parce qu'un seuil fixe se trompe dès que l'exposition change.

Quand couper ? La piste est filtrée en passe-bas à 150 Hz pour isoler l'énergie des kicks, une enveloppe d'amplitude est construite, sa dérivée est redressée pour obtenir une fonction d'attaque, les pics sont retenus contre un seuil adaptatif, puis une grille régulière est ajustée sur ces attaques. C'est la grille qui compte, pas les attaques brutes : un kick manqué laisserait sinon un trou dans le montage.

Où le morceau change-t-il de nature ? Le filtre à 150 Hz est le bon outil pour trouver une pulsation et le mauvais pour trouver une montée : tout ce qui fait qu'un refrain paraît plus grand qu'un couplet — les charleys, les nappes, la voix — vit au-dessus de cette coupure et se trouve jeté avant même que l'enveloppe soit construite. Une seconde passe découpe donc le signal en trois bandes et cherche les instants où l'équilibre entre elles se déplace. Une frontière de section n'est pas un moment fort ; c'est un moment où le timbre bouge. C'est cette distinction qui sépare un refrain qui démarre d'une mesure simplement plus forte à l'intérieur d'un couplet.

Ce que l'algorithme n'a pas le droit de faire

Quand vous montez à la main et demandez à CutPilot d'appliquer un rythme, le contrat est délibérément étroit, et tout le code en dépend :

• l'ordre de vos plans n'est jamais modifié ;
• un plan n'est jamais remplacé par un autre rush ;
• le point d'entrée que vous avez choisi n'est jamais déplacé ;
• seule la durée — où tombe la coupe suivante — est réécrite.

Vous décidez ce qui est à l'écran. L'outil décide combien de temps ça y reste. Plus large que ça, l'algorithme passerait au-dessus de vous.

Pourquoi c'est rapide

Analyser un rush, c'est en extraire quelques centaines d'images. La façon évidente est de demander chaque instant au lecteur vidéo. La façon évidente est aussi la mauvaise : chaque recherche fait sauter le décodeur sur une image-clé puis redérouler jusqu'à la cible, travail jeté aussitôt et refait pour l'échantillon suivant. 15,95 ms par image, et 95 % du budget.

Nous ouvrons donc le fichier nous-mêmes et donnons ses images encodées au décodeur dans l'ordre. Il décode alors chaque image une seule fois : 1,55 ms. Il faut pour cela lire le conteneur — la table d'échantillons d'un MP4 de téléphone, ou les fragments qu'écrit un navigateur — et c'est ce que fait notre démultiplexeur.

Sur huit vidéos réelles, prises telles quelles :

L'écart dépend de l'espacement des images-clés : plus il est grand, plus une recherche doit remonter loin pour se positionner, tandis que le décodage séquentiel ne paie rien de plus. Les fixtures de test, elles, n'ont que des images-clés — c'est le cas le plus favorable à l'ancienne méthode, et il ne donne que ×2,8.

Deux faux positifs ont disparu au passage, et ce n'était pas le but. Le métrage de test est continu, sans aucune coupe ; l'ancien chemin en détectait une à 20 s comme à 40 s. Une recherche ne rend pas toujours l'image demandée, et l'écart entre deux images voisines finissait par ressembler à une coupure. Le décodage séquentiel rend l'image du fichier.

Sept de ces huit vidéos donnent exactement les mêmes coupes par les deux méthodes. La huitième en trouve une de moins par décodage. Sans montage de référence sur une vidéo réelle, rien ne dit laquelle a raison — mais sur les onze références annotées, où la réponse est connue, le décodage donne les mêmes chiffres et supprime deux fausses détections.

Quand ce chemin ne s'applique pas — un conteneur inhabituel, un codec dont nous ne validons pas la configuration — il renonce et la méthode précédente reprend la main, à l'identique. Il peut ajouter de la vitesse, jamais retirer un format.

Où tourne le calcul

Le décodage, l'analyse et le rendu se font dans votre navigateur. Vos fichiers ne sont pas téléversés. Ce qui remonte à nos serveurs, c'est la mesure de chaque plan — durée, score, mouvement, netteté, exposition, cadrage — jamais l'image.

Deux exceptions, explicites : le mode agentique, qui téléverse pour pouvoir publier quand votre machine est éteinte, et la sélection sémantique, désactivée par défaut, qui envoie une vignette par plan à un modèle. Les deux sont décrits nommément dans la politique de confidentialité, qui liste chaque prestataire.

Le banc de mesure

Le banc se rejoue par npm run test:references. Il échoue si un seuil dérive, et il échoue aussi si la séparation réglage/validation est rompue — une référence sans rôle, ou présente dans les deux jeux, arrête l'exécution avant qu'un chiffre soit publié.

Le protocole, en clair

• Manifeste v1, 11 références encodées image par image : un instant de coupe est exact par construction.
• Tolérance d'appariement ±100 ms — le détecteur échantillonne 12 fois par seconde, soit environ 83 ms de résolution réelle.
• Appariement un-à-un, gloutonne, les paires les plus proches d'abord.
• Exécution : Chromium via playwright-core, sur les fixtures .webm committées. Ces chiffres ne sont donc pas produits par les tests unitaires, qui tournent sans navigateur.
• Dernière mesure : 2026-09-01. Chaque nombre de cette page est lu dans le fichier écrit par cette exécution — aucun n'est recopié à la main.

Ce qui est mesuré sur chaque plan

Netteté par variance du laplacien, mouvement par différence de grilles dans l'ordre chronologique — l'ordre compte, une version antérieure les comparait dans l'ordre d'échantillonnage et mesurait donc le mouvement à l'envers —, colorimétrie selon Hasler-Süsstrunk, exposition, poids du centre du cadre, et présence d'un visage lorsque le navigateur sait la détecter. Quand il ne le sait pas, le score n'est pas inventé : il vaut null, et le plan est classé sans lui.