Video Plays Too Fast or Too Slow — Wrong Frame Rate

The video opens. The audio's there. It just looks wrong — playing too fast, too slow, or jerky. Usually a frame rate mismatch.

What's happening

A video file declares its frame rate in two places: per-track in the mvhd and mdhd (timescale and duration), and implicitly through frame durations in the stts table. If those disagree, or if the recovery wrote the wrong values, the player divides time wrong and the video appears at the wrong speed.

Common patterns:

Pattern 1: half-speed or double-speed

The recorded file is 60 fps but plays at 30 fps (looks slow-mo) or vice versa. Almost always a misread frame rate at recovery time. The frames are correct; only the timing metadata is wrong.

Pattern 2: jerky motion / dropped frames look

The video looks like it's playing every other frame. Often a frame-rate mismatch where the player is set to 30 fps but the file is variable or 60 fps, so frames get effectively dropped during display.

Pattern 3: video plays correctly but exports at wrong speed

You import into Premiere / Resolve, the timeline plays normally, but the export comes out fast or slow. Project settings (timeline frame rate) don't match clip frame rate, and the conform is incorrect.

Pattern 4: variable frame rate (VFR) issues

iPhone and many phones record VFR — actual frame intervals vary slightly. NLEs convert to constant frame rate (CFR) on import, sometimes incorrectly. Result: timing drift over the recording.

How to figure out which one

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

You'll get something like:

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

Math check: nb_frames / duration ≈ avg_frame_rate. If that doesn't approximately hold, the timing metadata is inconsistent.

If r_frame_rate and avg_frame_rate differ significantly → VFR (pattern 4).

If nb_frames * (1/r_frame_rate) ≠ duration → wrong duration or wrong frame rate metadata.

What to do

Pattern 1 — wrong frame rate

Re-mux with the correct frame rate forced:

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

Replace 60 with the actual frame rate. If you don't know what the camera was recording: check the camera's menu, or count visible motion in the file (if a clearly 60-fps panning shot looks slow-mo, it's playing at 30; force 60).

Pattern 2 — jerky playback

Often a player issue rather than a file issue. Try VLC or Resolve. If those play smoothly, the file is fine and your original player is the problem.

If even VLC stutters: the file's frame timing has gaps. Re-mux with timestamp regeneration:

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

Pattern 3 — project frame rate mismatch

Set your timeline's frame rate to match the clip. In Premiere: New Sequence → Settings → Timebase. In Resolve: Project Settings → Master Settings → Timeline frame rate.

If you must use a different timeline rate, your NLE's "interpret footage" tool can override the clip's reported rate without affecting other clips.

Pattern 4 — VFR drift

Convert to CFR with FFmpeg:

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

-r 30 is the target CFR; choose to match the dominant rate in the source.

How our recovery handles frame rate detection

The recovery pipeline detects frame rate in two ways:

From codec parameters. H.264 SPS, H.265 SPS, ProRes frame headers all carry frame rate information. We extract it from the first valid frame's parameter set.
From timestamp distribution. When codec parameters are missing or damaged, we derive frame rate from the spacing between detected frames in mdat — the median frame interval becomes the fps estimate.

Edge cases:

VFR sources (phone footage): the recovered file is CFR by default at the median frame rate, with a per-frame timestamp passthrough so the playback timing matches the original. You can request VFR output if your editor needs it.
Slow-motion modes (e.g. iPhone 240 fps): the recovered file plays at the source's intended playback rate (30 fps), which makes 240 fps source play 8x slow-mo as expected.
Mixed rates (rare, only seen in concatenated recordings): we extract the dominant rate and flag the case for manual review.

What you do

If a recovered file from elsewhere plays at wrong speed: try the FFmpeg fixes above before re-recovering. If those don't work, upload the original broken file and we'll redo with correct frame rate detection.

If the file is from us and the speed is wrong: escalate the case from your job page. We'll regenerate with the corrected fps. No charge.

FAQ

My iPhone slow-mo recording plays at the wrong speed after recovery. Slow-mo modes record at high fps (120, 240) and embed playback rate metadata that says "play this at 30." Recovery sometimes loses that metadata. Solution: in Photos / FCP, manually set playback rate; or re-export with -r 30 for the desired playback speed.

Game/screen recording plays too fast in Premiere. Almost always project frame rate mismatch (pattern 3). Set timeline to match the source rate.

Video plays at wrong speed only on YouTube after upload. YouTube transcodes uploads to a fixed frame rate (29.97/59.94 typically). If your file is 30/60 exactly with off-spec metadata, YouTube's interpretation may differ. Pre-transcode to match YouTube's expectation:

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

Is my footage safe? Server in France, auto-deleted after 48 hours, never used to train anything or shared. Privacy policy.

Upload your file →

मुफ़्त प्रीव्यू · कोई प्रतिबद्धता नहीं

क्या आप अपना वीडियो रिकवर करने के लिए तैयार हैं?

अपनी फ़ाइल अपलोड करें — लगभग एक मिनट में 5-सेकंड का मुफ़्त प्रीव्यू पाएँ। अगर प्रीव्यू सही लगता है, तो ही भुगतान करें।

अपना वीडियो अपलोड करें →