TimeCraker/video-motion

video-motion — Superposition d'animations sur vidéo de base (Remotion)

Le design est le code : les coordonnées, les instants et les textes sont tous déclarés dans src/cues.ts (contrat de données, les champs ne doivent pas être modifiés) ; les composants fx ne sont pas codés en dur. Modifiez cues.ts et relancez une commande pour rejouer l'ensemble. Trois couches d'animation : sous-titres SubtitleTrack / barres de données DataBars / repérage Spotlight (cercle / flèche / boîte).

Les diagrammes techniques, les captures de processus/données, Lottie, 3D, les cartes ou l'édition de paramètres Studio suivent les branches correspondantes dans la réalisation visuelle spécialisée. Le réalisateur fournit le contenu et la direction visuelle, le module de production livre les assets/le code du projet et les preuves de rendu ; les composants, types et interfaces moteur actuels sont prioritaires.

Les vidéos d'une série appliquent les conventions de rubrique aux tokens, polices, scènes, sous-titres, couvertures et pistes audio réelles du projet, conformément à la cohérence de série. Réutilisez la version d'entrée réelle et rendez avec le contenu de cette période pour la comparaison ; ne considérez pas qu'une modification d'une valeur de thème unifie toute la vidéo.

Étape 1 · Conception du script (regardez les sources, ne devinez pas)

