Axiris · Dossier de production · 16.08.2026
Trois plans, montés et finis en 2520 × 1440 à 96 images/seconde. Générés en local, sur une seule machine. Voici la méthode et tous les temps réels — mesurés, pas estimés.
Le fichier d'origine · 2520 × 1440 · 96 i/s · 15,5 s · 28,6 Mo télécharger
Cette page sert à voir le fichier tel qu'il sort. Les réseaux ré-encodent systématiquement et plafonnent la cadence — la même vidéo publiée ailleurs y perd ses 96 images par seconde. C'est pour ça qu'elle est ici.
Pas un effet, pas une astuce de conditionnement : une partition qu'on exécute.
Un storyboard donne déjà la composition. Chaque case a été rendue en image avant qu'on parle de vidéo. Le travail ne consiste donc pas à faire inventer un cadrage au modèle, mais à mettre en mouvement une image déjà décidée.
Chaque plan porte quatre champs : l'intention, le mouvement de caméra, le paysage sonore, et l'image de départ. Il se lance seul, se regarde, se refait si besoin — puis se valide.
Aucun cache disque. Aucun état partagé.
Enchaîner des plans se fait souvent en gardant un cache de latents sur disque d'un clip au suivant. C'est efficace, et ça attache les clips les uns aux autres : toucher au plan du milieu, c'est toucher à l'état de toute la chaîne.
Ici, chaque plan est une soumission complète et indépendante — son graphe entier, son ancre, sa graine. Rien ne persiste entre deux plans. On refait le plan 2 après avoir validé le 5, dans n'importe quel ordre, sans rien recalculer et sans rien invalider.
Ce que ça coûte, dit franchement : la continuité ne vient pas d'un cache de mouvement mais de la dernière image du plan précédent. C'est une continuité d'image, pas de mouvement — sur un plan continu très rapide, un cache ferait sans doute mieux. Pour un storyboard, la question ne se pose pas : des plans distincts n'ont rien à se transmettre.
D'où elle vient, et où elle en est
La timeline s'inspire de l'interface de LTX Director 2.0 (WhatDreamsCost, GPL-3.0). Aucune ligne de son code n'a été reprise : l'implémentation est écrite depuis nos propres mesures, précisément pour rester libre de sa licence. On utilise le logiciel, on ne le vendorise pas — et ce qu'on écrit reste à nous.
C'est aussi pourquoi elle est encore en développement, et pourquoi cette page montre des chiffres plutôt qu'un outil. Un accès suivra peut-être.
1344 × 768 — la résolution native du modèle. 5 secondes chacun, son compris.
| Étape | Détail | Temps |
|---|---|---|
| Génération d'un plan | 5 s de vidéo, son inclus | 90 – 100 s |
| Les trois plans | lancés et jugés un par un | ≈ 285 s |
| Montage | niveau sonore égalisé par plan, puis raccord | 5 s |
| Séquence brute | 15,5 s de film en 1344 × 768 | ≈ 5 min |
Ces temps supposent une LoRA de distillation lightx2v (Apache-2.0) : 4 étapes d'échantillonnage au lieu de 20, sans perte visible. Sans elle, le même plan demanderait six à sept minutes, et la séquence dépasserait l'heure. Publier des temps sans dire ce qui les rend possibles n'aurait pas de sens.
Le son est produit dans la même passe que l'image. Pluie, vent, sirène lointaine, pulsation d'interface : chaque plan porte son propre paysage sonore, écrit avec l'intention. Il n'est pas ajouté après.
Deux traitements d'après-coup. Aucun des deux ne se fait pendant la génération.
Le modèle produit en 1344 × 768 à 24 images/seconde, et ces deux valeurs ne se règlent pas : elles sont ce qu'il sait faire. Tout le reste se gagne ensuite.
| Traitement | Ce qu'il fait | Temps |
|---|---|---|
| Agrandissement | 1344 × 768 → 2520 × 1440, par lots temporels | 1 415 s |
| Fluidification ×4 | 24 → 96 images/seconde, images intercalées | 229 s |
| Finition | sur les 15,5 s de séquence | ≈ 27 min |
L'agrandissement travaille par lots d'images consécutives, pas image par image : c'est ce qui évite le scintillement d'un agrandisseur photo appliqué à une vidéo. Et la fluidification n'accélère rien — la durée est identique à la seconde près, il y a simplement quatre fois plus d'images pour la parcourir.
2520 × 1440 et 96 images/seconde ne sont pas décoratifs. Chacun ouvre un usage — et chacun a son prix.
96 images/seconde
96 est exactement quatre fois 24. Un multiple entier, donc en revenant à la cadence cinéma on ne jette qu'une image sur quatre : aucune image inventée, aucun tremblement.
Concrètement : les 1 485 images relues à 24 i/s donnent 61,9 secondes de ralenti. Les 15,5 s de séquence deviennent une minute entière, quatre fois plus lente, sans rien recalculer.
Coût 3,8 min — soit 15 s de calcul par seconde de film
2520 × 1440
Le rapport 1,75 du natif est conservé au millième : l'agrandissement est homothétique, aucune image n'est étirée ni recadrée. Ce n'est pas du 16/9 — c'est plus large, entre le 16/9 et le scope.
Chaque image passe de 1,03 à 3,63 mégapixels, soit ×3,52. Sur toute la séquence, 5,39 gigapixels ont été calculés.
Coût 23,6 min — soit 91 s de calcul par seconde de film
La fluidité coûte six fois moins cher que la définition. Multiplier les images par quatre se paie en quelques minutes ; multiplier les pixels par trois et demi occupe la machine près d'une demi-heure. Si un seul des deux doit sauter, le choix est vite fait.
Ce qui sort à la fin de la chaîne.
Séquence CIRI-ANDROID · fichier final
| Poste | Temps | Part |
|---|---|---|
| Génération des 3 plans | ≈ 5 min | 16 % |
| Montage | 5 s | < 1 % |
| Agrandissement | 23,6 min | 74 % |
| Fluidification | 3,8 min | 12 % |
| Total machine | ≈ 32 min | 100 % |
Cinq minutes créent le film ; vingt-sept l'habillent. C'est la leçon la plus utile de la séquence : la partie qu'on juge à l'œil est rapide et se refait plan par plan, tandis que la finition est un coût fixe qu'on ne paie qu'une fois, à la toute fin — quand chaque plan a été validé.