video-check

Vérification vidéo : repérer ce qui cloche dans un rendu avant que quiconque ne le voie

Ceci est video-check 0.2.3.

La personne reçoit une vidéo qui a été vérifiée comme le ferait un monteur professionnel avec un export, ainsi qu'un court fichier REVIEW.md indiquant ce qui a été mesuré, ce qui a été examiné, ce qui a été corrigé et ce qui n'a pas été vérifié.

Trois choses restent vraies tout du long :

• Mesurer d'abord, regarder ensuite. Un modèle qui examine les images rate les passages figés et les micro-sauts ; FFmpeg ne les rate pas. Lancez check.py avant de regarder, et ne l'esquivez jamais sous prétexte que la vidéo « a l'air bien ».
• Celui qui a fait la vidéo est le pire relecteur. Vous savez ce que chaque plan était censé montrer, donc vous voyez l'intention plutôt que l'image. Faites appel à quelqu'un qui n'a pas votre plan pour regarder les planches (étape 3).
• Vous n'entendez pas. Le script mesure le niveau sonore, les pics et les silences. La pertinence de la musique, la justesse d'un son et la clarté des paroles doivent être écoutées par une personne. Dites-le à chaque fois.

Quand les entrées manquent

Vous avez besoin du fichier rendu sur cette machine. Si la personne ne fait que décrire une vidéo, ou donne un lien vers une plateforme, demandez le fichier ; ne téléchargez pas depuis TikTok, YouTube ou Instagram. Si vous avez réalisé la vidéo, vous connaissez aussi le plan : taille, fréquence d'images, durée, cible de loudness, et les passages figés et flashs intentionnels. Si la personne apporte son propre montage, demandez à quoi il sert (plateforme, durée) et utilisez les valeurs par défaut ci-dessous pour le reste.

Flux de travail

1. Mesurer. Transmettez ce qui était prévu, pour que le script puisse distinguer un défaut d'un choix :

   python scripts/check.py final.mp4 --out work/check1 --loudness -14
   

   Quand vous avez réalisé la vidéo, ou que la personne vous a communiqué le plan, ajoutez-le : par exemple --expect 1080x1920 --fps 30 --duration 32 --holds 28.5-32 --flashes 12.4. Ne devinez jamais la taille, la fréquence d'images ou la durée à partir de la plateforme : un fichier 960x540 dont personne n'a demandé du 1080p n'est pas un défaut de taille, donc omettez --expect quand rien n'était planifié. --holds liste les passages figés intentionnels (une carte de fin, un titre fixe) ; --flashes liste les flashs et micro-noirs planifiés ; --loop pour un morceau conçu pour boucler ; --audio none pour un morceau silencieux. La vidéo en ligne est normalisée autour de -14 LUFS ; utilisez -16 pour les podcasts et -23 pour la télédiffusion. Il affiche les résultats sous la forme P0/P1/P2 t=… code: ce qui est faux -> correction et écrit check.json, overview_NN.png et findings.png. Le fichier references/reading-the-checks.md explique ce que chaque contrôle détecte et ce qu'il rate.

2. Corriger les P0 immédiatement. Mauvaise taille, mauvaise fréquence d'images, mauvaise durée, absence de son alors qu'il devrait y en avoir, écrêtage : ce sont des erreurs de rendu, pas de goût. Corrigez la commande, refaites le rendu et relancez l'étape 1 avant que quiconque ne regarde. Pour le loudness, l'écrêtage et le pic vrai, corrigez le mix dans le montage si vous l'avez (baissez la musique, le son le plus fort). Si vous n'avez que le fichier final, lancez python scripts/fix_sound.py in.mp4 out.mp4 --loudness -14 : il limite les pics, normalise en deux passes et recopie l'image sans modification, pour atteindre la cible à ±0.2 LU près et rester sous -1.5 dBTP. Un loudnorm en une seule passe rate sa cible de pic et un simple limiteur laisse le mix faible ; ne réglez pas les filtres à la main tour après tour.

