Fichier MP4 / MOV tronqué — Guide de récupération

Un fichier vidéo « tronqué » est un fichier qui a été coupé avant que l'enregistrement n'ait atteint un arrêt net. La définition technique : il manque au fichier son index (atome MOOV), et il manque peut-être quelques octets finaux de la dernière image en cours. La définition fonctionnelle : il se trouve sur votre disque et semble avoir la bonne taille, mais il ne s'ouvre pas dans QuickTime / Premiere / Resolve et sa durée est indiquée comme étant zéro (ou un nombre étrange) lorsqu'il est examiné.

Les fichiers tronqués sont la catégorie de corruption vidéo la plus récupérable. La mauvaise nouvelle : la plupart des outils de « réparation MP4 » grand public les gèrent mal. La bonne nouvelle : c'est exactement pour ce cas que notre moteur et nos outils comme « untrunc » ont été conçus.

À quoi ressemble réellement la troncature

Un MP4/MOV normal se termine par un atome MOOV finalisé qui indexe tout en « mdat ». Un fichier tronqué se termine en cours d'écriture :

[ftyp]    ← container declaration, intact
[mdat]    ← frames + audio interleaved
                    ↓ truncation point — recording stopped here
[the next bytes — partial frame, partial atom, or just EOF]
            ← MOOV that should be here doesn't exist

Trois schémas courants :

1. Troncature due à une coupure de courant / un retrait de la carte. Le plus courant. « mdat » se termine au milieu d'une image ; pas de MOOV ; le fichier est par ailleurs correct.
2. Troncature due à une erreur du système de fichiers. Un secteur défectueux a mis à zéro une section du fichier, ou le système de fichiers n'a pas réussi à écrire les blocs finaux. « mdat » peut présenter un trou, mais est par ailleurs intact.
3. Troncature de copie ratée. Le fichier a été partiellement copié à partir d'une carte SD / d'un SSD et la copie a échoué. Le fichier « corrompu » sur le lecteur de destination n'est qu'une copie partielle d'une source par ailleurs correcte.

La cause n° 3 mérite d'être vérifiée avant toute récupération : essayez de copier à nouveau le fichier à partir de la source d'origine. Si l'original est toujours sur la carte SD / le SSD et que le fichier qui s'y trouve est en bon état, vous avez résolu le problème en 60 secondes.

Ce que signifie vraiment « la durée est affichée comme étant zéro »

Lorsque QuickTime ou VLC affiche la durée d'un enregistrement comme 0:00 ou comme une valeur incroyablement longue (comme 4:32:18:35), cela signifie presque toujours que la durée est lue à partir d'un « mvhd » (en-tête de film) manquant ou mal formé à l'intérieur du MOOV. Sans MOOV valide, il n'y a pas de durée valide. Les images sont toujours là dans « mdat », mais le lecteur ne sait tout simplement pas quelle est la durée de la vidéo.

Ce que vous pouvez essayer vous-même

1. Recopier à partir de la source

Cela semble évident. On l'ignore souvent. Si le fichier d'origine se trouve toujours sur la carte SD / le SSD, essayez de le copier à nouveau sur un autre lecteur. Une nouvelle copie avec « cp » (ou rsync, ou une copie du Finder) produit parfois un fichier fonctionnel lorsque la copie précédente était corrompue.

2. 'untrunc'

'untrunc' — open-source — a été nommé d'après ce mode de défaillance exact. Nécessite un fichier de référence sain provenant de la même caméra dans le même mode d'enregistrement. Commande rapide :

untrunc reference.mov broken.mov

Produit « broken.mov_fixed.mov ». Essayez de l'ouvrir. Excellent pour la cause n° 1 (troncature nette, pas de trous) lorsqu'une référence est disponible.

3. Re-mux FFmpeg ignore-errors

ffmpeg -err_detect ignore_err -i broken.mp4 -c copy out.mp4

