robinfernandez2016-create/motion

Que fait motion ?

Motion graphics écrits en code : chaque couleur, temps et marge provient d'un fichier de marque, et rien n'est rendu sans que la personne ait vu au préalable 2 ou 3 images-clés. Les règles ci-dessous sont issues de corrections réelles ; chacune explique pourquoi elle existe.

À quoi ça sert

Pièce	Qu'est-ce que c'est
Broll animé	Couvre un passage de voix avec une scène ou un graphique, en plein écran
Alpha	Graphique avec transparence qui se place au-dessus de la vidéo, ou derrière la personne
Pop-up	Une donnée qui entre, reste environ 1 s et disparaît
Sous-titres	Sans boîte et avec un mot mis en avant, ou cinétiques (mots-clés uniquement)
Simulation de chat	Une conversation d'une app de messagerie, crédible et lisible
Écran	Un site web ou une app de bureau dans une carte 4:3 avec titre
Cover	L'image 0 du reel

Avant de maquetter, décide lequel des deux formats :

1. Montre des données ou un produit de l'intérieur (panneau, métriques, boîte de réception) : interface plate et dense, tout lisible en même temps, photos et vidéos réelles dans les cartes, caméra quasi immobile (échelle 1,00 → 1,02). Les états changent sur place : la ligne était déjà là et son étiquette change. Le cadre, rempli.
2. Raconte une scène : envoie le métrage. Plan large, caméra qui bouge vraiment, peu de décor et une seule phrase.

Un diagramme n'est pas une pièce : si l'idée peut se dessiner comme une carte de flèches, montre le produit en faisant exactement cela.

Préparation

• Un projet Remotion (npx create-video@latest), Node et ffmpeg.
• La marque en code dans src/marca/ : tokens.ts (couleurs, types, rayons, marges), movimiento.ts (temps et courbe) et un useMarca() qui fournit le tout mis à l'échelle. Comment assembler, avec un exemple : reférences/tokens.md.
• Une entrée par pièce (src/piezas/<pieza>.tsx, avec son registerRoot et ses Composition) : le bundle reste petit et une pièce n'en casse pas une autre.
• Toile de 1080×1920 à 30 ips, sauf si la séquence dit autre chose : lis la taille et les ips de la séquence avant de commencer.

Le flux

1. Brief. Passage exact dans la séquence (entrée → sortie), ce que dit la voix dans ce passage, données autorisées et leur source, matériel utilisable et ce qu'il ne veut pas. Si quelque chose manque, demande-le.
2. Voix. Transcrit mot à mot la voix telle qu'elle est dans la timeline, pas le fichier brut (reférences/subtitulos.md). La voix réelle d'un tournage diffère souvent du script.
3. Durée. Celle du passage, dans une constante avec le timecode en commentaire, plus 1 image de marge : export const DURACION = 157; // 00:00:51:22 → 00:00:56:29.
4. Design. Ce qui se voit correspond à ce que dit la voix, phrase par phrase. Les instants qui partagent animation et son (chaque message qui entre, chaque impact) vont dans une constante que lisent la composition et le script d'effets.
5. Croquis. 2 ou 3 images clés avec remotion still, avec les guides de zones de sécurité peints. Montre-les et attends le oui.
6. Rendu avec fond ou avec alpha (ci-dessous).
7. Son. Toute animation est livrée avec son effet sonore : passe les instants au skill sonido.
8. Contrôle et livraison (en bas de cette page).

Ce qui ne se casse pas

