ouxxyy/codex-gif-video

Codex GIF Video

Verwendung und Ausgabeoptionen

Dieses Skill erstellt speziell visuelles Material für die spätere Nachbearbeitung. Es werden keine Untertitel, Titel, Textlabels, Wasserzeichen, Musik, Sprachausgabe oder Soundeffekte hinzugefügt. Sprechtext wird nur zum Verständnis der Aktionen und zur Aufteilung in Shots verwendet, nicht zur Erstellung von Untertiteln oder Ton. Anforderungen aus der übergeordneten Stilvorlage bezüglich Ton, Untertiteln und Langfilm-Erstellung sind keine auszuführenden Anweisungen dieses Skills.

Der Benutzer kann wählen:

• Originale kurze GIFs: Jeder Shot wird mit den vom Dienst zurückgegebenen Original-Bytes und einer Quellenliste gespeichert.
• Ein langes GIF: Mehrere qualifizierte Shots werden der Reihe nach zu einer einzigen .gif-Datei zusammengefügt; keine Schleifenauffüllung, einmalige vollständige Abspielung.
• Videoformat: Speicherung als .mp4 (H.264/yuv420p), nur Videostream, stumm, ohne Untertitel.
• Beides: Dieselben Shots werden sowohl für das lange GIF als auch für das MP4 verwendet, ohne die Shots erneut zu generieren.

Die vom Benutzer getroffene Wahl wird übernommen; wenn der Benutzer nur "GIF machen" sagt, wird ein GIF ausgegeben, bei "Videoformat" ein MP4. Wenn nichts angegeben ist, wird standardmäßig GIF-Material ausgegeben und auf die MP4-Option hingewiesen. Wenn die Zieldauer die Fähigkeiten eines einzelnen Shots übersteigt, wird der Vorgang zuerst in mehrere Shots aufgeteilt und dann eine lange Datei exportiert, es dürfen keine unzusammenhängenden Fragmente abgegeben werden. Siehe Export-Workflow.

Generierungsgrenzen und Einstieg

Als dynamische Bildquelle werden nur GIFs akzeptiert, die das Modell nativ zurückgeben kann. Verwendet werden die nativen Tools der aktuellen Codex-Sitzung oder die vom Benutzer ausgewählte offizielle OpenAI Image API. Keine Nutzung von Drittanbieter-Proxys, anderen Bild-/Videomodellen, statischen Einzelbild-Zusammenstellungen, Code-Animationen, I2V oder Frame-Interpolation, um native Animationen vorzutäuschen. Die Original-GIFs und jeder Nachweis einer Anfrage werden aufbewahrt. Es wird nicht die Geschwindigkeit verändert, keine Wiederholungsschleifen eingefügt oder Standbilder zur Verlängerung der Dauer verwendet.

Das Zusammenfügen langer GIFs, die MP4-Kodierung und die proportionale Skalierung sind abgeleitete Exporte und werden nicht als einmalige native Generierung des Modells bezeichnet. Sie fügen auch keine echten Bewegungsframes hinzu. Bei der Neukodierung von GIFs kann es zu Änderungen der Palette kommen; nach Möglichkeit wird die Originalgröße beibehalten. Bei langen Inhalten kann optional MP4 gewählt werden, um die Dateigröße zu reduzieren.

Priorität für den Einstieg: Explizite Anweisung dieser Runde → preferred_entry aus dem projekteigenen codex-gif-video.config.json → Codex-Sitzung. Bereits gespeicherte Einstellungen werden übernommen; bei Fehlschlag des nativen Einstiegs wird nicht automatisch auf die kostenpflichtige API umgeschaltet. credential_file und budget_file sind relativ zum Projektstammverzeichnis; Schlüssel gelangen nicht in das Skill, in Prompts oder Logs.

