ouxxyy/codex-gif-video

Codex GIF Vidéo

Utilisation et choix de sortie

Ce Skill est spécialement conçu pour produire des assets visuels destinés à un montage ultérieur, sans ajouter de sous-titres, titres, étiquettes textuelles, filigranes, musique, voix off ou effets sonores. Les textes de narration sont utilisés uniquement pour comprendre les actions et décomposer les plans, ils ne sont pas transformés en sous-titres ou en son. Les exigences concernant le son, les sous-titres et la production de longs métrages dans la documentation de style en amont ne sont pas des instructions à exécuter pour ce Skill.

L'utilisateur peut choisir :

• GIF court original : Chaque plan conserve les octets originaux retournés par le service ainsi que leur liste.
• Un long GIF : Assemble plusieurs plans valides dans l'ordre en un seul fichier .gif ; pas de boucle de remplissage, lecture complète une seule fois.
• Format vidéo : Enregistré en .mp4 (H.264/yuv420p), contient uniquement le flux vidéo, muet, sans sous-titres.
• Les deux : Réutilise les mêmes plans pour exporter à la fois le long GIF et le MP4, sans régénérer les plans.

Respecter le choix explicite de l'utilisateur ; dire "fais un GIF" produit un GIF, "format vidéo" produit un MP4. Par défaut, si rien n'est spécifié, fournir un asset GIF et mentionner l'option MP4. Lorsque la durée cible dépasse la capacité d'un seul plan, décomposer d'abord en plusieurs plans, puis exporter un seul fichier long, ne pas fournir uniquement des fragments. Voir flux d'exportation.

Limites de génération et point d'entrée

La source d'images animées n'accepte que les GIF que le modèle peut retourner nativement. Utiliser l'outil natif de la session Codex en cours, ou l'API OpenAI Image officielle déjà sélectionnée par l'utilisateur ; ne pas utiliser de proxy tiers, d'autres modèles d'image/vidéo, d'assemblage d'images statiques, d'animations par code, d'I2V ou d'interpolation pour imiter une animation native. Conserver le GIF original et la preuve de chaque requête, sans modifier la vitesse, répéter en boucle ou figer une image pour atteindre la durée.

L'assemblage du long GIF, l'encodage MP4 et la mise à l'échelle proportionnelle sont des exportations dérivées, ils ne peuvent pas être considérés comme une génération native unique du modèle et n'ajoutent pas de véritables images de mouvement. Le ré-encodage GIF peut entraîner des changements de palette ; privilégier la taille source. Pour les longs contenus, le MP4 peut être choisi pour réduire le volume.

Priorité d'entrée : instruction explicite de ce tour → preferred_entry dans le fichier de configuration privé du projet codex-gif-video.config.json → session Codex. Conserver la sélection déjà sauvegardée. En cas d'échec de l'entrée native, ne pas basculer automatiquement vers une API payante. credential_file et budget_file sont relatifs à la racine du projet ; les clés ne doivent pas apparaître dans le Skill, les invites ou les journaux.

Pour l'API officielle, lire d'abord official-api.md, utiliser official_api.py ; ignorer la vérification du commutateur gif de Codex. Pour le mode Codex, exécuter d'abord native_gif.py doctor et vérifier le schéma réel de l'outil de cette session : le champ gif doit être présent, ne pas envoyer de sonde statique prompt-only, ne pas inventer de paramètres. Diagnostic voir native-entry.md. Le modèle et les capacités GIF sont limités par le compte et la portée d'ouverture du service.

Un même lot d'autorisation partage un budget commun, par défaut 8 requêtes GIF maximum, 3 requêtes de référence ; les échecs et les timeouts comptent également. Pour une nouvelle tâche ou une refonte explicite, un budget indépendant peut être créé, avec enregistrement du nombre prévu et conservation de l'ancien budget. Ne pas effacer les crédits pour contourner les échecs ; une nouvelle tentative doit être explicitement relancée, tout changement d'invite, paramètre ou référence doit créer un nouveau bundle.

Du besoin au plan