Fonctionne parfois pour la cause n° 2 (trous dans le système de fichiers) en ignorant les sections illisibles.

4. Supprimer la dernière image partielle

Si « untrunc » ou nos outils se plaignent que la dernière image est incomplète, il existe une approche manuelle : coupez quelques centaines de Mo à la fin du fichier et réessayez. Le fichier rogné perd la ou les deux dernières secondes, mais sa structure est propre. Les outils qui automatisent cette opération (y compris les nôtres) le font pour vous.

Comment notre récupération gère la troncature

• Le diagnostic en six passes identifie si le fichier est tronqué proprement (cause n° 1), présente des trous internes (cause n° 2) ou est partiellement copié (cause n° 3).
• Analyse au niveau de la trame de « mdat » pour trouver la dernière trame complète, rognage automatique en toute sécurité de toute trame partielle de fin.
• Synthèse MOOV à partir des images observées — aucun clip de référence n'est requis.
• « co64 » pour les fichiers de plus de 4 Go pour éviter le dépassement de décalage dans l'index reconstruit.
• Récupération audio avec filtrage de la dominance de la taille des morceaux (ignorer les morceaux aberrants, conserver l'enregistrement cohérent).
• Détection de trou pour la cause n° 2 : si le fichier a une section remplie de zéros au milieu, nous l'identifions, sautons la plage morte et reconstruisons autour d'elle. Le fichier récupéré peut présenter un bref espace ou un sautillement au niveau du trou, mais le reste est lisible.

Ce que vous faites

1. Premièrement : essayez de recopier à partir de la source si vous l'avez encore. Gratuit, rapide, souvent la solution.
2. Si le fichier est réellement tronqué et que la recopie ne résout pas le problème : téléchargez-le. Jusqu'à 50 Go.
3. Environ 1 minute plus tard, vous obtenez un aperçu gratuit de 5 secondes.
4. Ne payez que si l'aperçu fonctionne.

FAQ

Mon fichier affiche la bonne taille de fichier, mais la lecture dure moins longtemps que prévu. Il s'agit d'un mode de défaillance différent : l'enregistrement a probablement été finalisé, mais la durée de lecture est plus courte que la durée d'enregistrement. Il s'agit souvent d'un problème d'échelle de temps « mvhd », parfois d'un « stts » mal formé. Récupérable ; importez-le pour diagnostic.

Mon fichier est lu pendant les 10 premières secondes, puis le lecteur plante. La cause n° 2 (trou au milieu du fichier) est la plus probable. Les 10 premières secondes sont des « mdat » intacts ; le lecteur atteint le trou et ne peut pas continuer. La récupération reconstruit autour du trou.

'untrunc' a échoué car je n'ai pas de clip de référence. Raison courante d'utiliser un service comme le nôtre. Nous n'avons pas besoin de référence : nous extrayons les paramètres du codec directement à partir des images du fichier endommagé.

Mon fichier provient d'une carte SD supprimée puis récupérée. Est-il encore récupérable ? Les outils de récupération de carte renvoient parfois des fichiers contenant des données de sources mixtes (octets de l'enregistrement d'origine plus octets d'enregistrements ultérieurs écrasés par-dessus). Ceux-ci sont plus compliqués. Le diagnostic au téléchargement nous indique s'ils sont exploitables.

Le fichier affiche une durée incorrecte mais est lu correctement. Juste une correction de métadonnées — « ffmpeg -i input.mp4 -c copy out.mp4 » réécrit généralement la durée correctement pendant le re-mux. Aucune récupération payante n'est nécessaire.

Mes images sont-elles en sécurité ? Serveur en France, suppression automatique après 48 heures, jamais utilisé pour l'entraînement ou partagé. Politique de confidentialité.

Connexes

• Atome MOOV introuvable (la cause de la troncature canonique)
• Données non valides trouvées lors du traitement de l'entrée
• Fonctionnement de notre moteur de récupération

Téléchargez votre fichier →