1. Extrayez des images pour visualiser les sources : npx remotion still remotion/index.ts FootageOverlay <sortie>/f-<n>.png --frame=<n>. Choisissez les images en fonction des plans et des changements clés ; utilisez le chemin absolu de l'image générée pour la lire.
2. Rédigez src/cues.ts, le script de l'animation :
   • Les sous-titres racontent ce qui se voit : dites ce que le spectateur voit à cet instant, segmenté selon le sens et la vitesse de lecture.
   • Le repérage désigne un élément concret : cercle / flèche / boîte pointent vers des éléments réels et notables dans l'image. Vérifiez d'abord la position avec l'image extraite.
   • Les chiffres doivent être sourcés : les valeurs des barres de données proviennent de la source réelle (HUD de l'image, panneau de résultats, données backend). Si impossible, indiquez « données de démonstration » dans les sous-titres.
3. Interprétez les détails pertinents pour l'objectif : le HUD, le chat, les indicateurs et les actions peuvent servir de preuves, mais ne marquez que le contenu nécessaire à l'explication ; ne remplissez pas toute l'image pour la densité des repères.

Étape 2 · Ingénierie et spécifications (adaptatives selon les sources)

1. Copiez templates/remotion-app/ dans le répertoire de travail, npm install (tous les sous-paquets Remotion doivent être installés en même lot, versions strictement liées) ; après installation, exécutez npm run typecheck (la tolérance d'esbuild ne garantit pas la propreté des types, tsc doit passer ; le modèle contient la dépendance de développement typescript, exécutable à tout moment).
2. Spécifications natives : node scripts/probe-footage.mjs <chemin de la source> utilise ffprobe pour générer src/footage-params.ts — la résolution de sortie / la fréquence d'images suivent la source, non codées en dur ; changez de source et relancez ce script.
3. Les sources n'entrent pas dans la compétence : le rendu utilise --public-dir <répertoire des sources> (staticFile lit directement la bibliothèque de sources du projet) ; ne copiez les sources comme public/footage.mp4 que si le paramètre est difficile à passer.
4. Les cues sont écrites en coordonnées de conception 1080p. FootageOverlay intègre transformOrigin: "top left" pour une mise à l'échelle globale adaptée à toute taille de toile — changez de résolution sans modifier les cues, les points d'impact des animations ne dérivent pas.

Étape 3 · Génération (une seule commande)

Avant le rendu, passez la validation : node scripts/verify-cues.mjs (pour le deck, changez les paramètres de src/deck-cues.ts). Les erreurs doivent être à zéro avant de lancer le rendu ; l'avertissement de durée totale n'est qu'un rappel, pas un blocage.

cd <remotion-app>
npx remotion render remotion/index.ts FootageOverlay <dépôt>/products/<nom du projet>/demo.mp4 --crf=16 --public-dir <répertoire des sources>

Le résultat se trouve dans le dépôt products/<nom du projet>/ (règle du répertoire : la compétence est un simple outil, le résultat ne tombe pas dans la compétence ; en cas d'utilisation interdépôt, il tombe dans output/<nom de la compétence>/ à la racine du projet) ; --crf=16 pour haute qualité. Les grosses sources sont rendues en arrière-plan (1440p60 × 30s environ 10 minutes). Validez avec le code de sortie + ffprobe, ne vous fiez pas à la barre de progression.

Étape 4 · Triple vérification (obligatoire, ne pas sauter)

① Programme : code de sortie du rendu = 0 ; npx remotion compositions remotion/index.ts affiche durationInFrames / largeur / hauteur / fps cohérents avec les métadonnées de la source ; npx remotion still sélectionne des images représentatives selon les sous-titres clés, les changements de données et les transitions — pour chaque cue : sous-titres start+0.3s / end-0.3s, barres de données t-0.3s / t+1.5s, repérage t+0.5s / t+ttl+0.3s (convertissez en numéros d'image avec le fps réel fourni par compositions).

② Lecture d'image : lisez les PNG réels image par image pour vérifier : moment d'apparition/disparition et texte, proportions des colonnes et étiquettes de valeurs, type et point d'impact du repérage, pas d'artefacts ni d'étirement sur le fond, pas de caractères illisibles sur l'ensemble de l'image (le chinois utilise Microsoft YaHei comme fallback). En cas de problème, réécrivez le fichier source correspondant, relancez le rendu et vérifiez le problème initial et les enchaînements adjacents ; si un blocage ne peut être jugé ou réparé, signalez-le clairement.

③ Lecture continue et audition : l'extraction d'images ne prouve pas le rythme et la synchronisation. Vérifiez les extraits réels et les pistes audio selon la méthode audiovisuelle media-qc, et enregistrez la portée de la vérification ; l'utilisateur final valide le produit fini.

Étape 5 · Livraison

Rapport : chemin et taille du produit fini / résolution et fréquence d'images (= source native) / conclusion de la triple vérification (incluant le tableau de vérification des images extraites) / emplacement de cues.ts (reproductible). Les produits et le mp4 n'entrent jamais dans git.

Diaporama PPT page par page (DeckVideo, deuxième type de produit)

Un moteur, deux types de produits : les étapes ci-dessus sont « superposition d'animations sur vidéo de base », cette section est « diaporama PPT page par page » — images de page pptx + voix off page par page pour un produit direct, la durée de la page suit la durée réelle de la voix off, les sous-titres apparaissent selon la timeline du script segmenté.

1. pptx et script segmenté : le produit ppt de la compétence ppt est un pptx ; rédigez le script segmenté de narration script.json, ref écrit "page N" (N = numéro de page). Passez d'abord python skills/narration/templates/verify_narration.py <script.json> tout vert. Chaque segment après découpage ≤ 20 caractères (la sous-titre en une seule ligne affiche directement le texte du segment) ; plusieurs segments sur une même page sont reliés par un point pour former la narration orale de cette page.
2. Image de page : python scripts/extract_pages.py <in.pptx> public/deck/pages — conversion COM → PDF puis rendu fitz en 200 dpi, produit p-<N>.png (2667×1500, la toile remplit avec contain).
3. Voix off : test avec powershell -File scripts/make_deck_audio.ps1 <script.json> public/deck/audio (SAPI Huihui génère page-N.wav par page) ; en production, la voix off est faite manuellement dans un outil de montage, exportée sous le même nom page-N.wav dans le même répertoire, le reste est transparent.
4. Branchement et rendu : node scripts/build-deck-params.mjs <script.json> public/deck génère src/deck-params.ts + src/deck-cues.ts (les points de départ des pages, la durée totale, la répartition des sous-titres sont des valeurs dérivées, ne pas les modifier manuellement) → npx remotion render remotion/index.ts DeckVideo <dépôt>/products/<nom du projet>/deck.mp4 --crf=16.
5. Triple vérification : comme à l'étape 4 (programme ffprobe / compositions + lecture d'image extraite + visionnage utilisateur). L2 points clés d'extraction : chaque première image de page +0.3s pour vérifier l'ordre des pages ; au milieu du chevauchement, prenez le start+0.25s de la page suivante (la queue du chevauchement est en fin de fenêtre de page, 0.5s de dissolve croisé) ; sous-titres start+0.3s / end+0.3s pour vérifier le texte et la sortie. À la première image de page +0.3s, le fondu spring n'est pas terminé, l'image entière est légèrement grise : c'est un état intermédiaire de transition, pas un défaut.

Les images de page et la voix off se trouvent dans public/deck/ (.gitignore déjà couvert, pas dans git) ; la toile 1920×1080@30 est une constante en haut de build-deck-params.mjs, changez deux lignes pour 4K.

Produit scénarisé v2→v3 qualité de texture (scene-kit dessin direct, troisième type de produit)

Ligne d'amélioration du diaporama PPT : le sujet de l'image passe de « l'image de page pptx » à une scène animée dessinée directement par des composants Remotion (src/scene-kit/ 24 composants). Le mécanisme de durée de page / audio / sous-titres suit la chaîne de dérivation deck-params. Pour juger « brut » ou « bas de gamme », référez-vous à docs/2026-08-30-motion-grammar.md ; cette section concerne les règles strictes de qualité de texture.

Seuil de qualité

Choisissez le mode de validation selon le type de contenu de docs/2026-08-30-motion-grammar.md. Préservez les tokens et la continuité de la marque. L'image est centrée sur le sujet réel et les informations lisibles ; le mouvement explique les changements. Les blancs, l'immobilité et la quantité d'informations de soutien par plan sont jugés selon l'objectif du plan, sans quota fixe ni rejet automatique du PPT statique.

D'abord, le content-director fournit les sources factuelles, le storyboard et le brief artistique. Ensuite, examinez les images représentatives et un court échantillon. Les schémas structurels sont prioritaires en SVG, les interfaces réelles utilisent des captures d'écran/vidéo, les illustrations sont générées avec un outil imagegen disponible si nécessaire (enregistrez l'actif). Les nouveaux ArtLayer et les animations supplémentaires ne représentent pas automatiquement une qualité artistique validée.

Méthode de conception scénarisée (générale, sans réponse prédéfinie)

Consultez d'abord la bibliothèque de solutions de pages assets/patterns.md — si une situation similaire a déjà une entrée PAT validée, adaptez-la en modifiant les paramètres (situation → mise en page → composants → pièges → images de référence sont dans l'entrée) ; sinon, concevez à partir de zéro. Pour chaque page, déterminez d'abord le type de contenu (narration problème / démonstration fonction / persuasion par données / explication processus / concept / appel à l'action — six types), puis suivez trois règles pour déterminer la forme du sujet et la combinaison de composants : le sujet est déterminé par le contenu du texte ; plusieurs pages de même type ne répètent pas la même solution visuelle ; la famille d'arrière-plan sert l'émotion du contenu. Avant de commencer, produisez un tableau de conception (par page : résumé du texte → type de contenu → forme du sujet → famille d'arrière-plan → combinaison de composants → justification → informations visuelles de la page une par une + source → annotation du sujet). Le tableau de conception est validé en amont, on ne code qu'après validation. Chaque information de soutien est sourcée individuellement (script oral / documentation projet / contenu visible sur la source).

Trois leçons dures (devenues règles)

1. L'état final permet une pause pour la lecture : pour les chats, graphiques ou processus nécessitant des changements d'état, utilisez les composants existants ; les plans statiques sont jugés selon l'information et le rythme, n'ajoutez pas d'animations décoratives pour satisfaire une vérification.
2. Les composants wrapper doivent explicitement transmettre width : lorsqu'un nouveau conteneur enveloppe un ancien composant sans width, le composant enveloppé remplit le parent en block (illustration couvre le titre, coque de téléphone s'élargit à 700px — deux fois la même cause racine) ; tous les wrappers doivent avoir style={{ width, ...style }}.
3. Avant d'utiliser une longue capture d'écran, vérifiez le taux de blanc : obtenez la capture, calculez l'écart-type / le taux de blanc par ligne (script PIL). Une « longue image vide » due à un lazy loading non rendu meurt au scroll — recadrez d'abord en gros plan, réparez la source, puis revenez au scroll.

Arsenal MG (S0-S6, munition principale pour la qualité du produit)

Le modèle embarque tout l'arsenal. Les détails des composants et leur utilisation sont dans assets/component-catalog.md (24 composants scene-kit / 9 verbes entrance-kit / sélection communauté vendor / polices). Ici seulement les règles absolues :

• Règle de version : tous les @remotion/* doivent être exactement à la même version (ex. 4.0.533, pas de ^) — une mauvaise version provoque une erreur dure de Remotion, pas un avertissement ; pour un nouveau paquet, alignez d'abord sur la version existante (l'assertion 3.7 de check-docs veille, le décalage rougit).
• API 4.0.533 constatée (différente de la doc/mémoire, testée ; mise à jour de 4.0.518→4.0.533 vérifiée avec PSNR tout inf sur baseline still, forme de l'API inchangée) : evolvePath retourne des propriétés dash pour les paths non découpés ; interpolatePath(value, from, to) trois paramètres indépendants ; fitText ne prend que withinWidth et retourne un objet {fontSize} ; le chinois multi-lignes ne peut pas utiliser fitTextOnNLines (sépare par espace) ; parseSrt prend un objet {input} (une chaîne nue plante undefined.split), retourne {captions:[{text,startMs,endMs}]} en millisecondes.
• Piège du wrap avec transform (double piège S6) : les verbes wrapped avec transform (CameraPush/SlideGroup/TextBreath/BlurTrail) ne doivent pas envelopper directement un sous-arbre position:absolute — l'élément transform est le containing block des descendants absolute, la hauteur du flux s'effondre à 0, le contenu déborde par le haut. Les composants sont autonomes (CameraPush inset 0 en racine, BlurTrail en flux principal). Évitez quand même d'envelopper nu dans un parent absolute sans dimensions.
• Sémantique de <Trail>/TransitionSeries officiel : la racine de Trail est AbsoluteFill (sémantique de couverture de page), les traînées au niveau élément utilisent BlurTrail de scene-kit (déjà relative) ; TransitionSeries consomme la durée des pages adjacentes, le moteur de produit utilise par défaut zéro transition (Series coupe franche) + verbes intra-page.
• Discipline vendor : copy-paste dans le dépôt, pas de dépendance npm ; mise à jour = re-téléchargement et nouveau intake. Quatre règles dans src/vendor/README.md du modèle.
• Flux d'actifs Lottie : JSON libre de droits dans assets/lottie/ (enregistre trois champs dans README) → copie dans le projet public/ → LottieLayer src référence ; intake interdit les JSON avec expressions (rendu incertain).
• Budget des effets complexes : samples de ShutterBlur et layers de BlurTrail augmentent le coût de rendu ; ThreeStage selon les différences de scène et machine. Rendez d'abord une image/un court extrait représentatif, décidez de l'échelle, pas de quota fixe de plans par vidéo.

Procédure de validation (quatre niveaux)

L1 Programme (code de sortie du rendu avec logs complets, pas de pipe en queue ; ffprobe = compositions alignement des images) ; L2 Extraction d'images (selon le risque, choisissez entrée / plan stable / info spécifique / transition et sous-titres représentatifs, vérifiez l'image réelle ; agrandissement seulement pour inspecter les détails, pas de nombre fixe par page) ; L2.5 Test silencieux (répondez visuellement au sujet de chaque page sans son) ; L3 Rapport (inclut périmètre technique, preuves d'images clés, articles à vérifier manuellement et comparaison avant/après si nécessaire). Si un composant, token ou mise en page a une valeur générique, réintégrez-le dans le modèle/registre selon les règles de retour d'actifs ; le contenu spécifique au projet reste dans le projet, ne créez pas de ticket sans nouvelle expérience. La commande de rendu est identique à DeckVideo (changez la composition pour le composant scénarisé, ex. DeckVideoV2). La couverture utilise npx remotion still (le numéro d'image still doit inclure la durée du spring d'entrée).

Sortie de couverture (Cover, quatrième type de produit)

Ne rendez pas une vidéo mais une image : une commande pour produire un PNG 1920×1080 de couverture, utilisé comme illustration pour la sortie vidéo.

1. Props : products/<nom du projet>/cover-<nom>.json écrit { title, subtitle?, badge?, bg?, preset }. preset ∈ photo (l'image bg remplit + masque dégradé noir 55% en bas pour le contraste) / dark (dégradé sombre, défaut) / clean (fond clair + ligne fine en haut) ; bg est un chemin relatif dans le public/ de remotion-app. subtitle omis = pas de rendu ; badge omis = retour au logo branding ASTERFORGE.
2. Rendu : npx remotion still src/cover-index.ts Cover <sortie>.png --props=<chemin du fichier json> (entrée indépendante, ne passe pas par Root.tsx, pas de conflit avec DeckVideo en parallèle).
3. Vérification : lisez l'image pour vérifier que le titre est complet et non tronqué, que le texte est lisible sous le masque photo, qu'il n'y a pas de caractères illisibles ; utilisez le chemin absolu du produit réel, revérifiez la version ou le hash actuel. Ajustez le nombre de lignes du titre selon la toile cible et les besoins de lecture.

Limites et pièges

• Utilisez le chemin absolu du produit réel pour lire l'image, revérifiez la version ou le hash actuel du fichier ; ne convertissez les chemins que si l'outil spécifique a une limitation de chemin.
• Console GBK : imprimez en anglais.
• Chrome Headless Shell : la première fois, npx remotion browser ensure télécharge depuis Google (plusieurs centaines de Mo), peut expirer sur le réseau chinois — signalez l'échec immédiatement, ne réessayez pas le téléchargement de gros fichiers.
• Gros médias, dépendances et caches n'entrent pas dans Git ; les recettes de production, la couverture, les sous-titres, les configurations de publication et les métadonnées de validation sont conservés selon les règles d'archivage.

Références actuelles du processus et techniques

Utilisez node scripts/studio.mjs init --id <nom> --line b pour sortir le modèle. Les commandes deps/typecheck du job.json sont reproductibles ; les commandes params/render/QC de ce projet sont ajoutées au job.json une fois la scène et la piste audio réelles déterminées. Après le rendu, appelez media-qc. Les rapports techniques et la validation finale utilisateur sont enregistrés séparément ; videz le cache après validation d'archivage.

Les remotion-best-practices officiels sont installés fixement dans le cache du projet via python scripts/install-upstream-skills.py, puis montés par setup-skills. Source dans references/upstream.json ; c'est une référence technique, ne remplace pas le flux de ce dépôt. La référence officielle 4.0.538 et le moteur actuel 4.0.533 sont gérés séparément. Avant d'utiliser une nouvelle API, vérifiez d'abord les types locaux et le rendu réel, ne mettez pas à jour automatiquement.