Réparer maintenant
- Déposez le fichier
- La réparation s'exécute en local
- Téléchargez le résultat
Les téléphones Android —Pixel, Samsung, Xiaomi, OnePlus et les autres— enregistrent la vidéo via les API MediaRecorder et MediaMuxer de la plateforme, qui écrivent un .mp4 standard dans le conteneur ISO base-media. L'image et le son se déversent dans une boîte mdat à mesure que vous filmez, mais l'atome moov —l'index qui cartographie chaque image— n'est écrit que lorsque l'appli appelle MediaMuxer.stop() à la fin. Si l'appli n'atteint jamais cet appel, il vous reste un fichier rempli de données HEVC ou H.264 valides mais sans index, et n'importe quel lecteur le refuse. Déposez le fichier ci-dessus et l'outil vérifie exactement cela, dans votre navigateur, et reconstruit le conteneur quand le matériau est récupérable.
Pourquoi Android laisse un .mp4 non finalisé
La pile multimédia d'Android est explicite sur le moment où un enregistrement devient lisible. Pendant la capture, MediaRecorder (ou une appli d'appareil photo utilisant directement MediaCodec + MediaMuxer) ajoute les échantillons encodés au mdat. L'atome moov —tailles d'échantillons, offsets de fragments (chunks), tables de synchronisation et jeux de paramètres du codec— est assemblé en mémoire et déversé à la fin du fichier uniquement lorsque stop() et release() s'exécutent. Sautez cette étape et les octets sur le disque forment un MP4 sans tête : de vraies images, aucune carte.
Trois interruptions en sont la cause. L'appli Appareil photo a planté ou a été fermée par le système. Un bug, ou le « tueur » de mémoire faible d'Android (low-memory killer) qui récupère une appli en arrière-plan ou au premier plan sous pression mémoire, met fin au processus avant stop(), si bien que rien n'écrit l'index. Le stockage s'est rempli en pleine capture. La 4K en HEVC s'écrit très vite ; quand le stockage interne ou la carte SD atteint zéro octet libre, l'écriture du muxer échoue à mi-parcours et le fichier reste tronqué, sans moov. Le téléphone s'est éteint. Une batterie à plat ou un redémarrage forcé pendant la capture saute la finalisation de la même façon.
Le codec à l'intérieur est soit HEVC/H.265 (la valeur par défaut pour les modes haute résolution sur la plupart des Android récents, choisie pour son efficacité), soit H.264/AVC (la solution de repli pour la compatibilité). Le comportement du conteneur est identique dans les deux cas, et c'est pourquoi la voie de réparation est la même quel que soit le codec.
Ce qui peut être reconstruit et ce qui ne le peut pas
Comme les données des images survivent dans le mdat, la solution consiste à reconstruire l'index que MediaMuxer.stop() n'a jamais écrit. L'outil analyse le flux qui a survécu, récupère les limites et la synchronisation de chaque image et refait les tables d'échantillons pour qu'un lecteur puisse décoder depuis le début, transformant un fichier sans tête en un MP4 normal dans lequel on peut naviguer. Lorsque le fichier a en plus été tronqué par un disque plein, il récupère les images qui ont été entièrement écrites avant la coupure et referme un conteneur lisible autour d'elles, de sorte qu'un clip ayant capturé 80 % d'une prise restitue ces 80 % au lieu d'échouer en entier. Tout cela s'exécute dans votre navigateur à mesure que le fichier est lu depuis le stockage.
La limite honnête, c'est que les images écrites après l'interruption n'existent pas : un disque plein arrête l'écriture, un plantage arrête l'encodeur, et aucun outil ne peut inventer des octets qui n'ont jamais été stockés. Quand il ne reste que la copie tronquée, la récupérer est le bon choix ; mais si le fichier original est toujours sur le téléphone et qu'il suffit de le recopier proprement, faites-le d'abord, car une bonne copie vaut mieux que n'importe quelle réparation.
Pourquoi un clip du même téléphone et de la même appli aide
Reconstruire l'index est plus fiable quand l'outil connaît la configuration exacte du codec que le fichier endommagé a omise. Un clip en bon état du même téléphone, enregistré par la même appli dans le même mode, fournit précisément cela : les jeux de paramètres HEVC (VPS/SPS/PPS) ou les SPS/PPS de H.264, ainsi que la résolution et la cadence d'images, de sorte que la reconstruction reproduit l'original au lieu de l'approximer.
En pratique : enregistrez quelques secondes sans importance avec la même appli d'appareil photo et les mêmes réglages de qualité, et gardez-les sous la main. Faites correspondre le codec (une référence HEVC pour un clip HEVC, H.264 pour H.264) et on ne vous la demandera que si la réparation en a besoin. Un échantillon d'un autre téléphone ou d'une autre appli ne convient généralement pas, car les jeux de paramètres diffèrent.
Ce que cela peut et ne peut pas réparer
Peut réparer
- Un enregistrement que l'appli Appareil photo ou une appli vidéo n'a jamais finalisé parce qu'elle a planté ou a été fermée par le système avant MediaMuxer.stop() (moov manquant)
- Des clips coupés net quand le stockage interne ou la carte SD s'est rempli en pleine capture
- Des enregistrements interrompus par une batterie à plat ou un redémarrage forcé pendant la capture
- Des fichiers .mp4 HEVC et H.264 qui refusent de s'ouvrir dans Google Photos, la Galerie, VLC ou un éditeur alors qu'ils contiennent de vraies images
Ne peut pas réparer
- Le matériau postérieur à l'interruption : ces images n'ont jamais été écrites dans le stockage
- Un fichier qui se lit comme 0 octet ou presque uniquement des zéros après une copie ratée ou une carte SD défaillante
- Du contenu protégé par DRM ou chiffré
- Un clip HEVC endommagé sans référence HEVC équivalente du même téléphone et de la même appli
Si une réparation échoue, nous vous expliquons pourquoi (données manquantes ou structure endommagée), et vous n'êtes jamais facturé pour une réparation échouée.