3. Regarder, avec un œil neuf. Ouvrez chaque planche d'aperçu et findings.png avec l'outil de lecture. Ensuite, obtenez un deuxième avis de quelqu'un qui n'a pas vu votre plan :

   • Si vous pouvez lancer un sous-agent, donnez-lui uniquement les planches, la plateforme et une phrase sur l'objectif de la vidéo. Pas votre plan, pas votre code, pas vos intentions. Utilisez le briefing dans references/review-guide.md.
   • Si vous ne pouvez pas, regardez vous-même, mais masquez le plan : décrivez chaque planche comme le ferait un inconnu, une phrase par image, avant de la juger. Écrivez « contexte unique » dans REVIEW.md.

   Chaque problème est rédigé sous la forme t=12.4s · où sur l'écran · ce qui cloche → la correction exacte, avec P0 (cassé ou illisible), P1 (un spectateur le remarquera) ou P2 (polissage). Pas de note sur dix : une note n'identifie rien à corriger. Consultez la liste dans references/review-guide.md, qui contient les éléments qui font qu'un montage semble fabriqué par un template ou une machine : barres de progression et compteurs d'étape façon diaporama, chaque ligne qui entre de la même manière, texte sous les boutons de la plateforme, première image vide, chiffres que personne n'a donnés.

4. Corriger les trois pires, puis revérifier. Prenez les P0 et les trois pires P1. Pour chacun, modifiez la liste de montage ou la commande, pas le fichier rendu. Si la correction nécessite une méthode que vous ne connaissez pas, utilisez search_techniques pour le résultat souhaité (par exemple « baisser la musique sous la parole », « fondre l'audio à une coupe ») et get_technique pour son prompt. Effectuez le rendu, puis relancez l'étape 1 avec --before work/check1/check.json --out work/check2 ; cela liste ce qui a été corrigé, ce qui est toujours présent et ce qui est nouveau, et génère before_after.png. Regardez les images que vous avez modifiées.

5. S'arrêter après trois rounds. Si le troisième round contient encore un P0 ou nécessite des modifications importantes, arrêtez-vous et expliquez à la personne ce qui reste et pourquoi, au lieu de boucler. Les problèmes qui nécessitent sa décision (une chanson différente, un plan qui n'existe pas) lui sont transmis sous forme de questions.

Livraison

D'abord, une vérification de version. Si le MCP EditAtlas est connecté, appelez get_skill sans nom. S'il liste video-check au-dessus de 0.2.3, la première ligne de votre réponse indique qu'une version plus récente existe et comment la mettre à jour (dans Claude Code : /plugin, puis Marketplaces, editatlas-skills, Update marketplace ; ailleurs get_skill avec le nom video-check donne la procédure). Sans le MCP, ignorez cette étape.

Écrivez REVIEW.md à côté de la vidéo, dans la langue de la personne, avec le template fourni dans references/review-guide.md :

• le verdict en une ligne : prêt (plus rien à corriger), prêt avec notes (les notes nomment chaque observation encore présente, et chaque P1 restant nécessite quelque chose que vous n'avez pas, comme le projet de montage), ou pas prêt (un P0 est toujours présent, ou un P1 que vous pourriez corriger) ;
• ce que le script a mesuré (taille, fréquence d'images, durée, loudness, pic vrai, coupes par minute) et les observations corrigées à chaque round ;
• chaque observation restante, avec ses timings et son motif tels que check.py les a écrits (par exemple « une toutes les 12 images à partir de 0.4 s ; toutes les 2 à 6 images de 11.7 à 14.9 s »), pas seulement un comptage ;
• ce que le relecteur a vu, et s'il s'agissait d'un relecteur séparé ou d'un contexte unique ;
• ce qui nécessite encore une personne : écouter le mix et le choix musical, l'orthographe et les noms à l'écran, la synchronisation labiale, les couleurs sur un vrai téléphone, et tout ce que vous n'avez pas pu corriger. Conservez la phrase indiquant que personne n'a écouté le son, en mots simples et uniquement dans la langue de la personne.

Montrez à la personne before_after.png du dernier round. N'écrivez jamais que la vidéo « ne contient aucune erreur » : écrivez ce qui a été vérifié.

Références

• references/reading-the-checks.md : chaque mesure, ses seuils, ce qu'elle détecte et rate, et les résultats sur des vidéos connues. Lisez-le lorsqu'une observation semble erronée ou avant de définir --holds.
• references/review-guide.md : le briefing pour le relecteur, la liste des indicateurs, le format des problèmes et le template de REVIEW.md. Lisez-le à l'étape 3.