Für die offizielle API zuerst official-api.md lesen, dann official_api.py verwenden; die Codex-GIF-Schalterprüfung wird übersprungen. Im Codex-Modus zuerst native_gif.py doctor ausführen und das tatsächliche Tool-Schema dieser Sitzung prüfen: Es muss ein gif-Feld enthalten, es wird keine prompt-only statische Sonde gesendet, und es werden keine Parameter erfunden. Diagnose siehe native-entry.md. Modell- und GIF-Fähigkeiten unterliegen den Beschränkungen des Kontos und der serverseitigen Freigabe.

Innerhalb derselben Autorisierungs-Charge wird das Budget gemeinsam genutzt. Standardmäßig maximal 8 GIF-Anfragen und 3 Referenzanfragen; Fehlschläge und Zeitüberschreitungen werden ebenfalls gezählt. Für neue Aufgaben oder explizite Neuanfertigungen kann ein separates Konto eingerichtet werden, das die geplante Anzahl erfasst und das alte Konto aufbewahrt. Das Löschen von Kontingenten zur Umgehung von Fehlschlägen ist nicht erlaubt; neue Versuche müssen explizit wiederholt werden, und bei Änderungen von Prompt, Parametern oder Referenzen muss ein neues Bundle erstellt werden.

Von der Anforderung zum Shot

1. Protokoll lesen, das Ziel in shots aufteilen, jeder Shot mit klarem „Anfangszustand → Aktion → Endzustand“. Sprechtext wird im Original belassen, keine erfundenen Audio-Zeitstempel; bei wiederholten Segmenten werden Zeichenpositionen angegeben.
2. Ausgabeformat, Seitenverhältnis und Gesamtdauer festlegen. prepare setzt das Seitenverhältnis in Pixel um: Standard 9:16 → 288×512, 16:9 → 512×288, 1:1 → 512×512; dies sind lokale konservative Vorgaben, keine Dienstobergrenzen. Explizit angegebene Abmessungen, die ein Vielfaches von 16 und innerhalb der Dienstpixellimits liegen, sind möglich.
3. Standardmäßig genaue Dauer. Wenn frame_count weggelassen wird, wird automatisch ein Schema innerhalb von 2–16 Frames gewählt, das die Zieldauer ganzzahlig teilt; explizite Frames, die inkompatibel sind, führen zu einem Fehler vor der Generierung. Nur bei expliziter Akzeptanz von Näherungswerten wird duration_policy:quantize gesetzt und die Abweichung offengelegt. 15 Sekunden können als 5 Segmente × 3 Sekunden × 15 Frames mit 200 ms pro Frame geplant werden; 16 Frames × 310 ms können nicht als 5 Sekunden bezeichnet werden. Niedrige Bildraten eignen sich für einfache Aktionen, garantieren keine filmische Flüssigkeit.
4. Stilempfehlung aussprechen, Kandidaten vergleichen und style_router.py guide --style ID ausführen, um den vollständigen Originaltext des ausgewählten Stils zu lesen. Materialien, Figuren, Farbpalette, Aktionen, Kameraführung und visuelle Tabus prüfen; Anforderungen an Untertitel, Ton und Code-Engine aus der übergeordneten Vorlage ignorieren. Siehe styles.md.
5. Wenn über mehrere Shots hinweg Figurenkonsistenz erforderlich ist, aber keine Benutzer-Hauptreferenz vorliegt, mit style_router.py reference-prompt --style ID --subject-file FILE einen Hauptreferenz-Prompt-Plan erstellen und dann das Modell aufrufen. Zuerst die tatsächliche Hauptreferenz ansehen, dann für jeden Shot die Figurenmerkmale und style_lock wiederverwenden und fixieren; Drift-Ergebnisse nicht durch die Hauptreferenz ersetzen.
6. Anfrage-JSON schreiben, prepare fixiert Prompt, Abmessungen, Zeitplan, Hash des Stil-Originals und Referenzen. Vor der Generierung Parameter und Gesamtdauer prüfen. Änderungen an der Anfrage erfolgen in einem neuen Verzeichnis, alte Ergebnisse werden nicht überschrieben.

Generierung und Quellnachweise

