Que fait sourceframe ?

Une méthode pour réaliser une vidéo comme on construirait un système : d'abord les exigences, un registre de ce qui est vrai, un contrat de mise en page, de petites étapes vérifiées, la mesure avant l'opinion. Le produit est une courte vidéo d'abord silencieuse (15 à 90 s) qui explique un mécanisme en suivant un seul élément focal à travers celui-ci. Le nom est la règle : chaque image remonte à une source.

Cette compétence a été distillée à partir d'une construction réelle (une explication de 77 s sur la façon dont coreboot exécute du code C avant que la DRAM n'existe, avec une grille de cache de 4 096 cellules, une puce flash 3D et un entraînement DRAM) et re-prouvée sur un second sujet sans rapport (examples/merkle-proof, une preuve d'inclusion Merkle dont chaque hachage est calculé par le build). Les chemins ci-dessous sont relatifs au dossier de cette compétence.

Quand l'utiliser, quand ne pas l'utiliser

À utiliser pour : les vidéos « comment ça marche », les présentations de protocoles ou d'algorithmes, les visites d'architecture système, les séquences « que se passe-t-il quand », les rejeux post-mortem. Elle excelle lorsque le sujet a un mécanisme avec un état qui change (des bits basculent, un pointeur se déplace, un hachage se propage).

Ne pas l'utiliser pour : les montages de têtes parlantes ou de séquences, les publicités de produits, le branding animé pur, tout contenu où l'opinion prime sur le mécanisme. Pour ceux-ci, utilisez une compétence de mouvement simple. Si l'utilisateur ne souhaite qu'un carrousel statique, utilisez une compétence de carrousel.

Les sept principes

Registre avant pixels. Écrivez FACTS.md (affirmation, preuve, état) avant la première scène. État V = lu depuis une source dans cette session, C = calculé par le build, S = schématique et étiqueté à l'écran, H = mémoire (re-vérifier), N = nécessite une source (bloque l'expédition). N'inventez jamais un nombre, un symbole, un chemin, une version. Préférez C : laissez le build calculer ce que la vidéo montre.
Un seul élément focal. Une chose par image est l'ancre du regard : elle reçoit la couleur « focus » unique, elle est toujours l'étape en cours, et elle n'entre jamais en compétition avec une seconde. Tout le reste est plus discret par construction.
La couleur est un sens. Les rôles de palette (data, focus, ok, bad, ink) sont sémantiques et fixes pour toute la vidéo. Ne choisissez jamais une teinte pour l'apparence.
Déterminisme. Une image est une fonction pure de son numéro d'image. Pas de temps réel, pas de Math.random, pas de transitions CSS, pas de useFrame. Utilisez hash(n) avec une graine pour tout ce qui est pseudo-aléatoire. C'est ce qui rend possible le rendu parallèle, les images fixes et la synchronisation sonore ultérieure.
L'image est l'instrument. L'animation existe pour montrer un changement d'état. Chaque mouvement répond à la question « que montre ceci ? ». Interdit : le même fondu sur chaque bloc, le rebond ou l'assouplissement élastique, la décoration en boucle, la lueur pour elle-même.
Mesurez d'abord, regardez ensuite. Les chiffres sont bon marché et exacts ; les opinions sont coûteuses. Vérifiez les types, le registre, sondez le conteneur, mesurez les pixels quand vous le pouvez, puis regardez une planche contact par tour.
Règles d'arrêt. Maximum trois tours de révision par ensemble de scènes, maximum trois corrections par tour. Dites ce qui reste et pourquoi vous vous êtes arrêté. L'honnêteté vaut mieux que le polissage : étiquetez ce qui n'a pas été vérifié.

Les dix phases

Chaque phase a un livrable et une porte. Ne sautez pas de porte pour gagner du temps : les erreurs coûteuses sont toutes en amont.

