"Invalid data found when processing input"

Un fichier MP4 ou MOV est une arborescence de boîtes (aussi appelées atomes). Chaque boîte commence par une taille sur 4 octets et un type sur 4 octets : ftyp déclare la marque (brand), mdat contient les échantillons audio et vidéo bruts, et moov est l'index : les tables d'échantillons qui indiquent où se trouve chaque image, quel codec la décode et à quel horodatage. Lorsque ffmpeg ouvre le fichier, il parcourt cette arborescence. S'il ne trouve pas de moov cohérent, si une boîte annonce une taille qui dépasse la fin du fichier, ou si les octets où devrait se trouver l'en-tête d'une boîte ne sont que du bruit, il s'arrête et signale « Invalid data found when processing input ».

Et le point essentiel : les données lourdes (le mdat qui contient vos images réelles) peuvent être parfaitement intactes pendant que cela se produit. L'analyseur échoue sur l'index, pas sur les images. C'est pourquoi le même fichier qui « ne contient aucune donnée valide » peut être plein d'images en parfait état, en attente d'un conteneur qui les décrive correctement. Cela recoupe largement le cas classique du « moov atom not found » : un enregistrement interrompu avant que la caméra n'écrive son moov laisse exactement cette signature.

Quand les échantillons ont survécu mais que la carte est cassée, la solution consiste à remultiplexer (remux) : analyser les données du flux qui ont survécu, reconstruire les tables d'échantillons dont le conteneur a besoin et écrire un MP4 neuf et bien formé autour des mêmes images. Aucun réencodage n'entre en jeu, donc aucune perte de qualité : les images sont les images d'origine, simplement réindexées correctement. Lorsque le moov manque entièrement, l'outil le reconstruit à partir de la structure du flux multimédia afin que le lecteur dispose de la carte des images qu'il cherchait.

L'autre déclencheur fréquent est une extension qui ne correspond pas ou un transfert interrompu. Un fichier nommé .mp4 qui a en réalité été enregistré dans un autre conteneur, ou un clip dont le téléchargement s'est arrêté à mi-chemin, font tous deux que ffmpeg s'étrangle sur des octets inattendus. L'outil vérifie ce qu'est réellement le fichier d'après les signatures de ses boîtes plutôt que d'après son nom, et récupère la partie qui est arrivée. Tout cela s'exécute dans votre navigateur : sans installer ffmpeg, sans ligne de commande et sans qu'aucun serveur ne reçoive jamais la vidéo.

Reconstruire le conteneur ne fonctionne que lorsque le problème vient du conteneur. Si les données multimédias sous-jacentes elles-mêmes sont détruites ou écrasées (une carte qui a renvoyé des zéros, un fichier abîmé par un disque défaillant, un enregistrement par-dessus lequel la caméra a réenregistré en boucle), il n'y a aucune image valable à réindexer, et aucun outil ne peut reconstruire des images qui ne sont pas sur le disque. Récupérez d'abord les octets bruts depuis le stockage, puis réparez.

L'autre cas véritablement perdu, en toute honnêteté, est un fichier qui n'est pas vraiment une vidéo : un document, une image ou un fragment tronqué qui porte par hasard une extension .mp4. Là, le « Invalid data » est littéralement vrai, et aucun remux ne peut transformer un fichier non multimédia en un clip lisible. En revanche, lorsque les images sont bien présentes, l'approche 100 % navigateur signifie que les enregistrements sensibles (preuves judiciaires, vidéo personnelle, travail non publié) sont réparés sans être copiés où que ce soit. Ouvrez l'onglet Réseau (Network) et vous pourrez vérifier que 0 octet du clip n'est envoyé.