ismum123/kinetic-promo-video

Vidéo Promotionnelle Cinétique

Créez une vidéo promotionnelle verticale d'aspect broadcast à partir d'une simple description de l'activité. La vidéo est écrite comme une page HTML unique pilotée par une horloge maîtresse suspendue, puis rendue image par image et encodée. Pas d'éditeur, pas d'image de stock, pas d'application de montage – et chaque image est reproductible à partir d'un horodatage.

Entrées

• $brief — ce qu'est la chose, à qui elle s'adresse, ce qui la rend différente. Obligatoire. Extrayez-le de la conversation, du README du dépôt, ou demandez.
• $reference — facultatif. Une URL vidéo ou un fichier local dont l'apparence doit être reproduite.
• $brand — facultatif. Nom, slogan, URL, couleurs, logo. S'il est absent, utilisez un espace réservé clairement indiqué (n'inventez jamais un nom de marque en silence et ne le présentez pas comme final).
• $duration — facultatif. Par défaut 30–35 s silencieuse, 45–60 s narrée (la voix fixe la durée – voir references/audio.md). Restez sous 60 s pour Shorts/Reels/TikTok.
• $audio — par défaut : narrée, pas de musique. Écrivez une voix off et construisez la ligne de temps autour d'elle, sauf si l'utilisateur demande une pièce silencieuse. La musique est la seule chose qui reste désactivée sauf demande explicite.

Objectif

promo.mp4 — 1080×1920, 30 ips, H.264, lisible et correcte dès la première lecture – plus le scene.html qui l'a générée, un render.py qui la reproduit, un fichier de sous-titres voice.srt pour les pièces narrées, et un README avec la feuille de rythme et les constantes pour la rebrander. Le succès n'est pas "un fichier existe" : ce sont des images que vous avez regardées qui se lisent proprement, sans texte qui se chevauche, sans éléments visibles avant leur signal, et sans temps mort.

Étapes

1. Vérifier la chaîne d'outils

which ffmpeg ffprobe yt-dlp python3
python3 -m venv .venv && .venv/bin/pip install -q playwright && .venv/bin/playwright install chromium

ffmpeg et un Chromium pour Playwright sont des prérequis stricts. yt-dlp n'est nécessaire que pour l'analyse des vidéos de référence. Préférez un environnement virtuel – le Python système de l'utilisateur peut être géré de manière externe.

Critères de succès : ffmpeg -version fonctionne et .venv/bin/python -c "from playwright.sync_api import sync_playwright; sync_playwright().start().chromium.executable_path" affiche un chemin.

2. Établir la cible visuelle

Deux chemins – choisissez selon que $reference existe ou non.

2a. Référence donnée → l'analyser

Lisez references/teardown.md et suivez-le. En résumé : téléchargez-la, sondez-la, extrayez des planches contact à 1 ips, lisez réellement les images des planches, et notez les dimensions, la durée, la palette, le traitement typographique, la structure des séquences et le vocabulaire de mouvement avant d'écrire du code.

Ne décrivez jamais une référence que vous n'avez pas examinée image par image. Le titre ou la description d'une page ne vous dit rien sur son design de mouvement.

2b. Pas de référence → dérivez d'abord le langage propre du sujet

N'ouvrez pas default-style.md tout de suite. Prenez deux minutes pour répondre à quatre questions sur le sujet réel :

1. Quels sont les objets ? Livres, pots, factures, visages, un tableau de bord. Ce sont eux qui doivent bouger.
2. Dans quelle lumière vivent-ils ? Lampe de lecture, salle d'exposition, clair de lune, lueur d'écran, lumière du jour à travers une fenêtre.
3. Comment bougent-ils physiquement ? Les choses avec masse s'installent. Le papier se tourne et se plisse. Les liquides s'étalent. Les données claquent.
4. Quelle est la colonne vertébrale ? L'élément récurrent qui porte l'argument – un compte à rebours, une horloge traversant une nuit, un reçu qui s'allonge, un itinéraire qui se remplit. Idéalement, il est la revendication, pas une décoration.

Si ces quatre réponses donnent un aspect cohérent, construisez-le. Une promotion de soins de la peau sur la réparation nocturne obtient une palette de nuit, une police serif, un mouvement de mise en place lent et un cadran allant de 22h à 7h – pas des anneaux lumineux.

