HD70X/nxtpath-minimax-video

哪都通 MiniMax Vidéo

Utilise le client autonome scripts/nxtpath_minimax_video.py, passerelle fixe https://api.nxtpath.ai/v1, modèle par défaut minimax/minimax-h3. Les paramètres sont basés sur le canal H3 de 哪都通, sans utiliser l'interface directe officielle de MiniMax ni les paramètres Seedance. Les interfaces vérifiées et leur périmètre de validation sont détaillés dans Références API.

Configuration et entrée

• Réutilise la clé NXTPATH_API_KEY de la machine, la variable d'environnement est prioritaire, sinon lit ~/.config/nxtpath/env ; NXTPATH_ENV_FILE peut surcharger le chemin du fichier. Ne lit pas les identifiants de chat de Claude, Codex ou Grok, ne place pas la clé dans la ligne de commande ni dans les enregistrements de tâches.
• Se positionne à partir du répertoire réel de cette skill. Privilégie ~/.config/nxtpath/venv/bin/python ; seules les entrées texte ou images HTTPS nécessitent Python 3.9+. L'hébergement d'images locales nécessite également boto3 dans scripts/requirements.txt, la configuration est décrite dans Configuration et reprise.
• Lit d'abord les conventions de contenu et de confidentialité du projet cible. Chaque candidature utilise un nouveau répertoire de tâche, placé par défaut dans le répertoire ignoré du projet tmp/artwork/generations/<run-id>/<asset-id>/<attempt-id>/ ; en l'absence de projet, utilise le répertoire temporaire de l'espace de travail courant ou un emplacement spécifié par l'utilisateur. N'écrase pas les anciennes tâches et ne remplace pas automatiquement les ressources officielles.
• Par défaut, l'échantillon est de 4 secondes, 720p, 16:9. La durée est un entier entre 4 et 12 secondes, les résolutions sont uniquement 720p / 960p / 2k, les formats sont 21:9 / 16:9 / 4:3 / 1:1 / 3:4 / 9:16.
• Trois types d'entrée : texte uniquement ; --first-frame et/ou --last-frame (au maximum une image chacun) ; --ref-image pour des images de référence ordinaires, répétable. Les images de début/fin et les images de référence ordinaires ne peuvent pas être mélangées. Les références audio ou vidéo ne sont pas prises en charge. Les images de référence ordinaires n'ont pas le rôle d'images de début/fin.
• Les images utilisent une URL HTTPS, ou des PNG/JPEG/WebP locaux (chaque image au maximum 20 MiB). Les data URL sont refusées. Les images trop grandes doivent d'abord être réduites dans une copie, sans modifier l'image originale de l'utilisateur.

Génération et reprise

Lorsque l'utilisateur demande explicitement la génération d'une vidéo, une candidature est complétée ; les lots et les reprises suivent les règles définies. La simple vérification de la configuration, l'étude de l'interface ou la création de la skill n'autorisent pas une génération payante. Sans tentative supplémentaire convenue, ne régénère pas automatiquement les tâches échouées et ne change pas de modèle.

1. Utiliser doctor --check-api pour vérifier en lecture seule les identifiants, model_available et model_supported ; si l'une des vérifications de modèle est fausse, arrêter la soumission, vérifier le répertoire ou la configuration.
2. Organiser les actions, plans, durée et les personnages/objets à conserver selon les demandes de l'utilisateur, écrire le prompt dans un fichier UTF-8. Utiliser prepare pour figer le prompt, les paramètres et l'instantané d'entrée ; cette commande s'exécute hors ligne, sans générer de vidéo.
3. En présence d'images locales, exécuter host, utiliser le R2 privé configuré, réutiliser les objets basés sur le hachage du contenu, émettre un GET de 24 heures et vérifier le hachage du téléchargement. Cette opération transmet les entrées au R2 et au fournisseur vidéo ; en cas d'échec d'hébergement, arrêter sans basculer automatiquement vers un hébergement public ou un autre compte. Les entrées texte uniquement ou les images HTTPS existantes peuvent sauter cette étape.
4. Exécuter une fois submit. Avant le POST payant, il persiste un enregistrement de soumission exclusif et une clé d'idempotence ; puis interroge avec un status indépendant. Les états du service sont Pending / Running / Success / Failure / Expired. L'attente utilise l'interruption possible de l'hôte et maintient la communication sur la progression, sans boucler plusieurs minutes dans un appel shell long.
5. En cas de Success, utiliser download pour télécharger et vérifier le MP4. En cas d'échec du téléchargement, ne réessayer que le téléchargement ; Failure / Expired sont des états finaux de la tâche, rapporter le résultat, sans créer automatiquement une nouvelle tâche payante.
6. Pour une reprise inter-conversation, utiliser le chemin du job original, d'abord inspect, puis status / download. En présence d'un enregistrement de soumission, d'un délai d'attente, d'une déconnexion ou d'un identifiant de tâche manquant, ne pas refaire un POST ; en cas de résultat incertain, vérifier auprès du fournisseur selon les enregistrements privés, sans utiliser une nouvelle tentative pour contourner.

Exemples de commandes (PY, CLIENT, JOB, PROMPT_FILE et les variables d'image désignent des chemins réels ; JOB ne doit pas encore exister) :

"$PY" "$CLIENT" doctor --check-api
"$PY" "$CLIENT" prepare --job "$JOB" --prompt-file "$PROMPT_FILE" --first-frame "$FIRST_FRAME" --last-frame "$LAST_FRAME" --duration 4 --resolution 720p --ratio 16:9
"$PY" "$CLIENT" host --job "$JOB"
"$PY" "$CLIENT" submit --job "$JOB"
"$PY" "$CLIENT" status --job "$JOB"
"$PY" "$CLIENT" download --job "$JOB"

En cas de première image uniquement, omettre --last-frame ; pour les images de référence ordinaires, utiliser --ref-image à la place des deux paramètres d'image ; pour la génération texte-vers-vidéo, omettre tous les paramètres d'image et host. La variable locale NXTPATH_MINIMAX_MODEL ou l'option explicite --model ne peuvent sélectionner que les ID H3 pris en charge, sans basculer automatiquement vers un autre canal.

Livraison

Livrer la vidéo locale lisible video.mp4 et le répertoire de la tâche, en affichant la vidéo avec un chemin absolu. Expliquer les paramètres réels, et si la vitesse originale, les actions et le début/fin ont été vérifiés ; un succès HTTP ne prouve pas la qualité visuelle ni la cohérence des personnages. L'interface prend en charge les images de début/fin mais ne garantit pas une conformité pixel par pixel ; le résultat est basé sur la vidéo réelle.

Le prompt, les URL des images signées, le handle de la tâche et les réponses sont conservés dans des enregistrements lisibles uniquement par l'utilisateur actuel ; ne pas les coller en entier dans le chat ou les soumettre à Git. La console affiche uniquement l'empreinte du handle de la tâche. Le Bearer de la vidéo est envoyé uniquement au handle d'artefact correspondant de cette passerelle ; le téléchargement média HTTPS après redirection utilise des requêtes anonymes.