• Aucune couleur ni mesure à la main dans une composition : tout vient des tokens. Pourquoi : changer une teinte, c'est toucher un fichier, et personne n'invente un nouveau gris dans chaque pièce.
• Une seule chose mise en avant par image, avec la couleur d'accent de ta marque : un mot du titre ou un bouton, jamais les deux. Pourquoi : si deux choses crient, on ne lit rien. (Les couleurs propres à une interface simulée ne comptent pas.)
• Rien ne rebondit. Entrées et sorties avec les temps et la courbe des tokens ; rien de spring(). Pourquoi : spring() dépasse et revient, ce qui se lit comme un jouet.
• Temps en secondes, jamais en images. Pourquoi : avec des retards en images, passer de 30 à 60 ips double la vitesse.
• Zones de sécurité, avec de l'air (tableau de nombres). Ce qui se lit va à ~100 px des côtés et à ~290 du haut : 54 et 224 sont la ligne à ne pas franchir, pas le support du design. Pourquoi : l'interface de l'app cache les bords, et collé à la limite « tout est très aux extrémités ».
• Le centre de la composition, en x 540. On ne décale pas le design pour éviter les boutons de l'app : ce qui tombe à cette hauteur se rétrécit symétriquement. Pourquoi : une composition décalée se remarque plus qu'une icône dessus.
• Chaque objet entièrement dans le cadre. Rien coupé par le bord ; ce qui ne joue pas le rôle principal s'écarte avec un fondu. Pourquoi : un téléphone ou une carte coupés se lisent comme une erreur.
• Dans un broll, il se passe quelque chose : la caméra bouge et une action concrète a lieu, qui est la phrase de la voix, pas le thème. Pourquoi : « il ne se passe rien » est le rejet le plus courant. L'exception est le produit réel d'un client : on le reproduit, on ne le recrée pas ni ne lui invente de mouvements.
• Quelque chose de nouveau toutes les 4 s au maximum, et jamais deux mouvements identiques à la suite. Pourquoi : deux zooms collés effacent la coupe.
• Rien d'immobile à la fin : une poussée très lente dans le dernier passage. Pourquoi : un plan figé se lit comme une erreur de rendu.
• Un nombre qui monte est un graphique ; un nombre qui apparaît est un cartouche. Dans un alpha, chaque chiffre a son objet animé (compteur, mesureur, barre, icône qui agit) et le texte accompagne. Pourquoi : un texte brut sur la vidéo se lit comme un sous-titre.
• Plan séquence, profondeur et détail. Une caméra qui parcourt la scène au lieu d'entrées séparées, des objets à différentes profondeurs, noms, heures et états dans chaque élément. Pourquoi : les pièces qui étaient des diagrammes avec beaucoup de blanc ont été rejetées pour « trop simples ».
• Sous-titres sans boîte, un mot mis en avant par phrase ; jamais sur un broll ni là où un graphique dit déjà la même chose (reférences/subtitulos.md).
• Chat simulé lisible : téléphone au centre, l'app entière agrandie de manière homogène, un message à la fois avec le temps de lire ; pour mettre en avant, on floute le reste, jamais un voile foncé (reférences/alfas-y-chats.md).
• Un écran réel dans le plan commande : rien au-dessus de son texte ni de son en-tête ; le pop-up va dans sa zone vide.
• Sans bordures noires ni arrêtes dures : si la caméra bouge sur du métrage, échelle minimale 1,04 (1,18 si le plan se déplace latéralement) ; dégradés de pas doux et coins arrondis. Pourquoi : un zoom arrière qui montre du noir, ou un dégradé par à-coups, se lit comme un cadre.
• On n'invente pas de données et on ne répète pas les pièces. Chiffres, noms et captures viennent de la personne ; une simulation ne montre jamais de données de vrais clients. Chaque pièce apporte son propre graphique : répéter celui d'une autre se remarque.
• Les animations s'ajustent à la voix, jamais l'inverse : on n'insère pas de pauses dans la voix pour faire correspondre un graphique.
• Une correction ne se rend pas entièrement : uniquement les passages qui changent, raccordés et avec un nouveau nom (reférences/3d-y-trampas.md). Pourquoi : la version déjà placée n'est pas écrasée, et on ne perd pas une heure de rendu pour trois secondes.

Nombres

Quoi	Valeur (toile de 1080×1920)
Latéraux	54 px de chaque côté (ce qui se lit, à ~100)
Plafond	rien à lire au-dessus de y 224 (ce qui se lit, depuis ~290)
Bande de lecture	de y 420 à y 1495
Colonne de boutons	depuis x 897, de y 1228 vers le bas ; à cette hauteur, ce qui se lit va dans x 183–897
Grand chiffre large	entièrement au-dessus de y 1228
Téléphone en plan détail	au maximum 0,8 de la largeur du cadre
Ensemble en plan large	au maximum 1080 − 2 × 54 de largeur
Pop-up	un peu plus de 1 s à l'écran, puis disparaît (s'ils restent, au bout de 8 s il y en a six et on n'en lit aucun)
Rythme	quelque chose de nouveau toutes les 4 s ou moins
Échelle minimale avec caméra sur métrage	1,04 (1,18 avec déplacement latéral)
Remplissage d'une pièce de données	environ 75 % de la boîte utile ; en dessous de 50 % on lit comme un croquis
Remplissage d'une pièce de scène	40–60 %
Recadrages de cover	4:5 du feed: y 285–1635 · 3:4 du profil: y 240–1680

Le remplissage est la partie de la boîte utile occupée par quelque chose qui n'est pas du fond ; il se mesure sur les stills, pas à vue.

Rendu

# Croquis : une image seule
npx remotion still src/piezas/mi-pieza.tsx MiPieza out/boceto_f45.png --frame=45

# Avec fond (opaque : cache le plan)
npx remotion render src/piezas/mi-pieza.tsx MiPieza out/mi-pieza_FONDO.mov \
  --codec=prores --prores-profile=4444 --pixel-format=yuv444p10le

# Avec alpha (transparent : on voit la vidéo en dessous)
npx remotion render src/piezas/mi-pieza.tsx MiPieza-Alfa out/mi-pieza_ALFA.mov \
  --codec=prores --prores-profile=4444 --pixel-format=yuva444p10le --image-format=png