Revenez au style par défaut lorsque le sujet ne suggère vraiment rien de spécifique (la plupart des logiciels B2B, services abstraits). Lisez alors references/default-style.md et utilisez-le tel quel : c'est un cahier des charges complet et validé (bleu marine foncé + lueur bleue, sans empattement géométrique, typographie cinétique avec flou d'entrée, horizon lumineux, outro en anneau). Dites à l'utilisateur en une ligne quel style vous utilisez et qu'il peut le changer en nommant une vidéo de référence – puis continuez. N'attendez pas d'approbation.

Vérification d'honnêteté avant de construire. Si vos temps de séquence tombent à ~0,5 s près de ceux du modèle et que les plans signatures survivent – la pile de mots répétés, l'éclosion de l'anneau, la carte horizon-plus-dalle, le flou d'entrée comme seul mouvement de texte – vous avez rethématisé le modèle plutôt que conçu pour le sujet. C'est acceptable lorsque vous avez délibérément choisi le repli, et un défaut dans le cas contraire.

Critères de succès : un petit cahier des charges écrit – taille du canevas, ips, durée, hexadécimaux de la palette, police et mouvements que vous utiliserez – auquel vous pouvez vous référer pendant la construction. Si vous avez dérivé un langage natif du sujet, il nomme également la colonne vertébrale et les mouvements que vous avez délibérément évités.

3. Écrire la feuille de rythme

Lisez references/audio.md et écrivez la piste vocale en premier – elle est activée par défaut. La voix possède la ligne de temps : générez les lignes, mesurez-les et déduisez les temps des séquences à partir des mesures plutôt que d'adapter la parole à des nombres ronds. Conservez les temps mesurés par ligne – ils deviendront voice.srt à la livraison. Ne sautez cette étape que lorsque l'utilisateur a demandé une pièce silencieuse.

Lisez references/beats.md pour la structure et les règles de copie, puis mappez les véritables différenciateurs de l'utilisateur sur les séquences. Le tiers médian est celui où le produit est vendu : il doit contenir les raisons spécifiques pour lesquelles cette chose est meilleure, pas des adjectifs. Supposez une lecture sans son – la plupart des spectateurs de Shorts/Reels n'entendent jamais la voix – donc chaque affirmation de la voix off doit aussi apparaître sous forme de texte à l'écran, pas seulement comme narration.

Écrivez la feuille de rythme sous forme de tableau (plage t → séquence) avant d'écrire du code. Corriger le rythme après la construction des scènes est bien plus coûteux.

Artéfacts : tableau des séquences avec des plages de secondes explicites totalisant $duration.

Critères de succès : chaque séquence fait référence à quelque chose de réel sur le produit, et les plages sont contiguës sans écart > 0,3 s.

4. Générer l'échafaudage à partir des modèles

$SKILL ci-dessous est le répertoire de cette compétence elle-même – celui qui contient ce SKILL.md. Résolvez-le à partir de votre liste de compétences plutôt que de deviner un chemin ; il est souvent monté en lecture seule, ce qui est acceptable car tout est copié ailleurs.

mkdir -p video && cp "$SKILL/templates/render.py" video/
cp "$SKILL/templates/scene-starter.html" video/scene.html
bash "$SKILL/templates/fetch-fonts.sh" video/fonts     # Sous-ensembles Poppins, ~40 Ko

scene-starter.html contient déjà le cadre d'animation (seek, win, io, pop, swap, draw, RNG ensemencé, atmosphère) et sept exemples de séquences couvrant tous les modèles qui valent la peine d'être copiés. Ne réécrivez pas le cadre – il intègre les bugs listés dans les Règles. Remplacez les séquences d'exemple ; conservez tout ce qui se trouve au-dessus d'elles.

Critères de succès : python render.py --contact produit contact.png à partir du modèle non modifié.

5. Construire les scènes

Une IIFE par séquence, créant chacune son propre layer() conditionné par win(layer, tIn, tOut). À l'intérieur, chaque élément animé reçoit exactement un appel à io() / pop() / swap().

Construisez les maquettes d'interface utilisateur (tableaux de bord, téléphones, ordinateurs portables, cartes, puces) en DOM + CSS pur et animez-les – elles apportent le côté "produit réel" que la pure typographie ne peut pas fournir. Les graphiques sont des divs et du SVG en ligne ; pas de bibliothèque de graphiques, pas d'images, pas de requêtes externes.