Offizieller Modus: prepare → official_api.py generate, native-request wird nicht aufgerufen, um doppelte Reservierungen zu vermeiden. Erst nachdem der erste Shot ein echtes Multi-Frame-GIF erhalten hat, die technischen Parameter stimmen und ausreichende Quellnachweise vorliegen, wird fortgefahren; bei Fehlern in Größe, Framerate oder Format wird zuerst lokalisiert, nicht blind die gesamte Gruppe wiederholt.

Codex-Modus: prepare → native-request → entsprechend dem tatsächlichen Schema das native Tool aufrufen (mit gif-Feld) → import-native. Wenn keine Datei vorhanden ist, mit finish-attempt Fehlschlag oder Unbekannt vermerken. Nicht verfügbare model/size/output_format nicht als Tool-Felder ausgeben.

• model_evidence.reported_model erfasst nur die vom Dienst tatsächlich zurückgemeldeten Daten; fehlt dieser, bleibt null, es wird kein Modell erraten.
• Offizielle Anfragen können mit einem festen offiziellen HTTPS-Endpunkt, explizit erlaubtem Modell, ohne Weiterleitung, 200-Antwort, Request-ID und Request-Hash als official_request_evidence belegt werden. Dies belegt die Herkunft der offiziellen Anfrage, ist aber nicht gleichbedeutend mit einer Eigenauskunft des Dienstes über das ausgeführte Modell.
• Codex-Quellen unbekannt, offizielle Quittung unvollständig, widersprüchliche Modellberichte führen weiterhin zur Ablehnung. Historische „unknown/unverified“-Einträge werden nicht automatisch überschrieben.

Prüfung und Auslieferung

quality.md lesen. Technische Prüfungen belegen nur Format, Größe, Framerate, Verzögerung, Dekodierung und Pixelveränderungen; sie belegen keine natürliche Bewegung. Tatsächliche Prüfung umfasst die vollständige Abspielung aller Frames bei normaler Geschwindigkeit, getrennte Erfassung von Identität, Stil, Struktur, Bewegung, Semantik, Schleifenverhalten und clean_visual (keine Untertitel oder überlagerter Text). Wenn verfügbar, mit Jev echte Frame-Extraktion und Hauptreferenz verwenden; statische Frame-Extraktion und vollständiger Abspielbereich werden getrennt erfasst.

review bindet den Hash der Originaldatei; erst wenn alle Qualitätsanforderungen erfüllt sind, wird export als ready_gif_assets durchgeführt. Abgeleitete Exporte verwenden standardmäßig nur fertige Pakete. Wenn technische und Quellprüfungen bestehen, aber die vollständige Abspielprüfung fehlt, kann explizit --review-copy verwendet werden, um eine überprüfungsbedürftige Datei zu erstellen, wobei rendered_pending_review und die fehlenden Prüfpunkte erhalten bleiben; eindeutige visuelle Fehlschläge können nicht über den Prüfmodus durchgewunken werden.

Je nach Benutzerwahl compose_movie.py --out assets.gif oder --out assets.mp4 aufrufen; unterstützt wird eine Shot-Liste aus einem einzelnen Bundle oder mehreren Bundles. Es wird nur ein Zyklus pro Shot verwendet, die Originalgeschwindigkeit bleibt erhalten; keine Untertitel oder Ton werden hinzugefügt. Der MP4-Export erzwingt, dass nur ein einziger Videostream vorhanden ist; bei langen GIFs werden tatsächliche Gesamtverzögerung, Abmessungen, Reihenfolge und einmalige Abspielung überprüft. Beide erfordern eine Prüfung des tatsächlichen Bildes; eine Stream-Prüfung kann nicht feststellen, ob Text in das Bild eingebrannt ist.

Ausgeliefert werden: die ausgewählte Datei, Original-GIFs, die Quellenliste, der Rendering-Beleg und der verbleibende Prüfumfang. Historische Ergebnisse und korrigierte Versionen bleiben nachvollziehbar. Wenn der Installationspfad ein symbolischer Link ist, wird das Quellverzeichnis aktualisiert; beim Packen werden Schlüssel und Laufzeitausgaben ausgeschlossen.