#	phase	livrable	porte
0	analyse	vérification d'adéquation en une ligne, plateforme, durée, silencieux d'abord ou avec son	ne demandez que ce qui bloque le travail (une question), sinon décidez et énoncez
1	brief	sections 1 à 3 de `BRIEF.md`	le message clé tient en une phrase ; l'élément focal est nommable en une phrase
2	preuves	`FACTS.md` rempli pour chaque affirmation prévue ; scripts de calcul pour les lignes `C`	`tools/ledger_lint.py` passe ; pas de ligne `N`
3	direction	kill-list, phrase d'idée, moment signature, jetons `theme.ts`	test du concurrent réussi (voir `references/02-direction.md`)
4	storyboard	tableau : scène, secondes, ce qui bouge, légende, ligne du registre ; `timeline.json`	budget de légende respecté ; durée totale justifiée
5	fondations	projet échafaudé, polices, thème, coque, caméra, aperçu fonctionnel	une image fixe rend ; WebGL fonctionne (voir pièges : longueur de chemin)
6	construction	scènes, d'abord les plus dures et les plus centrales	par scène : images fixes, une planche contact, au maximum 3 corrections
7	ressources	ressources 3D et d'icônes, procédurales sauf si une source sous licence est nécessaire	chaque logo ou marque utilisé inchangé et crédité
8	vérification	rendu complet, encodage, sonde, feuille d'images, registre	toutes les vérifications automatiques vertes ; feuille examinée ; défauts listés
9	livraison	mp4, image de couverture, texte de légende, texte alternatif, crédits, liste « non vérifié »	l'utilisateur peut le publier sans se demander ce qui est vrai

Phase 0 : analyse

Énoncez en une ligne ce que vous allez faire : Lecture comme : <médium> pour <lecteur>, <élément focal>, <durée>. Ne posez une question que si la réponse change ce que vous construisez (plateforme et rapport hauteur/largeur ; si le son suivra ; quelles sources sont autoritaires). Toile par défaut 1080 x 1350 (4:5) à 30 ips pour les réseaux sociaux ; voir references/08-adapting.md pour 16:9, 1:1, 9:16.

Phase 1 : brief

Copiez templates/starter/BRIEF.md. Remplissez l'intention (médium, lecteur, message clé, élément focal, ambiance). Le message clé doit être une phrase qu'un spectateur pourrait répéter. Si vous ne pouvez pas nommer l'élément focal en une phrase, vous n'avez pas encore de vidéo : décidez et dites-le, ou posez une question.

Phase 2 : preuves (la partie que la plupart des vidéos sautent)