# Toute pièce avec 3D (CSS ou three.js), en still et en rendu :  --gl=angle

• Fond et alpha sont la même composition avec une prop transparente ; la version alpha ne peint pas de toile et son id se termine par -Alfa.
• --prores-profile=4444 seul ne donne pas d'alpha. Vérifie-le : ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt -of csv=p=0 out/mi-pieza_ALFA.mov doit commencer par yuva.
• En alpha, il n'y a pas de toile : chaque texte a besoin de sa propre surface ou disparaît sur un métrage sombre.
• Si le disque est juste : le ProRes 4444 avec alpha prend environ 1,35 Go par minute à 1080. Le passer en PNG dans MOV (ffmpeg -i x.mov -c:v png -pix_fmt rgba y.mov) est sans perte, conserve l'alpha et pèse environ 7,5 fois moins.
• Interfaces avec perspective qui sortent avec le texte flou : rendu avec --scale=2 et redimensionnement à 1080 avec lanczos.
• Pour plusieurs stills, un script qui fait un seul bundle et le supprime à la fin (reférences/3d-y-trampas.md).

Cover à l'image 0

• La cover est la première image du reel exporté : <Sequence durationInFrames={1}> avec la cover et le reel entier dans <Sequence from={1}>. Les plateformes choisissent la cover parmi les images de la vidéo ; ainsi il n'y a pas de fichier séparé. Si le sélecteur ne tombe pas sur la 0, donne deux images.
• Personnage au centre : axe en x 540, son centre près de y 900–960, et entièrement dans le 4:5 et le 3:4, avec le titre aussi dedans. Pourquoi : la grille du profil et du feed recadrent la cover, et dans la miniature se décide le clic.
• Rien de grand décor aux coins. Avant de livrer, sors une version avec les recadrages simulés (voile en dehors du 4:5, lignes du 3:4 et axe central) et regarde-la.
• Si la cover est collée avec ffmpeg depuis un JPG, attention à la plage de couleurs (reférences/3d-y-trampas.md).

Style « liquid glass » (optionnel)

Verre type iOS pour cartes et boutons, sur fond clair. Ça fonctionne s'il y a quelque chose à réfracter, une seule lumière pour toute la scène et des choses vivantes dedans ; sinon, « ça ressemble à un dépliant ». Règles et nombres dans reférences/cristal.md, qui explique aussi comment masquer du texte brûlé dans le métrage. Aucun style n'est éternel : chaque pièce apporte quelque chose que les précédentes n'avaient pas.

Pièges qui coûtent le plus cher

• Vidéo figée : un <OffthreadVideo> qui entre après l'image 0 va dans <Sequence from={entrada} layout="none">. Sinon, il demande le temps depuis l'image 0 de la composition et reste immobile sur sa dernière image, sans générer d'erreur. Vérifie que startFrom + durée visible ≤ durée du clip.
• Première image noire dans three.js avec post-traitement : le compositeur doit demander delayRender et dessiner avant de le libérer. Un remotion still seul est le test.
• 3D coupé en ligne droite (demi-téléphone blanc) : il manque --gl=angle.
• Copies fantômes du texte avec flou de mouvement à 29,97 ips : le flou, uniquement dans les fenêtres où la caméra balaye.
• Disque plein : chaque bundle copie public/ dans le dossier temporaire du système ; s'il n'est pas supprimé, il s'accumule (dans un cas réel, des centaines de Go). Regarde df -h avant les longs rendus.
• defaultProps se mélangent avec les props de chaque rendu : dans les defaults, uniquement ce qui est obligatoire.

Le reste (appareillage 3D en CSS, three.js, raccords, ffmpeg, zsh) : reférences/3d-y-trampas.md.

Ce qui est livré et ce qui est vérifié

Est livré : le .mov (FONDO ou ALFA) avec la durée exacte du passage et son effet sonore dedans ou à côté, les stills du croquis approuvés et une ligne dans pieza.md avec ce qui a été fait et ce qui reste.

Est vérifié, en mesurant :

• Durée et ips identiques à la séquence. Compte les paquets (ffprobe -v error -count_packets -show_entries stream=nb_read_packets -of csv=p=0 x.mov) : en ProRes, nb_frames ment.
• Vrai alpha : pix_fmt commence par yuva.
• Rien en dehors des zones de sécurité : guides peints sur les stills des moments clés et l'encre mesurée dans la bande du texte (x min ≥ 54, x max ≤ 1026).
• Une seule chose mise en avant par image.
• Aucune vidéo figée ni image noire : lis-la, ne te fie pas aux stills.
• Image par image là où entre un message ou la caméra balaye : ni sauts ni fantômes.
• La dernière image, complète et avec quelque chose en mouvement.
• npm run lint (eslint + tsc) passe, et il n'y a pas de #hex isolé en dehors des tokens.