La durée de la vidéo indique 0:00 — Comment résoudre le problème

Le fichier fait des centaines de mégaoctets (ou de gigaoctets). La vignette d'aperçu du Finder/de l'Explorateur peut même s'afficher. Mais la durée indique « 0:00 » dans QuickTime, dans la fenêtre Lire les informations de Finder, dans la boîte de dialogue d'importation de Premiere et dans « ffprobe ». La vidéo n'a apparemment aucune durée.

Il s'agit presque toujours d'un problème de métadonnées, et non d'un problème de contenu. Les données vidéo sont dans le fichier. L'information qui indique la durée de la vidéo : c'est ce qui manque ou est corrompu.

Où se trouve la durée dans un MP4/MOV

La durée est stockée dans l'atome « mvhd » (en-tête du film) à l'intérieur de MOOV, ainsi que par piste dans « tkhd » et « mdhd ». Les trois devraient correspondre. Si MOOV est complètement absent, les trois sont absents : la durée est de 0, car il n'y a rien à lire.

Trois cas :

Cas 1 : MOOV est manquant → la durée indique 0

Même cause première que MOOV atom not found : l'enregistrement a été interrompu avant l'écriture de l'index. Le champ de durée n'existe nulle part dans le fichier.

Indice : le fichier est volumineux mais « ffprobe » renvoie « moov atom not found » et la durée est indiquée comme 0 ou « N/A ».

C'est le cas le plus facile à résoudre.

Modèle 2 : MOOV existe mais a une échelle de temps = 0 ou une durée = 0

Le MOOV est présent ; le champ de durée à l'intérieur de « mvhd » est défini sur zéro (ou l'échelle de temps est zéro, ce qui fait que la durée affichée est zéro par division). Cela se produit parfois avec des MOOV à écriture partielle qui n'ont pas fini de remplir la durée avant que la caméra ne s'éteigne.

Indicateur : « ffprobe » renvoie un nombre de flux et des informations sur le codec, mais une durée de 0 ou N/A. Le fichier est lu, mais le lecteur ne peut pas effectuer de recherche et n'affiche aucune barre de progression.

Souvent corrigé par un re-mux qui recalcule la durée à partir des horodatages des images :

ffmpeg -i broken.mp4 -c copy fixed.mp4

FFmpeg recalcule la durée à partir des horodatages au niveau du codec et écrit un nouveau MOOV.

Modèle 3 : débordement d'entier sur des enregistrements très longs

Moins courant. Certains anciens outils stockent la durée sous la forme d'une valeur 32 bits avec une échelle de temps élevée, qui déborde pour les enregistrements de plus de quelques heures. La valeur passe alors à un nombre négatif ou est lue comme zéro.

Indice : le fichier provient d'un enregistrement de plusieurs heures (caméra de sécurité, diffusion en direct, événement de longue durée). Le re-mux de FFmpeg corrige cela en écrivant une durée de 64 bits si nécessaire.

Comment déterminer le modèle

ffprobe -v error -show_format broken.mp4

Regardez la sortie :

Si la durée est réelle mais incorrecte (par exemple, le fichier indique 12 minutes mais l'enregistrement durait en réalité 47 minutes), il s'agit d'un modèle distinct de « durée incorrecte », généralement dû à une incohérence d'échelle de temps. Le re-multiplexage avec FFmpeg résout le problème la plupart du temps.

Ce que vous pouvez essayer vous-même

Pour le modèle 1 : voir le guide de récupération MOOV.

Pour les cas 2 et 3, la solution la plus simple est le re-mux FFmpeg :

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

Cela réécrit le MOOV avec la durée calculée à partir des horodatages des images. Cela fonctionne généralement.

Si '-c copy' ne corrige pas la durée, forcez le réencodage du flux audio (qui régénère de manière fiable les métadonnées d'horodatage) :

ffmpeg -i broken.mp4 -c:v copy -c:a aac out.mp4

Si aucune de ces solutions ne fonctionne, les données d'horodatage dans le flux de codec sont également endommagées et la récupération sera plus difficile.

Comment notre récupération gère les fichiers de durée nulle

• Modèle 1 — synthèse MOOV complète à partir des images. La durée est calculée à partir du nombre et du timing des images détectées dans « mdat ».
• Modèle 2 / 3 — Le MOOV est reconstruit à partir de zéro (nous ne faisons pas confiance au MOOV existant). Durée écrite avec des valeurs 64 bits lorsque la longueur de l'enregistrement le justifie ; échelle de temps choisie pour correspondre au débit naturel du codec.
• 'co64' pour les fichiers de plus de 4 Go afin que les décalages de blocs ne débordent pas parallèlement à la correction de la durée.

Ce que vous faites

1. Téléchargez le fichier.
2. Aperçu gratuit de 5 secondes environ 1 minute plus tard. La durée dans le fichier récupéré indiquera la longueur réelle de l'enregistrement.
3. Ne payez que si cela fonctionne.

FAQ

Mon fichier affiche la bonne durée dans VLC, mais 0:00 dans QuickTime. Lecteur permissif vs lecteur strict. VLC calcule la durée à partir des horodatages des images, même lorsque MOOV indique 0 ; QuickTime fait confiance à MOOV. Re-mux corrige les deux.

Le fichier provient d'une caméra de sécurité / d'une caméra de tableau de bord — la durée est incorrecte sur les enregistrements de plusieurs heures. Probablement le modèle 3 (dépassement d'entier). Le re-mux FFmpeg avec les versions actuelles corrige cela dans la plupart des cas.

Mon fichier récupéré a une durée, mais le lecteur ne recherche pas. Il s'agit souvent d'un « stss » (tableau d'échantillons de synchronisation) manquant : le lecteur a la durée mais pas de carte d'images clés vers laquelle se diriger. La récupération reconstruit « stss » à partir des positions IDR / image clé observées.

J'obtiens une durée de zéro sur un fichier provenant de la récupération d'un autre outil. Leur récupération peut avoir produit un MOOV partiel. Téléchargez le fichier d'origine (avant la récupération) ; nous le referons à partir de zéro.

Mes images sont-elles en sécurité ? Serveur en France, suppression automatique après 48 heures, jamais utilisé pour entraîner quoi que ce soit ou partagé. Politique de confidentialité.

Articles connexes

• Atome MOOV introuvable
• Impossible de trouver les données essentielles
• Comment fonctionne notre moteur de récupération

Téléchargez votre fichier →