Comment ajouter une animation ou une vidéo à mes métadonnées NFT ?

Exigences de format multimédia pour les métadonnées NFT

1. Le champ animation_url dans les métadonnées ERC-721 ou ERC-1155 doit pointer vers un point de terminaison HTTP(S) accessible au public, et non vers des URI IPFS bruts ou Arweave comme ipfs://QmXyZ... ou ar://abc123 .

2. Les formats vidéo valides incluent .mp4 , .webm et .mov ; Les GIF sont acceptés mais déconseillés pour les ressources volumineuses en raison de l'inefficacité de la taille et des limitations de lecture.

3. Les NFT audio uniquement nécessitent des fichiers .mp3 , .wav ou .ogg servis via HTTPS, avec des déclarations de type MIME explicites dans les en-têtes de réponse.

4. Tous les fichiers multimédias doivent faire moins de 100 Mo pour une indexation fiable en chaîne par les principaux marchés, notamment OpenSea et Blur.

5. Les dimensions et les proportions des fichiers doivent être conformes aux contraintes d'affichage spécifiques à la plate-forme : OpenSea impose une largeur maximale de 3 200 pixels pour les vidéos rendues dans les aperçus de collection.

Règles de conversion de passerelle

1. Les liens IPFS doivent être réécrits à l'aide de passerelles publiques de confiance : ipfs://QmXyZ... devient https://ipfs.io/ipfs/QmXyZ... ou https://cloudflare-ipfs.com/ipfs/QmXyZ... .

2. Les identifiants Arweave doivent être préfixés par https://arweave.net/ ; aucune barre oblique finale ni aucun paramètre de requête ne peuvent être ajoutés.

3. Les passerelles privées telles que Pinata ou Infura nécessitent des jetons d'authentification et ne conviennent pas aux métadonnées immuables, sauf si le jeton est intégré dans l'URL, une pratique fortement déconseillée en raison du risque de révocation.

4. La logique de repli de la passerelle ne doit jamais être implémentée côté client ; les métadonnées doivent être résolues sans ambiguïté sans intervention de JavaScript.

5. Les réponses des passerelles doivent renvoyer des en-têtes Content-Type valides correspondant à l'extension du fichier (par exemple, video/mp4 pour les fichiers MP4) pour éviter les échecs de rendu dans les portefeuilles et les explorateurs.

Meilleures pratiques de rendu HTML

1. Utiliser balises exclusivement pour le contenu vidéo, avec des attributs obligatoires de contrôle , de boucle et de sourdine pour garantir la compatibilité de la lecture automatique dans Chrome, Safari et MetaMask Mobile.

2. Évitez d'intégrer des médias via ou des acteurs tiers : ils rompent la vérification déterministe et violent la politique de validation des métadonnées d'OpenSea.

3. Spécifiez toujours les attributs de largeur et de hauteur sur et éléments pour empêcher les changements de disposition lors d’un chargement paresseux.

4. Ne comptez pas sur l'encodage Base64 en ligne pour la vidéo : il viole les limites de taille, augmente la surcharge JSON et empêche la diffusion en continu ou le téléchargement partiel.

5. Servez les médias via HTTP/2 ou HTTP/3 avec des en-têtes de mise en cache appropriés ( Cache-Control: public, max-age=31536000 ) pour réduire les requêtes répétées de passerelle lors des menthes à fort trafic.

Gestion de l'animation au niveau du contrat

1. Sur le réseau principal Ethereum, la fonction tokenURI() doit renvoyer une chaîne JSON statique contenant le champ animation_url ; la résolution dynamique via des oracles hors chaîne n'est pas prise en charge par les indexeurs.

2. Pour les chaînes L2 comme Optimism ou Base, vérifiez que le nœud RPC choisi prend en charge la résolution multimédia inter-domaines ; certains nœuds suppriment les en-têtes de réponse non standard requis pour le streaming vidéo.

3. En cas de déploiement via des outils de création tiers tels que Manifold Studio ou Thirdweb, vérifiez si l'outil convertit automatiquement ipfs:// en URL de passerelle au moment du téléchargement ou si une transformation manuelle est requise avant de finaliser le CID des métadonnées.

4. Ne stockez jamais la logique d’animation dans le bytecode du contrat intelligent ; les animations sont des problèmes de présentation purement hors chaîne et n'ont aucun impact sur la vérification de la propriété ou la sémantique du transfert.

5. Lorsque vous utilisez des fournisseurs de stockage décentralisés, épinglez d'abord le fichier d'animation, puis générez le JSON des métadonnées, puis épinglez le JSON lui-même. Inverser cet ordre risque de briser les références si le fichier d'animation n'est pas épinglé avant que le CID des métadonnées ne soit finalisé.

Foire aux questions

Q : Puis-je utiliser des URL YouTube ou Vimeo dans animation_url ? R : Non. Les domaines intégrés externes sont bloqués par tous les principaux marchés NFT. Seules les URL de fichiers directes via HTTPS sont acceptées.

Q : Animation_url prend-il en charge les flux HLS (.m3u8) ? R : Non. HLS n’est pas pris en charge dans les implémentations actuelles de l’indexeur. Seuls les formats vidéo à téléchargement progressif sont indexés de manière fiable.

Q : Que se passe-t-il si mon fichier vidéo renvoie un 404 après la création ? R : Le NFT s'affichera comme vide ou affichera une icône multimédia cassée sur toutes les plates-formes. Aucun retour automatique vers image_url n’est effectué.

Q : Est-il sûr d'héberger des fichiers d'animation sur AWS S3 avec des ACL publiques ? R : Oui, si les stratégies de compartiment appliquent l'accès HTTPS uniquement et désactivent la liste des répertoires. Cependant, l'immuabilité à long terme nécessite un ancrage IPFS/Arweave, et non S3.