HD70X/nxtpath-minimax-video

Nxtpath MiniMax Video

Verwendet den unabhängigen Client scripts/nxtpath_minimax_video.py, festes Gateway https://api.nxtpath.ai/v1, Standardmodell minimax/minimax-h3. Die Parameter richten sich nach dem H3-Kanal von Nxtpath, nicht nach der offiziellen MiniMax-Direktschnittstelle oder Seedance-Parametern. Die überprüfte Schnittstelle und der Validierungsumfang sind in Schnittstellengrundlage dokumentiert.

Konfiguration und Eingabe

• Verwendet den lokalen NXTPATH_API_KEY, Umgebungsvariable hat Vorrang, sonst wird ~/.config/nxtpath/env ausgewertet; NXTPATH_ENV_FILE kann den Dateipfad überschreiben. Liest keine Chat-Anmeldeinformationen von Claude, Codex oder Grok und legt den Schlüssel nicht in der Befehlszeile oder in Aufgabenaufzeichnungen ab.
• Lokalisiert den Client ausgehend vom tatsächlichen Verzeichnis dieses Skills. Bevorzugt ~/.config/nxtpath/venv/bin/python; für Text- oder HTTPS-Bildeingabe wird lediglich Python 3.9+ benötigt. Für lokale Bildbereitstellung wird zusätzlich boto3 aus scripts/requirements.txt benötigt, Konfigurationsdetails siehe Konfiguration und Wiederherstellung.
• Prüft zunächst die Materialien und Datenschutzvereinbarungen des Zielprojekts. Jeder Kandidat verwendet ein neues Aufgabenverzeichnis, standardmäßig im ignorierten tmp/artwork/generations/<run-id>/<asset-id>/<attempt-id>/ des Projekts; ohne Projekt wird ein temporäres Verzeichnis im aktuellen Arbeitsbereich oder ein vom Benutzer angegebener Speicherort verwendet. Überschreibt keine alten Aufgaben oder ersetzt automatisch offizielle Ressourcen.
• Standardmäßig 4 Sekunden, 720p, 16:9. Dauer 4–12 ganze Sekunden, Auflösungen nur 720p / 960p / 2k, Seitenverhältnisse 21:9 / 16:9 / 4:3 / 1:1 / 3:4 / 9:16.
• Drei Eingabemodi: reiner Text; --first-frame und/oder --last-frame jeweils maximal ein Bild; wiederholbare --ref-image normale Referenzbilder. Erste/letzte Frames und normale Referenzbilder können nicht gemischt werden, keine Referenz-Audio- oder -Videodateien. Normale Referenzbilder haben nicht die Rolle eines ersten/letzten Frames.
• Bilder als HTTPS-URLs oder lokale PNG/JPEG/WebP (maximal 20 MiB pro Bild). Data-URLs werden abgelehnt. Zu große Bilder müssen vorher in einer verkleinerten Kopie gespeichert werden, ohne das Original des Benutzers zu ändern.

Erstellung und Wiederherstellung

Wenn der Benutzer explizit die Generierung eines Videos wünscht, wird ein Kandidat abgeschlossen; Batch- und Wiederholungsanzahl folgen dieser Konvention. Nur die Überprüfung der Konfiguration, das Studium der Schnittstelle oder die Erstellung eines Skills berechtigen nicht zur kostenpflichtigen Generierung. Ohne vereinbarte zusätzliche Versuche werden fehlgeschlagene Aufgaben nicht automatisch neu generiert oder das Modell gewechselt.

1. Mit doctor --check-api werden die Anmeldeinformationen, model_available und model_supported schreibgeschützt überprüft; wenn eine der Modellprüfungen false ergibt, wird die Übermittlung gestoppt und das Verzeichnis oder die Konfiguration überprüft.
2. Entsprechend den Benutzeranforderungen werden Aktionen, Kameraeinstellungen, Dauer und beizubehaltende Charaktere/Objekte zusammengestellt und der Prompt in eine UTF-8-Datei geschrieben. Mit prepare werden Prompt, Parameter und Eingabe-Snapshot eingefroren; dieser Befehl wird offline ausgeführt und erzeugt kein Video.
3. Bei lokalen Bildern wird host ausgeführt, das einen konfigurierten privaten R2 verwendet, Inhaltshash-Objekte wiederverwendet, 24-Stunden-GET-Signaturen ausstellt und den Download-Hash überprüft. Dieser Vorgang sendet die Eingabe an R2 und den Videoanbieter; bei Fehlschlag der Bereitstellung wird abgebrochen, ohne automatisch auf ein öffentliches Bildhosting oder Konto zu wechseln. Bei reinem Text oder bereits vorhandenen HTTPS-Bildern kann dieser Schritt übersprungen werden.
4. Einmaliges Ausführen von submit. Es persistiert vor dem kostenpflichtigen POST einen exklusiven Übermittlungsdatensatz mit Idempotenz-Schlüssel; anschließend wird mit einem separaten status abgefragt. Dienststatus: Pending / Running / Success / Failure / Expired. Das Warten erfolgt mit unterbrechbarer Kommunikation des Hosts, nicht mit minutenlangen Schleifen in einem langen Shell-Aufruf.
5. Bei Success wird mit download das MP4 heruntergeladen und validiert. Bei Fehlschlag wird nur der Download wiederholt; Failure / Expired sind Endzustände dieser Aufgabe – das Ergebnis wird gemeldet, es darf deswegen keine neue kostenpflichtige Aufgabe automatisch erstellt werden.
6. Für die Wiederherstellung über Chat-Grenzen hinweg wird der ursprüngliche Job-Pfad verwendet, zuerst inspect, dann status / download. Bei vorhandenem Übermittlungsdatensatz, Zeitüberschreitung, Verbindungsabbruch oder fehlender Aufgaben-ID darf kein erneuter POST erfolgen; bei unklarem Ergebnis muss anhand privater Aufzeichnungen beim Anbieter überprüft werden, kein neuer Versuch zur Umgehung.

Befehlsbeispiele (PY, CLIENT, JOB, PROMPT_FILE und Bildvariablen bezeichnen tatsächliche Pfade; JOB darf noch nicht existieren):

"$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"

Bei nur einem ersten Frame wird --last-frame weggelassen; bei normalen Referenzbildern wird --ref-image anstelle der beiden Frame-Parameter verwendet; bei Text-zu-Video werden alle Bildparameter und host weggelassen. Die lokale NXTPATH_MINIMAX_MODEL oder explizites --model können nur unterstützte H3-IDs auswählen, kein automatischer Fallback auf andere Kanäle.

Auslieferung

Auslieferung eines abspielbaren lokalen video.mp4 und des Aufgabenverzeichnisses, Anzeige des Videos mit absolutem Pfad. Angabe der tatsächlichen Parameter sowie ob Originalgeschwindigkeit, Aktionen und erste/letzte Frames überprüft wurden; HTTP-Erfolg garantiert keine visuelle Qualität oder Charakterkonsistenz. Die Schnittstelle unterstützt erste/letzte Frames, dies bedeutet keine pixelgenaue Garantie; maßgeblich ist das tatsächliche Video.

Prompt, signierte Bild-URLs, Aufgaben-Handle und Antworten werden in für den aktuellen Benutzer lesbaren Aufzeichnungen gespeichert; nicht vollständig in den Chat oder in Git einfügen. Auf der Konsole wird nur der Fingerabdruck des Aufgaben-Handles angezeigt. Der Video-Bearer wird nur an das entsprechende Artefakt-Handle dieses Gateways gesendet; der nachfolgende HTTPS-Medien-Download verwendet anonyme Anfragen.