Réparer une vidéo MP4 ou MOV corrompue

Ce que cette page vérifie exactement

Choisissez une vidéo : cette page parcourt tout le flux pour trouver les images dont les données sont endommagées, puis vous montre où elles se trouvent sur une timeline. La réparation enregistre un nouveau fichier qui ne contient que les images décodables, si bien que le résultat se lit sans se figer. Tout se passe sur votre appareil : rien n’est envoyé.

Dans un MP4 ou un MOV, chaque image H.264 ou HEVC est stockée sous forme de chaîne : une longueur, puis autant d’octets de données d’image, puis la longueur suivante, et ainsi de suite jusqu’à la fin des données de l’image. La chaîne doit tomber exactement sur la fin. Si une longueur vaut zéro, ou pointe au-delà de la fin des données, les octets de cette image ne sont pas ce que le fichier prétend.

Après avoir vérifié la longueur des paquets, l’outil décode chaque groupe d’images. Si le décodage échoue, le groupe est exclu et la vérification reprend à l’image clé suivante ; la timeline signale tout le groupe concerné, car l’image fautive exacte peut rester inconnue.

Si vous avez déjà passé une vidéo abîmée dans ffmpeg et vu défiler Invalid NAL unit size (0 > 1241), c’est exactement ce problème qui était signalé. Les lecteurs réagissent généralement en se figeant, en sautant des passages ou en affichant une bouillie de blocs : c’est tout ce qu’ils peuvent faire avec des octets qui n’existent pas.

La vérification nécessite un décodeur pour le codec de la vidéo. Un navigateur incapable de décoder la vidéo ne peut pas vérifier une copie réparée.

Deux types de dégâts, qui ne se ressemblent pas

Des images aux données corrompues. Quelque chose a écrit de mauvais octets : une copie interrompue sur une clé USB, une carte mémoire défaillante, une synchronisation coupée en plein milieu. La longueur et l’index du fichier sont intacts et la vidéo s’ouvre normalement, mais certaines images à l’intérieur sont inutilisables. Sur la timeline, elles apparaissent sous forme de marques dispersées là où les dégâts se sont produits.

Une vidéo tronquée. Un téléchargement ou un transfert s’est arrêté trop tôt. L’en-tête annonce toujours la durée d’origine, si bien que les lecteurs affichent une barre de lecture complète, mais les données d’image s’arrêtent tout simplement en cours de route. Cette page le détecte en comparant la durée annoncée par le fichier à la dernière image réellement accessible ; sur la timeline, c’est un bloc gris à la fin.

Il vaut la peine de les distinguer, car on ne peut pas en attendre la même chose. Des dégâts dispersés vous coûtent souvent une seconde ici ou là. Un fichier coupé à 40 % est privé de 60 % de la vidéo, et aucun outil ne peut inventer ce qui n’a jamais été écrit.

Pourquoi le fichier réparé est plus court

Les images d’une vidéo ne sont pas indépendantes. Une image clé se suffit à elle-même, mais les images qui la suivent sont stockées sous forme de différences par rapport à elle : si les données d’une image clé sont endommagées, toutes les images qui en dépendent deviennent inutilisables elles aussi, même si leurs propres octets sont parfaitement sains. C’est pourquoi un fichier qui compte dix images endommagées peut en perdre bien plus que dix.

La réparation ne conserve que les images réellement décodables et resserre les trous, pour que le résultat se lise d’un bout à l’autre au lieu de se figer là où se trouvaient les dégâts. La contrepartie : le fichier obtenu est plus court que l’original, de toute la durée retirée. La page vous indique ce chiffre avant que vous ne lanciez la réparation, puis de nouveau sur le résultat.

Dans le mode par défaut, les images conservées sont copiées sans réencodage. Le contrôle complet du décodage prend du temps ; le mode facultatif « Garder aussi les images incomplètes » réencode la vidéo conservée.

Le son est conservé et reste synchronisé. Comme les trous sont resserrés, l’image ne correspond plus à une bande-son de la durée d’origine : le son est donc coupé exactement aux mêmes endroits, et chaque passage d’image conservé garde son propre passage de son, décalé de la même durée. À l’intérieur d’un passage, l’image et le son restent calés ; ce n’est qu’aux raccords que le son peut être décalé, et jamais de plus d’un demi-paquet audio, soit une dizaine de millisecondes. C’est un ordre de grandeur en dessous de ce que l’on peut percevoir comme un défaut de synchronisation labiale.

Ce que cet outil ne peut pas faire

Un fichier qui ne s’ouvre pas du tout est hors de portée. Chaque MP4 contient un index qui décrit l’emplacement de chaque image. Si cet index est endommagé ou absent — c’est fréquent quand un enregistrement s’arrête sans avoir été finalisé —, il n’y a aucune carte à suivre, et cette page vous le dit au lieu de tourner dans le vide. Pour récupérer ces fichiers, il faut la source d’origine ou un outil qui reconstruit l’index en devinant où commence et où finit chaque image.

Le son n’est pas contrôlé. Les paquets audio existants sont copiés et coupés pour correspondre à la vidéo conservée. Un son endommagé ou déjà manquant ne peut pas être restauré par ce traitement.

Uniquement H.264 et HEVC. Ce sont les codecs qui stockent les images avec des préfixes de longueur, et c’est ce que lit la vérification. MJPEG, MPEG-4 Part 2 et d’autres organisent leurs images différemment : mesurées de cette façon, elles paraîtraient toutes endommagées, alors la page préfère refuser.

FAQ