Un cut sec est un mouvement légitime : deux couches win() partageant une limite de temps exacte, entrées avec steps(1,end), donnent un cut délibéré d'une seule image – l'outil approprié pour un changement tonal comme monde de l'histoire → couleur de fond de marque plate. Tout le reste s'adoucit ; le cut fonctionne parce qu'il est le seul.

Les logos multicolores réels sont souvent illisibles à la fois sur des scènes sombres et sur des fonds de marque plats – placez l'actif sur un petit plateau blanc plutôt que de le recolorer.

Règles : voir la section Règles. Ce ne sont pas des préférences de style – chacune est un échec spécifique que cette compétence a déjà rencontré.

Critères de succès : python render.py --contact se rend sans erreur.

6. Boucle de prévisualisation – regarder chaque image

python render.py --contact          # Aperçu de 24 images, ~20 s
python render.py --at 6.2 12.0 19.5 # moments spécifiques, pleine résolution

Lisez les PNG résultants avec votre outil de lecture d'images – quel que soit le nom que le cadre lui donne – et inspectez-les. Ensuite corrigez et répétez. Itérez ici jusqu'à ce que la planche soit propre – un rendu complet est 10× plus lent, ne l'utilisez donc jamais comme boucle de rétroaction.

Les deux vues répondent à des questions différentes. La planche contact est pour la structure : timing, chevauchements, images mortes, ordre des séquences. Elle fait 270×480 par image et sous-estime systématiquement les travaux sombres ou à faible contraste – une pièce qui semble boueuse et cassée sur la planche est souvent propre en taille réelle. Jugez le contraste, la palette et la lisibilité uniquement à partir des images --at, et tirez-en au moins une par séquence chaque fois que la palette est sombre, plus une par pictogramme ou illustration – la reconnaissabilité ne peut pas être jugée à la taille d'une tuile (voir Règle 12). N'augmentez pas la luminosité pour corriger quelque chose que la planche a exagéré.

Ce qu'il faut rechercher à chaque passage :

• deux textes lisibles en même temps en pleine transition
• quoi que ce soit visible avant son signal (le bug classique fill: 'both' – voir Règles)
• des éléments d'arrière-plan qui se lisent comme des formes reconnaissables au lieu d'une atmosphère
• des blobs translucides empilés – les couches alpha qui se chevauchent se composent en arcs d'intersection visibles et se lisent comme des disques ; utilisez un élément avec un bord qui se dissout à l'intérieur de sa propre boîte, dimensionné plus grand que l'image
• des images mortes – tout moment sans rien à l'écran
• du texte ou des maquettes serrés contre les bords de l'image, ou trop petits pour un écran de téléphone

Point de contrôle humain : aucun requis, mais si l'utilisateur est présent, montrez-lui la planche contact avant le rendu complet – les notes sur le rythme et la copie sont les moins chères maintenant.

Critères de succès : vous avez visionné une planche contact dans laquelle chaque image se lit proprement et aucun défaut ci-dessus n'est présent.

7. Rendre et vérifier

Testez d'abord l'encodeur avec un test de fumée. Rendez une tranche d'environ 2 s – via un indicateur de plage si votre copie de render.py en a un, sinon en réduisant temporairement les constantes de durée – et sondez le résultat avec ffprobe. Les problèmes d'encodeur et de muxage apparaissent en secondes ici au lieu d'après un rendu complet de plusieurs minutes.

python render.py                    # -> promo.mp4, ~1 capture d'écran par image
# pièces narrées : muxage uniquement après la SORTIE du processus d'encodage
ffmpeg -y -i promo.mp4 -i vo/voice.wav -c:v copy -c:a aac -b:a 192k promo_av.mp4
ffprobe -v error -show_entries format=duration \
        -show_entries stream=codec_type,codec_name,width,height,nb_frames \
        -of default=noprint_wrappers=1 promo_av.mp4
ffmpeg -y -v error -i promo_av.mp4 -vf "fps=1/1.2,scale=180:320,tile=10x3" -frames:v 1 verify.png

