La vidéo est lue trop rapidement ou trop lentement — Mauvais nombre d'images par seconde

La vidéo s'ouvre. L'audio est là. Mais la vidéo ne semble pas correcte : elle est lue trop vite, trop lentement ou de manière saccadée. Il s'agit généralement d'une incompatibilité de la fréquence d'images.

Ce qui se passe

Un fichier vidéo déclare sa fréquence d'images à deux endroits : par piste dans les « mvhd » et « mdhd » (échelle de temps et durée), et implicitement par les durées d'images dans la table « stts ». Si ces valeurs ne correspondent pas, ou si la récupération a écrit les mauvaises valeurs, le lecteur divise mal le temps et la vidéo apparaît à la mauvaise vitesse.

Problèmes courants :

Schéma 1 : demi-vitesse ou double vitesse

Le fichier enregistré est à 60 ips mais est lu à 30 ips (il semble être au ralenti) ou vice versa. Il s'agit presque toujours d'une erreur de lecture de la fréquence d'images au moment de la récupération. Les images sont correctes ; seules les métadonnées de synchronisation sont erronées.

Schéma 2 : mouvement saccadé / aspect d'images perdues

La vidéo semble lire une image sur deux. Il s'agit souvent d'une incompatibilité de fréquence d'images : le lecteur est réglé sur 30 ips, mais le fichier est à fréquence variable ou à 60 ips, de sorte que des images sont effectivement supprimées lors de l'affichage.

Schéma 3 : la vidéo est lue correctement mais est exportée à une vitesse incorrecte

Vous importez dans Premiere / Resolve, la timeline se lit normalement, mais l'exportation est rapide ou lente. Les paramètres du projet (fréquence d'images de la timeline) ne correspondent pas à la fréquence d'images du clip, et la conformité est incorrecte.

Schéma 4 : problèmes de fréquence d'images variable (VFR)

L'iPhone et de nombreux téléphones enregistrent en VFR : les intervalles réels entre les images varient légèrement. Les NLE convertissent en fréquence d'images constante (CFR) à l'importation, parfois de manière incorrecte. Résultat : décalage temporel sur l'enregistrement.

Comment déterminer de quel cas il s'agit

ffprobe -v error -show_streams broken.mov | grep -E "r_frame_rate|avg_frame_rate|time_base|nb_frames|duration"

Vous obtiendrez quelque chose comme :

r_frame_rate=60/1
avg_frame_rate=60/1
time_base=1/60000
duration=120.500000
nb_frames=7230

Vérification mathématique : « nb_frames / duration ≈ avg_frame_rate ». Si cela n'est pas approximativement vrai, les métadonnées de synchronisation sont incohérentes.

Si « r_frame_rate » et « avg_frame_rate » diffèrent de manière significative → VFR (modèle 4).

Si 'nb_frames * (1/r_frame_rate) ≠ duration' → durée incorrecte ou métadonnées de fréquence d'images incorrectes.

Que faire

Modèle 1 — fréquence d'images incorrecte

Remultiplexez en forçant la bonne fréquence d'images :

ffmpeg -i broken.mov -c copy -video_track_timescale 60000 -r 60 fixed.mov

Remplacez « 60 » par la fréquence d'images réelle. Si vous ne savez pas ce que la caméra enregistrait : vérifiez le menu de la caméra ou comptez les mouvements visibles dans le fichier (si un plan panoramique clairement à 60 ips semble être au ralenti, il est lu à 30 ips ; forcez 60 ips).

Modèle 2 — lecture saccadée

Il s'agit souvent d'un problème de lecteur plutôt que d'un problème de fichier. Essayez VLC ou Resolve. Si la lecture est fluide, le fichier est correct et le problème vient de votre lecteur d'origine.

Si même VLC est saccadé : le timing des images du fichier présente des écarts. Re-multiplexez avec régénération de l'horodatage :

ffmpeg -i broken.mov -fflags +genpts -c copy fixed.mov

