# Was geschieht bei der Migration einer Sora-App mit Eingabedateien und Ausgabe-URLs? > Dateireferenzen und Videolinks eines Anbieters sind keine portablen Assets. Bewahren Sie Originalbytes unter eigenen Asset-IDs auf, laden Sie sie im Zielformat erneut hoch, ordnen Sie beide Aufträge getrennt zu und kopieren Sie fertige Videos vor Ablauf der Ressourcen in dauerhaften Speicher. Bei einer Sora-Migration müssen Eingabereferenzen meist für den Zielanbieter neu hochgeladen oder formatiert werden, während Video-URLs als temporäre Downloadorte gelten. Stellen Sie eine Asset-Schicht bereit, die dauerhafte Dateien, Prüfsummen, Zugriff und Anbieterzuordnungen verwaltet. Eine kompatible Anfrageform macht Datei-IDs und Ausgabelinks nicht portabel. Diese Ressourcen gehören dem ausstellenden Anbieter. ## Assets von Anbieterreferenzen trennen Verwenden Sie eine anwendungseigene Asset-ID als stabilen Schlüssel: ```json { "asset_id": "asset_01J...", "kind": "input_image", "sha256": "...", "storage_key": "inputs/asset_01J...png", "provider_refs": { "openai": "provider-specific-reference" } } ``` Quell-Datei-ID, Video-Auftrags-ID und signierte URL sind Attribute dieses Datensatzes, keine dauerhaften Produktkennungen. ## Eingabereferenzen neu erstellen Der OpenAI-Video-Endpoint akzeptiert einen Prompt und optional ein `input_reference`-Bild. Das Ziel kann Multipart-Upload, eine vorab geladene Datei-ID, öffentliche URL oder base64-Daten verlangen. Lesen Sie jedes Original aus Ihrem Speicher, prüfen Sie Typ und Abmessungen und erstellen Sie die Zielreferenz. Gehen Sie nicht davon aus, dass eine OpenAI-Kennung bei einem anderen Anbieter funktioniert. Wenn nur eine externe Referenz gespeichert wurde, prüfen Sie ihre Abrufbarkeit. Nach Ablauf oder Löschung muss der Benutzer das Original erneut hochladen; eine ID-Konvertierung stellt keine Bytes wieder her. ## Auftragsobjekte explizit zuordnen Sora-Videogenerierung ist asynchron. Ein Auftrag enthält ID, Status, Fortschritt, Modell, Dauer, Größe, Zeitpunkte und eventuell Ablauf. Speichern Sie den Zielauftrag neben dem Quellauftrag: | Anwendungsfeld | Quellzuordnung | Zielzuordnung | |---|---|---| | Interne Auftrags-ID | Ihre Datenbank | Derselbe Wert | | Anbieter-Auftrags-ID | OpenAI-Video-ID | Ziel-Auftrags-ID | | Status | Quellstatus | Normalisierter Zielstatus | | Eingabe-Asset | Quellreferenz | Neu geladene Zielreferenz | | Ausgabe-Asset | Heruntergeladene Bytes | Zielbytes | Überschreiben Sie während der schrittweisen Migration nicht die Quellzuordnung. Beide Zuordnungen ermöglichen Rollback und Support. ## Inhalte statt nur URLs herunterladen Die OpenAI API bietet einen Content-Endpoint für fertige Videos und meldet bei Ablauf `expires_at`. Eine kopierte URL kann auslaufen, Authentifizierung verlangen oder für Clients ungeeignet sein. Nach Abschluss sollte der Worker: 1. den Inhalt vom authentifizierten Endpoint abrufen; 2. ihn in eigenen Objektspeicher streamen; 3. Typ, Größe und Prüfsumme prüfen; 4. Herkunft, Modell, Prompt-Richtlinie und Parameter speichern; 5. ihn über eine autorisierte Anwendungs-URL ausliefern. Wenden Sie dies auch auf Vorschaubilder und andere benötigte Varianten an. ## Aufbewahrung und Datenschutz planen Das Kopieren von Dateien ändert den Governance-Umfang. Definieren Sie getrennte Fristen für Uploads, Zwischenprodukte, fertige Videos, Vorschaubilder und Fehler. Verschlüsseln Sie Assets, begrenzen Sie Dienstrollen und protokollieren Sie keine signierten URLs oder Rohprompts. Löschen Sie auf Anfrage die Anwendungskopie und rufen Sie, falls verfügbar, den Anbieter-Endpoint auf. Bewahren Sie einen nicht sensiblen Löschmarker für idempotente Wiederholungen auf. ## Medienverhalten vor der Umschaltung testen Erstellen Sie Fälle für Formate, Ausrichtungen, Auflösungen, Dauern und Maximalgrößen. Prüfen Sie bei Bedarf Alpha und Farbprofile. Testen Sie abgelaufene Links, Teil-Downloads, falsche Inhaltstypen, Range-Anfragen, Abbruch und Wiederaufnahme nach Worker-Ausfall. Vergleichen Sie auch Inhalts- und Moderationsregeln. Das Akzeptieren derselben Form garantiert nicht dasselbe Ergebnis. ## Fazit Sora-Referenzen und Ausgabe-URLs sind Anbieterressourcen, keine portablen Assets. Bewahren Sie Originale auf, erstellen Sie neue Referenzen, laden Sie fertige Videos umgehend herunter und zeigen Sie eigene Asset-IDs, damit ablaufende Links nicht zu Datenverlust führen. ## FAQ ### Kann eine OpenAI-input_reference an einen anderen Videoanbieter gesendet werden? Meist nicht. Lesen Sie das Original aus Ihrem Speicher und erstellen Sie den vom Ziel verlangten Multipart-Upload, die Datei-ID, URL oder base64-Referenz. ### Sind Sora-Ausgabe-URLs dauerhaft? Behandeln Sie sie als temporäre oder authentifizierte Lieferorte. Der Auftrag kann ein Ablaufdatum enthalten, daher sollten Sie den Inhalt schnell in eigenen Speicher laden. ### Was ist zu tun, wenn nur eine Anbieter-Datei-ID gespeichert wurde? Versuchen Sie die Originalbytes abzurufen, solange die Ressource verfügbar ist. Nach Ablauf oder Löschung muss der Benutzer das Original eventuell erneut hochladen. ### Welche ID sollte die Anwendung anzeigen? Zeigen Sie eigene stabile Asset- und Auftrags-IDs. Bewahren Sie Quell- und Zielanbieter-IDs als Zuordnungen für Abruf, Support und Rollback auf. ### Soll die Quellzuordnung nach der Umschaltung überschrieben werden? Nein. Behalten Sie während der schrittweisen Migration beide Zuordnungen, damit Sie Verhalten vergleichen und zurückrollen können. ### Was muss bei Video-Assets getestet werden? Testen Sie alle Formate, Größen, Dauern, Ausrichtungen und Varianten sowie Ablauf, Teil-Downloads, Abbruch und Speicherwiederholungen.