Identifiez les sources principales (spécification, RFC, arbre source, fiche technique, page de manuel, sortie mesurée). Lisez les lignes exactes que vous allez citer. Enregistrez fichier:ligne ou URL plus section.
Pour chaque nombre, demandez : le build peut-il le calculer ? Si oui, écrivez un script qui le calcule, le recoupe d'une deuxième manière, abandonne en cas de désaccord, et écrit un module généré que les scènes importent (examples/merkle-proof/scripts/compute.mjs est le modèle : la récursion RFC contre le build itératif doivent être d'accord ou rien n'est écrit).
Tout ce qui ne peut pas être sourcé devient soit un schéma étiqueté (S, et le mot « schéma » apparaît à l'écran), soit est coupé. [NÉCESSITE SOURCE] visible est autorisé dans les brouillons, jamais dans le rendu final.
Les données illustratives sont légales lorsqu'elles sont honnêtes : les exemples d'éléments inventés sont affichés comme un texte d'exemple simple et enregistrés comme S.
Exécutez python tools/ledger_lint.py comme un fil de détection : chaque chiffre dans une chaîne de scène doit apparaître dans le registre.

Format complet et exemples : references/01-brief-and-ledger.md.

Phase 3 : direction

Écrivez la phrase d'idée : « Dans cette vidéo, [quelque chose qui appartient au sujet] devient [le dispositif]. » Réalisez le test du concurrent : si une vidéo générique sur le sujet pourrait utiliser la même phrase, c'est une idée de catégorie, pas une idée. Choisissez un moment signature (le seul mouvement fort) et la kill-list (les trois visualisations les plus évidentes, désormais interdites : typiquement une pile de rectangles avec des flèches, une capture d'écran, un objet centré sur un dégradé). Réglez les cadrans : variance, intensité du mouvement, densité, chacun de 1 à 10, à partir du sujet (une explication de sécurité pour les ingénieurs est calme et dense ; un teaser de lancement n'est ni l'un ni l'autre). Détails et règles de chorégraphie dans references/02-direction.md.

Phase 4 : storyboard et timing

Un tableau : scène, secondes, ce qui bouge, légende, ligne du registre. Budgets qui ont tenu dans la pratique :

légende au maximum 2 lignes et 14 mots, minimum 48 px sur une toile 1080 (un téléphone affiche la toile à environ 0,36x, donc 48 px correspondent à environ 17 pt) ; les étiquettes au moins 26 px ;
une légende reste au moins mots / 2,6 + 0,8 secondes, jamais remplacée au milieu d'une phrase ;
une idée par scène ; une scène de plus de 12 s nécessite des battements internes (étapes) avec leur propre légende ;
l'ensemble est une idée racontée une fois : coupez toute scène dont la suppression ne fait pas perdre une ligne du registre.

Écrivez l'ordre des scènes et les durées dans timeline.json uniquement. Remotion, les scripts de vérification et le pipeline sonore cuelab lisent tous ce même fichier.

Phase 5 : fondations

node scripts/scaffold.mjs <target-dir> --install

Ensuite : éditez src/theme.ts (palette, toile), placez les polices dans public/fonts, définissez BRAND dans src/ui/Chrome.tsx, éditez timeline.json. Gardez le chemin du projet court (voir pièges : ANGLE a besoin d'un chemin court sous Windows). Rendez une image fixe d'une scène 3D avant d'écrire plus : si WebGL échoue maintenant, il échouera plus tard.

Phase 6 : construction, scène par scène

Ordre : la scène signature en premier (la grille 3D difficile), puis les scènes qui en dépendent, puis les scènes de liaison. Par scène :

écrivez la scène selon le contrat de mise en page (references/03-layout-contract.md) en utilisant Shell, les jetons et les helpers d'animation ;
bash tools/shots.sh <Scene> out/<scene> <images...> : choisissez les images au début, au milieu du mouvement et au repos de chaque battement, une planche contact ;
lisez la planche une fois, répondez : première/deuxième/troisième chose vue ? élément focal à l'endroit prévu ? quelque chose de générique ? Que couper ? Corrigez au maximum trois choses ; ne re-photographiez que les images modifiées ;
lorsque la scène est stable, passez à la suivante. Ne peaufinez pas la scène 2 pendant que la scène 6 n'est pas construite.

Les motifs d'animation qui portent le travail (dévoilements de lignes masquées, lignes décalées, brassage de hachage, basculements de bits, étiquettes projetées sur 3D, grilles instanciées) sont dans references/04-remotion-patterns.md ; les recettes 3D dans references/05-three-assets.md.

Phase 7 : ressources

Préférez les ressources procédurales : elles sont déterministes, minuscules, thématisables et ne comportent aucun risque de licence. Les boîtes en feuille, les logos extrudés, les grilles de cellules instanciées et les champs de points couvrent la plupart des vidéos explicatives. Utilisez des maillages générés par IA uniquement lorsqu'un objet organique ou de marque est essentiel et que la licence et le coût du service sont acceptables pour l'utilisateur ; ne cachez jamais qu'une ressource a été générée. Logos et marques réels : utilisez le fichier du projet inchangé (recolorer une marque monochrome est généralement acceptable ; la redessiner ne l'est pas), vérifiez la licence, créditez à l'écran ou dans la légende.

Phase 8 : vérification

Automatique, dans cet ordre (du moins cher au plus cher) :

npx tsc --noEmit                 # types
python tools/ledger_lint.py      # nombres vs registre
bash tools/shots.sh Main out/m <images>   # planche contact, regardez une fois
npm run render && npm run encode          # rendu brut, puis yuv420p h264 à plage limitée
                                          # encode.sh se termine en exécutant tools/probe.py

tools/probe.py vérifie le codec, yuv420p (pas yuvj420p), la taille, les ips, la durée par rapport à timeline.json, la plage limitée, l'absence d'images noires, l'atome fast-start. Examinez ensuite une planche du mp4 final (images toutes les 4 s, extraites avec ffmpeg) et une image en taille réelle pour la netteté du texte. Si un critique de design est disponible (par exemple la compétence creator-critic), exécutez-le sur un dossier d'images fixes : traitez les bloqueurs comme des bloqueurs et les majeurs comme des questions. Liste de contrôle complète : references/06-verification.md.

Phase 9 : livraison

Livrez : out/video.mp4, une image de couverture (une image de repos où le titre et l'élément focal sont tous deux lisibles), un brouillon de légende (simple, sans emphase, source nommée), un texte alternatif (une phrase sur ce que montre la vidéo), des crédits (ressources, logos, licences), et une liste « non vérifié » (tout ce qui a l'état H ou S dans le registre, tout ce que le build ne peut pas prouver, tout ce que vous n'avez pas pu examiner visuellement). Ne publiez rien vous-même.

Choisir entre options (tableaux de décision)

question	choisissez	parce que
2D ou 3D pour un élément	3D uniquement lorsque la profondeur ou la forme physique est le point (une puce, une pile, un champ d'un million d'éléments) ; sinon 2D	La 3D coûte du temps de rendu et de la lisibilité ; utilisez-la là où elle explique
caméra	orthographique, `manual = true`, fixe par scène	L'orthographique maintient les étiquettes projetables et les mesures honnêtes
étiquettes sur la 3D	HTML ou SVG projeté avec `project()`	Le texte reste net et stylisé
beaucoup de cellules répétées	`InstancedMesh` (milliers) ou `Points` (un million)	appels de dessin
polices	deux familles au maximum, OFL ou sous licence, regroupées dans `public/fonts`	déterminisme, pas de réseau au rendu
texte sur dalle ou remplissage	texte foncé sur remplissage clair, jamais blanc sur clair	contraste
son	concevez-le après que l'image est verrouillée, à partir de `timeline.json`	voir la compétence cuelab

Modes d'échec que cette méthode vise à prévenir

La vidéo belle mais fausse (pas de registre) ; la vidéo correcte mais illisible (pas de contrat de mise en page) ; la vidéo générique (pas de phrase d'idée, pas de kill-list) ; la vidéo qui semble bonne dans le studio et casse au rendu (non-déterminisme) ; la vidéo qui semble bonne à 100 % et est floue sur un téléphone (tailles de police plancher, test de vignette) ; la vidéo qui ne peut pas être notée (pas de timeline unique) ; la vidéo dont les affirmations ne peuvent être vérifiées par personne (pas d'honnêteté de livraison). Les bogues concrets rencontrés lors de la construction des deux premières vidéos, chacun avec symptôme, cause et correctif, se trouvent dans references/07-pitfalls.md ; lisez-le avant de déboguer quoi que ce soit qui ressemble à de la magie.

Fichiers de cette compétence

chemin	quoi
`references/01-brief-and-ledger.md`	modèle de brief, format du registre, comment calculer et recouper les faits
`references/02-direction.md`	phrase d'idée, kill-list, cadrans, règles de chorégraphie, jetons de mouvement
`references/03-layout-contract.md`	toile, zones de sécurité, tailles de police plancher et arithmétique d'échelle téléphone
`references/04-remotion-patterns.md`	motifs d'animation testés avec code
`references/05-three-assets.md`	three.js dans Remotion : caméra, shader feuille, arêtes, instanciation, points, extrusion, projection d'étiquette
`references/06-verification.md`	l'échelle de vérification complète, le protocole de planche contact, encodage et sonde
`references/07-pitfalls.md`	tous les bogues réels rencontrés, avec correctifs
`references/08-adapting.md`	autres rapports hauteur/largeur, thèmes, langues, variante sans 3D, transfert au son
`templates/starter/`	un projet Remotion fonctionnel : thème, helpers, chrome UI, kit three.js, outils, modèles BRIEF et FACTS
`scripts/scaffold.mjs`	copie le starter dans un nouveau projet et installe
`../../examples/merkle-proof/`	un exemple complet de 36 s avec faits calculés, registre, rendu et sonde

Note de licence que vous devez transmettre

Remotion n'est pas sous licence MIT. Il est gratuit pour les particuliers et pour les équipes de trois personnes maximum ; les entreprises dépassant ce seuil ont besoin d'une licence payante (le CLI Remotion affiche l'avis, voir remotion.pro/license). Informez l'utilisateur une fois, tôt, lorsque le projet peut être commercial. three.js, React et les polices regroupées (SIL OFL) sont permissifs.

endlessconflict/sourceframe

Qu'est-ce que sourceframe ?

Demander à votre IA préférée

Documentation