Wie füge ich Animationen oder Videos zu meinen NFT-Metadaten hinzu?

Medienformatanforderungen für NFT-Metadaten

1. Das Feld „animation_url“ in ERC-721- oder ERC-1155-Metadaten muss auf einen öffentlich zugänglichen HTTP(S)-Endpunkt verweisen, nicht auf rohe IPFS- oder Arweave-URIs wie ipfs://QmXyZ... oder ar://abc123 .

2. Zu den gültigen Videoformaten gehören .mp4 , .webm und .mov ; GIFs werden akzeptiert, bei großen Assets wird jedoch aufgrund von Größenineffizienz und Wiedergabebeschränkungen davon abgeraten.

3. Nur-Audio-NFTs erfordern .mp3- , .wav- oder .ogg- Dateien, die über HTTPS bereitgestellt werden, mit expliziten MIME-Typdeklarationen in Antwortheadern.

4. Alle Mediendateien müssen weniger als 100 MB groß sein, um eine zuverlässige On-Chain-Indizierung durch große Marktplätze wie OpenSea und Blur zu ermöglichen.

5. Dateiabmessungen und Seitenverhältnisse sollten den plattformspezifischen Anzeigebeschränkungen entsprechen – OpenSea erzwingt eine maximale Breite von 3200 Pixeln für Videos, die in Sammlungsvorschauen gerendert werden.

Gateway-Konvertierungsregeln

1. IPFS-Links müssen mithilfe vertrauenswürdiger öffentlicher Gateways neu geschrieben werden: ipfs://QmXyZ... wird zu https://ipfs.io/ipfs/QmXyZ... oder https://cloudflare-ipfs.com/ipfs/QmXyZ... .

2. Arweave-Identifikatoren müssen https://arweave.net/ vorangestellt werden; Es dürfen keine abschließenden Schrägstriche oder Abfrageparameter angehängt werden.

3. Private Gateways wie Pinata oder Infura erfordern Authentifizierungstoken und sind für unveränderliche Metadaten ungeeignet, es sei denn, das Token ist in die URL eingebettet – eine Praxis, von der aufgrund des Sperrrisikos dringend abgeraten wird.

4. Gateway-Fallback-Logik sollte niemals clientseitig implementiert werden; Metadaten müssen ohne JavaScript-Eingriff eindeutig aufgelöst werden.

5. Antworten von Gateways müssen gültige Content-Type- Header zurückgeben, die der Dateierweiterung entsprechen – z. B. video/mp4 für MP4-Dateien –, um Darstellungsfehler bei Wallets und Explorern zu verhindern.

Best Practices für das HTML-Rendering

1. Verwendung Tags ausschließlich für Videoinhalte, mit obligatorischen Steuerelementen , Schleifen- und stummgeschalteten Attributen, um die Autoplay-Kompatibilität in Chrome, Safari und MetaMask Mobile sicherzustellen.

2. Vermeiden Sie das Einbetten von Medien über oder Drittanbieter – diese brechen die deterministische Überprüfung und verstoßen gegen die Metadatenvalidierungsrichtlinie von OpenSea.

3. Geben Sie immer die Breiten- und Höhenattribute an Und Elemente, um Layoutverschiebungen beim verzögerten Laden zu verhindern.

4. Verlassen Sie sich nicht auf die Inline-Base64-Codierung für Videos – sie verstößt gegen Größenbeschränkungen, erhöht die JSON-Aufblähung und verhindert Streaming oder teilweise Downloads.

5. Stellen Sie Medien über HTTP/2 oder HTTP/3 mit geeigneten Caching-Headern bereit ( Cache-Control: public, max-age=31536000 ), um wiederholte Gateway-Anfragen bei Mints mit hohem Datenverkehr zu reduzieren.

Handhabung von Animationen auf Vertragsebene

1. Im Ethereum-Mainnet muss die tokenURI()- Funktion einen statischen JSON-String zurückgeben, der das Feld „animation_url“ enthält – die dynamische Auflösung über Off-Chain-Oracles wird von Indexern nicht unterstützt.

2. Überprüfen Sie bei L2-Ketten wie Optimism oder Base, ob der ausgewählte RPC-Knoten die domänenübergreifende Medienauflösung unterstützt. Einige Knoten entfernen nicht standardmäßige Antwortheader, die für das Videostreaming erforderlich sind.

3. Wenn Sie die Bereitstellung über Minting-Tools von Drittanbietern wie Manifold Studio oder Thirdweb durchführen, überprüfen Sie, ob das Tool ipfs:// zum Zeitpunkt des Hochladens automatisch in Gateway-URLs konvertiert – oder ob eine manuelle Transformation erforderlich ist, bevor Sie die Metadaten-CID finalisieren.

4. Speichern Sie niemals Animationslogik im Smart-Contract-Bytecode. Animationen sind reine Off-Chain-Präsentationsprobleme und haben keinen Einfluss auf die Eigentumsüberprüfung oder Übertragungssemantik.

5. Wenn Sie dezentrale Speicheranbieter verwenden, heften Sie zuerst die Animationsdatei an, generieren Sie dann das Metadaten-JSON und heften Sie dann das JSON selbst an. Wenn Sie diese Reihenfolge umkehren, besteht die Gefahr fehlerhafter Referenzen, wenn die Animationsdatei vor der endgültigen Festlegung der Metadaten-CID gelöst wird.

Häufig gestellte Fragen

F: Kann ich YouTube- oder Vimeo-URLs in animation_url verwenden? A: Nein. Externe Einbettungsdomänen werden von allen großen NFT-Marktplätzen blockiert. Es werden nur direkte Datei-URLs über HTTPS akzeptiert.

F: Unterstützt animation_url HLS-Streams (.m3u8)? A: Nein. HLS wird in aktuellen Indexer-Implementierungen nicht unterstützt. Nur progressive Download-Videoformate werden zuverlässig indiziert.

F: Was passiert, wenn meine Videodatei nach dem Minting einen 404-Fehler zurückgibt? A: Der NFT wird auf allen Plattformen leer dargestellt oder zeigt ein defektes Mediensymbol an. Es wird kein automatischer Fallback auf image_url durchgeführt.

F: Ist es sicher, Animationsdateien auf AWS S3 mit öffentlichen ACLs zu hosten? A: Ja – wenn Bucket-Richtlinien einen reinen HTTPS-Zugriff erzwingen und die Verzeichnisauflistung deaktivieren. Eine langfristige Unveränderlichkeit erfordert jedoch eine IPFS/Arweave-Verankerung, nicht S3.