Modèle 3 — Incompatibilité de la fréquence d'images du projet

Définissez la fréquence d'images de votre timeline pour qu'elle corresponde au clip. Dans Premiere : Nouvelle séquence → Paramètres → Base de temps. Dans Resolve : Project Settings → Master Settings → Timeline frame rate.

Si vous devez utiliser une fréquence de timeline différente, l'outil « Interpret footage » de votre NLE peut remplacer la fréquence indiquée du clip sans affecter les autres clips.

Modèle 4 — Dérive VFR

Convertir en CFR avec FFmpeg :

ffmpeg -i variable_frame_rate.mov -vsync cfr -r 30 -c:a copy constant_frame_rate.mp4

'-r 30' est le CFR cible ; choisissez-le pour qu'il corresponde à la fréquence dominante dans la source.

Comment notre récupération gère la détection de la fréquence d'images

Le pipeline de récupération détecte la fréquence d'images de deux manières :

• À partir des paramètres du codec. Les en-têtes de trame H.264 SPS, H.265 SPS, ProRes contiennent tous des informations sur la fréquence d'images. Nous l'extrayons de l'ensemble de paramètres de la première image valide.
• À partir de la distribution des horodatages. Lorsque les paramètres du codec sont manquants ou endommagés, nous déduisons la fréquence d'images de l'espacement entre les images détectées dans « mdat » : l'intervalle d'image médian devient l'estimation de la fréquence d'images.

Cas particuliers :

• Sources VFR (séquences de téléphone) : le fichier récupéré est CFR par défaut à la fréquence d'images médiane, avec un transfert d'horodatage par image afin que le timing de lecture corresponde à l'original. Vous pouvez demander une sortie VFR si votre éditeur en a besoin.
• Modes ralenti (par exemple, iPhone 240 ips) : le fichier récupéré est lu à la fréquence de lecture prévue de la source (30 ips), ce qui fait que la source à 240 ips est lue au ralenti 8x comme prévu.
• Fréquences mixtes (rares, uniquement observées dans les enregistrements concaténés) : nous extrayons la fréquence dominante et signalons le cas pour examen manuel.

Ce que vous faites

Si un fichier récupéré ailleurs est lu à une vitesse incorrecte : essayez les correctifs FFmpeg ci-dessus avant de le récupérer à nouveau. Si cela ne fonctionne pas, téléchargez le fichier original endommagé et nous recommencerons avec la détection correcte de la fréquence d'images.

Si le fichier provient de nous et que la vitesse est incorrecte : faites remonter le cas depuis votre page de tâche. Nous régénérerons le fichier avec les images par seconde corrigées. Sans frais.

FAQ

Mon enregistrement au ralenti sur iPhone est lu à la mauvaise vitesse après la récupération. Les modes ralenti enregistrent à un nombre d'images par seconde élevé (120, 240) et intègrent des métadonnées de vitesse de lecture indiquant « lire à 30 ». La récupération perd parfois ces métadonnées. Solution : dans Photos / FCP, définissez manuellement la vitesse de lecture ; ou réexportez avec « -r 30 » pour obtenir la vitesse de lecture souhaitée.

L'enregistrement de jeu/d'écran est lu trop rapidement dans Premiere. Presque toujours une incompatibilité de la fréquence d'images du projet (modèle 3). Définissez la timeline pour qu'elle corresponde à la fréquence source.

La vidéo est lue à la mauvaise vitesse uniquement sur YouTube après le téléchargement. YouTube transcode les importations à une fréquence d'images fixe (29,97/59,94 en général). Si votre fichier est exactement à 30/60 avec des métadonnées hors spécifications, l'interprétation de YouTube peut différer. Pré-transcodez pour répondre aux attentes de YouTube :

ffmpeg -i input.mov -r 30000/1001 -c:v libx264 -c:a copy youtube_friendly.mp4

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

Connexes

• Audio désynchronisé
• La durée indique zéro
• Comment fonctionne notre moteur de récupération

Téléchargez votre fichier →