Lancez le rendu complet en arrière-plan. C'est environ 1 capture d'écran par image – une vidéo de 50 s fait environ 1500 images et dépasse confortablement un délai de commande de 600 s. Vérifiez que le processus de rendu s'est terminé, pas que le mp4 est apparu : le fichier existe sur le disque bien avant d'être terminé, et un muxage précoce donne "moov atom not found".

Pour les pièces narrées, écrivez voice.srt à partir des temps par ligne mesurés à l'étape 3 – les nombres existent déjà ; c'est un passage de formatage, pas un nouveau travail.

Lisez verify.png – vérifier la sortie encodée, pas le navigateur, est le but. Ensuite supprimez les planches de travail et le répertoire d'images.

Critères de succès : ffprobe signale la durée attendue, les dimensions attendues (1080×1920 sauf si l'utilisateur a changé le format), et nb_frames == fps × durée ; pour les pièces narrées, un flux audio est présent, la durée correspond au fond sonore vocal, et voice.srt existe ; verify.png correspond à la feuille de rythme de bout en bout. Un fichier court avec une fin manquante signifie généralement que -shortest a rencontré une piste vocale obsolète – voir references/audio.md.

8. Remettre le travail

Écrivez un README à côté de la vidéo avec : la feuille de rythme, les constantes de rebranding, les commandes de rendu et les deux pièges du cadre. Ensuite faites un rapport à l'utilisateur :

• où se trouve le fichier et ses spécifications exactes (taille, durée, ips, et s'il est narré ou silencieux – plus la voix TTS utilisée, pour qu'elle puisse être régénérée)
• le chemin de voice.srt pour les pièces narrées, et que Shorts/Reels/TikTok l'acceptent comme téléchargement aux côtés de la vidéo
• le tableau des séquences
• chaque espace réservé et nombre inventé, signalé explicitement – noms de marque, URL et toute mesure affichée dans une maquette. Dites clairement que les chiffres fabriqués doivent être remplacés avant publication si les affirmations doivent être défendables.
• qu'il n'y a aucun lien partageable – c'est un fichier local – sauf si l'utilisateur a demandé un hébergement

Proposez de l'ouvrir : open promo.mp4.

Règles : ne jamais commit ou publier sans approbation explicite. Ne jamais télécharger la vidéo quelque part comme effet secondaire de sa production.

Critères de succès : l'utilisateur connaît le chemin du fichier, ce qui est un espace réservé et comment le modifier.

Règles

Contraintes strictes. Chacune est un échec que ce pipeline a déjà produit.

1. Narrée par défaut, jamais de musique. Écrivez une voix off et laissez-la posséder la ligne de temps, sauf si l'utilisateur a demandé une pièce silencieuse. La musique et le design sonore restent désactivés sauf demande explicite – vous ne pouvez pas fournir de morceaux sous licence, ne tirez jamais de l'audio d'un site de streaming. Supposez une lecture sans son quoi qu'il arrive : chaque affirmation de la voix off est reflétée sous forme de texte à l'écran, et les pièces narrées sont livrées avec un voice.srt. Lorsque vous livrez une pièce silencieuse, dites "silencieux" lorsque vous faites le rapport pour que la lecture silencieuse ne soit pas comprise comme un bug.

2. Une animation par élément, couvrant entrée → maintien → sortie. Deux animations WAAPI séparées avec fill: 'both' se battent : le clip de sortie applique sa première image clé à partir de t = 0, épinglant l'élément visible pendant toute la vidéo. L'assistance io() existe uniquement pour empêcher cela. Symptôme : tous les éléments d'une scène apparaissent en même temps au début de la scène au lieu d'animer leur entrée.

3. Le texte consécutif doit complètement sortir avant que le suivant n'entre. Deux lignes lisibles à l'écran en plein fondu enchaîné se lisent comme un bug de rendu, pas une transition. Programmez la sortie de la ligne N pour qu'elle se termine avant que l'entrée de la ligne N+1 ne commence.

4. Le déterminisme est non négociable. Ensemencez le RNG. N'appelez jamais Date.now(), Math.random(), ni aucune autre source d'entropie. L'horloge maîtresse et le RNG ensemencé sont les seuls contrôles de temps et de variabilité.

5. Images mortes. Chaque image doit contenir soit un élément qui se lit comme du contenu intentionnel, soit une atmosphère qui ne peut pas être confondue avec une scène vide. Un plan de maintien sur un fond noir est une image morte – sauf s'il est immédiatement précédé d'un générique ou d'une fin établie et dure < 1,5 s.

6. Mesurez les voix off avant de coder. Ne devinez pas la durée de la narration. Enregistrez ou synthétisez le script tôt, lisez les durées et dérivez les temps de séquence à partir des mesures. Un rapport voix-rythme qui a été deviné plutôt que mesuré se rompt systématiquement au rendu complet.

7. Le muxage audio est séquentiel, pas en parallèle. Vous ne pouvez pas mélanger l'audio dans une image Playwright. Le cadre rend un mp4 vidéo uniquement. Ajoutez l'audio en deuxième passage, et uniquement après que le processus d'encodage s'est terminé. Si vous muxez pendant que l'encodeur écrit encore, vous obtenez une corruption atom et un fichier que le téléphone ne peut pas lire.

8. Les bulles de caméra et les logos sont des cas particuliers. Recolorer un logo présenté comme du texte blanc fonctionne ; recolorer un actif pixellisé standard d'Apple/Google/Samsung à partir d'un site de marque non – ces actifs sont des PNG plats et n'ont pas de représentations vectorielles fiables facilement disponibles et ne se lisent souvent pas comme du matériel de marque lorsqu'ils sont forcés en blanc. Utilisez plutôt l'actif sur un petit plateau blanc. Pour les bulles de coupe des caméras, lisez references/notch.md – le cadre a un système d'espace réservé.

9. Les bugs de remplissage d'image arrivent par manque de temps. Si un élément a une animation qui commence à t > 0, WAAPI le croit à la position de son image clé à t = 0, ce qui signifie que l'image clé à 0 % d'une animation qui commence à 5 s est visible pendant les 5 premières secondes. Utilisez io() qui traduit tout le groupe en retardant l'ensemble du clip animé, ou utilisez pop() qui applique un masque de débordement de texte. Ce n'est pas élégant – c'est le seul moyen de rendre WAAPI déterministe image par image.

10. Les textes sont trop petits pour être lus sur un téléphone. Si un téléspectateur doit pincer pour zoomer, c'est un échec. Sur une image 1080×1920, le corps du texte doit mesurer au moins 24 px (taille de police de base : 48 px, corps : 36 px) ; toute maquette d'interface doit être réalisable à une échelle où les informations les plus petites lisibles sur l'écran de l'image sont également lisibles dans une vignette de 270 × 480 px.

11. Les chiffres que vous inventez seront pris pour de la vérité. Ne montrez pas de faux chiffres sauf s'ils sont explicitement signalés comme des espaces réservés. Si vous inventez "87 % plus rapide" ou "1 200 utilisateurs" sans mention claire que ce n'est pas réel, l'utilisateur le croira – et peut le publier. Utilisez des formules telles que "[MESURE RÉELLE]" ou "CHIFFRE À REMPLACER" lors de l'affichage de métriques fictives. Faites toujours un rapport comme espace réservé.

12. La lisibilité à la taille d'une tuile n'est pas celle du texte sur mobile. Les émoticônes, logos, icônes d'application et certaines formes d'interface sont reconnaissables à 64×64 px ; le texte ne l'est qu'à partir d'environ 160×40 px par mot. Ne jugez pas la présence et la position des pictogrammes à partir d'une planche contact. Utilisez --at à la place.

13. Les grandes surfaces avec peu ou pas d'action ne sont pas de l'atmosphère – ce sont des images d'attente. Chaque scène doit avoir au moins un élément qui bouge toutes les 3 s, même si ce n'est qu'une lueur subtile ou une animation de respiration.

14. Les motifs d'arrière-plan distrayants. Tout motif répété (grille, points, lignes) qui n'est pas intentionnellement une fonctionnalité de marque attire l'œil plus que le plan précédent. S'il y a un motif, il doit soit être si subtil qu'il est quasi imperceptible sans zoom, soit être la signature visuelle du plan.

15. Le manque d'adhésion au style de la marque. Si $brand est fourni avec des couleurs, une police et un logo spécifiques, le non-respect de ces éléments les rend inutilisables. Si la police de la marque n'est pas disponible, utilisez le Poppins du modèle comme substitut et signalez-le.

16. Pas d'application de filtre général. N'endommagez pas la sortie entière avec des courbes de couleur globales imposées ; chaque scène doit avoir son propre filtre, pas une passe finale de correction des couleurs qui uniformise tout. La palette, le contraste et la sensation sont construits scène par scène.

17. N'appliquez pas de flou gaussien à des centaines de pixels pour créer une abstraction. C'est lent à rendre et semble bâclé. Limitez le flou de l'image entière à < 15 px. Utilisez des dégradés radiaux et des opacités faibles pour le bokeh.

18. Ne passez pas d'arguments de scène à win(). win() prend exactement (couche, tIn, tOut). Il n'accepte pas de troisième ou quatrième paramètre. N'essayez pas de le surcharger pour passer des paramètres de scène – ils sont une distorsion de l'interface du cadre. Utilisez plutôt une fermeture lexicale :

const color = getColor(); // au niveau de la portée de la IIFE
win(layer(() => {
  // utiliser color ici
}), tIn, tOut);

19. Ne réutilisez pas les noms de paramètres dans les fonctions de couche. Le paramètre t de la fonction de couche entre en conflit avec la variable t de la portée englobante de rAF à l'intérieur de pop() et io(). Renommez le paramètre :

layer(clock => {          // ✓ : pas de conflit
layer(t => {              // ✗ : écrase le t de rAF

20. Les encapsulations conditionnelles de layer sont des scènes incomplètes. Si une IIFE de scène entoure son appel win() avec une branche if (CONDITION), elle casse le décompte total des images. Chaque scène doit produire exactement une sortie win(). Si des parties de la scène sont conditionnelles, gérez la condition à l'intérieur du rendu de la couche, pas autour de celui-ci.

21. Les sel et sels hybrides ne se mélangent pas. Le modèle scene-starter.html exporte sel() pour des sélections uniques et sels() pour des sélections multiples. Ce sont deux fonctions différentes avec des API différentes. Ne les utilisez pas de manière interchangeable.

22. Utilisez io() pour les entrées-sorties, pop() pour les poussées uniques. io() est pour les éléments qui entrent et sortent (version complète). pop() est pour les éléments qui apparaissent une fois et restent (version légère). swap() est pour remplacer le contenu d'un conteneur en place. Si vous utilisez pop() pour quelque chose qui doit sortir, vous finirez par avoir des résidus.

23. Chaque scène doit gérer la largeur totale. Les éléments ne doivent pas dépasser la largeur de l'image ni être rognés. Utilisez des pourcentages et vmin/vmax pour vous adapter à différentes tailles.

24. Les couleurs doivent être cohérentes. Si vous utilisez une palette, tenez-vous-y. Ne passez pas du bleu à l'orange sans raisons de scène. Si vous devez changer, faites-le progressivement ou justifiez-le visuellement.

25. Ne pas utiliser d'images à moins qu'elles ne soient générées par code. Les images de stock et les logos sont hors limites. Tout ce qui est visuel doit être généré par code (SVG, Canvas, CSS). Les logos doivent être simplifiés à leurs éléments de design de base.

26. Le texte ne doit pas chevaucher le texte. Si deux éléments de texte sont à l'écran simultanément, ils ne doivent pas se chevaucher spatialement.

27. Le contenu doit être centré. Le contenu principal doit être centré ou visuellement équilibré dans l'image. Ne poussez pas tout le contenu vers un bord.

28. Les polices doivent être chargées et disponibles. Si une police personnalisée est utilisée, elle doit être préchargée avant le rendu. Utilisez le script fetch-fonts.sh depuis les modèles.

Références

Les répertoires suivants contiennent du matériel de référence utilisé par ce flux de travail :

• references/audio.md – Directives de production audio, mesures de voix off et règles de muxage
• references/beats.md – Structure des séquences, règles de copie et directives de rythme
• references/default-style.md – Cahier des charges de style par défaut complet (palette, typographie, mouvements)
• references/teardown.md – Processus d'analyse des vidéos de référence
• references/notch.md – Gestion des bulles de caméra et des échancrures
• templates/render.py – Script de rendu Python
• templates/scene-starter.html – Modèle de scène HTML avec cadre d'animation
• templates/fetch-fonts.sh – Script de téléchargement de polices