1. Lire le protocole d'appel, décomposer l'objectif en shots, chaque plan ayant un "état initial → action → état final" clairs. Conserver le texte de narration original, ne pas inventer de timestamp audio ; pour les segments répétés, fournir la position des caractères.
2. Déterminer le format de sortie, le rapport hauteur/largeur et la durée totale. prepare convertit le ratio en pixels : par défaut 9:16→288×512, 16:9→512×288, 1:1→512×512 ; ce sont des valeurs locales prudentes par défaut, pas une limite du service. Des dimensions respectant les limites de pixels du service et étant multiples de 16 peuvent être spécifiées explicitement.
3. Durée exacte par défaut. Si frame_count est omis, choisir automatiquement un schéma dont le nombre d'images (2–16) divise la durée cible ; si un nombre d'images explicite est incompatible, signaler une erreur avant génération. Utiliser duration_policy:quantize uniquement si l'approximation est explicitement acceptée, et divulguer l'erreur. 15 secondes peuvent être planifiées comme 5 segments × 3 secondes × 15 images, chaque image durant 200 ms ; ne pas décrire 16 images × 310 ms comme 5 secondes. Une faible fréquence d'images convient aux actions simples, sans garantie de fluidité cinématographique.
4. Recommander un style, comparer les candidats, puis exécuter style_router.py guide --style ID pour lire le texte complet du style sélectionné. Vérifier les matériaux, personnages, couleurs, actions, mouvements de caméra et tabous visuels ; ignorer les exigences en amont concernant les sous-titres, le son, ou les moteurs de code. Voir styles.md.
5. Si une cohérence des personnages entre les plans est nécessaire mais qu'aucune référence principale n'est fournie par l'utilisateur, utiliser style_router.py reference-prompt --style ID --subject-file FILE pour générer un plan d'invite de référence principale, puis appeler le modèle autorisé. D'abord examiner la référence principale réelle, puis pour chaque plan la réutiliser et verrouiller les caractéristiques du personnage ainsi que style_lock ; ne pas remplacer les résultats dérivés par la référence principale.
6. Écrire la requête JSON, prepare fige l'invite, les dimensions, le plan temporel, le hash du texte du style et la référence. Avant génération, vérifier les paramètres et la durée totale. Les changements de requête utilisent un nouveau répertoire, ne pas écraser les anciens résultats.

Génération et preuves de source

Mode officiel : prepare → official_api.py generate, ne pas appeler native-request pour une double réservation. Une fois le premier plan reçu avec un vrai GIF multi-images, des paramètres techniques conformes et des preuves de source suffisantes, continuer ; en cas d'erreur de taille, nombre d'images ou de format, localiser d'abord le problème sans relancer aveuglément l'ensemble du groupe.

Mode Codex : prepare → native-request → selon le schéma réel, appeler l'outil natif (en conservant gif) → import-native. Si aucun fichier n'est produit, utiliser finish-attempt pour enregistrer un échec ou un état inconnu. Ne pas considérer model/size/output_format non exposés comme des champs d'outil.

• model_evidence.reported_model enregistre uniquement le modèle réellement retourné par le service ; s'il manque, laisser null, ne pas deviner le modèle.
• Une requête officielle peut utiliser un endpoint HTTPS officiel fixe, un modèle explicitement autorisé, pas de redirection, réponse 200, un ID de requête et un hash de requête constituant official_request_evidence. Cela prouve la source de la requête officielle, mais n'équivaut pas à une auto-déclaration du modèle par le service.
• Même si la source Codex est inconnue, l'accusé de réception officiel est incomplet, ou le rapport de modèle est conflictuel, la validation ne peut pas passer. Les valeurs historique unknown/unverified ne sont pas automatiquement réécrites.

Vérification et livraison

Lire quality.md. Les vérifications techniques prouvent uniquement le format, les dimensions, le nombre d'images, le délai, le décodage et les variations de pixels ; elles ne peuvent pas prouver le naturel du mouvement. Vérifier réellement toutes les images et la lecture complète à vitesse normale, en enregistrant séparément l'identité, le style, la structure, le mouvement, la sémantique, la boucle, et clean_visual (pas de sous-titres ni de calque de texte superposé). Si Jev est disponible, utiliser le vrai échantillonnage d'images et la référence principale ; l'échantillonnage d'images statiques et la plage de lecture complète sont enregistrés séparément.

review est lié au hash du fichier original ; ce n'est qu'après que tous les critères de qualité sont satisfaits que l'on peut export vers ready_gif_assets. Les exportations dérivées ne consomment par défaut que les packages prêts (ready). Si la qualité technique et la source sont conformes mais que la vérification de lecture complète manque, un --review-copy peut être explicitement utilisé pour créer un fichier en attente de révision, en conservant rendered_pending_review et les éléments manquants ; un échec visuel clair ne peut pas être autorisé via le mode d'attente de révision.

Selon le choix de l'utilisateur, appeler compose_movie.py --out assets.gif ou --out assets.mp4, en supportant une liste de plans provenant d'un seul bundle ou de plusieurs bundles. Utiliser un seul cycle par plan, en conservant la vitesse d'origine ; ne pas ajouter de sous-titres ni de son. L'exportation MP4 impose un seul flux vidéo ; le long GIF vérifie le délai total réel, les dimensions, l'ordre et la lecture unique. Les deux nécessitent une vérification de l'image réelle ; la vérification du flux ne peut pas détecter le texte incrusté dans l'image.

Livrer les fichiers choisis, les GIF originaux, la liste des sources, l'accusé de réception du rendu et la portée de vérification restante. Conserver les résultats historiques et les versions corrigées traçables. Si le chemin d'installation est un lien symbolique, mettre à jour le répertoire source ; l'archivage exclut les clés et les artefacts d'exécution.