QA vidéo — la passerelle de sortie
Une vidéo n'est pas terminée quand elle est rendue ; elle est terminée quand elle a été inspectée, VUE sur une planche contact, et normalisée. Cette compétence fonctionne sur n'importe quel fichier, indépendamment de la façon dont il a été créé.
1. Relever les faits (ne jamais faire confiance aux suppositions)
scripts/probe.sh video.mp4
Comparer chaque valeur avec ce qui a été commandé (timeline, brief, spécifications de la plateforme) :
| Vérification | Attendue |
|---|---|
| durée | durée commandée ± 0.1s |
| fps / résolution | fps commandé / L×H |
| codec / pix_fmt | h264 / yuv420p (yuvj420p = variante pleine gamme, généralement acceptable) |
| flux audio | présent ssi la vidéo doit avoir du son |
| loudness intégrée | −14 ± 2 LUFS (les plateformes sociales normalisent près de −14) |
Tout écart est un bogue dans le rendu, pas une question de goût. Corriger en amont, re-rendre.
2. Loudness : mesurer → normaliser (audio uniquement, secondes)
# mesurer
ffmpeg -hide_banner -i video.mp4 -af ebur128 -f null - 2>&1 | awk '/Integrated loudness/{getline; print}'
# normaliser à −14 LUFS (flux vidéo copié, pas de ré-encodage)
ffmpeg -i video.mp4 -c:v copy -af "loudnorm=I=-14:TP=-1.5:LRA=11" -c:a aac -b:a 192k video_norm.mp4 \
&& mv video_norm.mp4 video.mp4
Ne jamais normaliser à l'oreille avec un filtre de volume — le LUFS est l'unité que les plateformes utilisent réellement.
3. Regarder : planche contact + bandes d'images
scripts/contact_sheet.sh video.mp4 contact.png 2 8x # 1 vignette / 0.5s, 8 colonnes
# 12 images consécutives autour d'un moment délicat (transition à T) :
ffmpeg -y -ss <T-0.2> -i video.mp4 -frames:v 12 -vf "scale=320:-1,tile=6x2" strip_T.png
Lire la planche comme un film : le rythme est-il visible ? les coupes tombent-elles sur la grille des temps ? y a-t-il une scène vide ou surchargée ? Les planches cachent la qualité du mouvement — toujours REGARDER la vidéo complète au moins une fois avant de valider.
4. Passage critique (le constructeur n'est pas le juge)
Examiner le RENDU — pas la source, pas les intentions — en notant chaque /10 :
- Accroche — l’image la plus forte dans les 2 premières secondes ?
- Lisibilité — texte ≥ taille minimale, dans les zones de sécurité, pas de chevauchement/coupure, tenu assez longtemps ?
- Motion — pas d’easing linéaire, entrées multi-propriétés, décalage, sorties plus rapides que les entrées ?
- Synchronisation — les événements tombent-ils sur la grille des temps/mots ?
- Cohérence stylistique — une famille de palettes, un système typographique, des transitions unifiées ?
- Son — VO claire, musique baissée, loudness cible, pas d’écrêtage ?
Protocole : noter les 3 pires défauts AVEC horodatages → corriger exactement ceux-ci → re-rendre → re-noter. 3 à 5 passes pour atteindre ≥8/10 partout est normal. Exécuter le critique dans un contexte frais (ou sous-agent) : l'auteur du code est le pire relecteur du code.
5. Déterminisme (pour les vidéos générées / reproductibles)
# deux empreintes de la même entrée doivent correspondre octet pour octet
ffmpeg -i video.mp4 -map 0:v -f framemd5 - | sha1sum
Même pipeline, même entrée → un hash différent signifie une dépendance au temps réel cachée, un aléatoire non ensemencé ou un état accumulé : corriger le générateur, ne pas « relancer ».
6. Liste de livraison
video.mp4 H.264, yuv420p, +faststart, −14 LUFS
poster.png/jpg l’image d’accroche
contact.png le filmstrip à 2 ips
sources tout ce qui génère la vidéo (éditable > final)
Indiquer précisément à l'utilisateur quel fichier éditer pour changer un élément, et la commande de re-rendu.
Règle de preuve
Lorsqu’un relecteur (humain ou modèle de vision) déclare un défaut géométrique (« texte coupé », « éléments qui se chevauchent »), confirmer avec une mesure (inspection dans le lecteur, échantillon de pixel ou les propres métriques du code générateur) avant de « corriger » un non-bogue. Les relecteurs hallucinent bien plus souvent des marges que les rendus ne coupent du texte.