Video Duration Shows 0:00 — How to Fix

The file is hundreds of megabytes (or gigabytes). The Finder / Explorer preview thumbnail might even be showing. But the duration reads 0:00 in QuickTime, Finder's Get Info, Premiere's import dialog, and ffprobe. The video apparently has no length.

This is almost always a metadata issue, not a content issue. The video data is in the file. The information that says how long the video is — that's what's missing or broken.

Where duration lives in an MP4 / MOV

The duration is stored in the mvhd atom (movie header) inside MOOV, and also per-track in tkhd and mdhd. All three should agree. If MOOV is missing entirely, all three are missing — duration reads as 0 because there's nothing to read from.

Three patterns:

Pattern 1: MOOV is missing → duration shows 0

Same root cause as MOOV atom not found: the recording was interrupted before the index was written. The duration field doesn't exist anywhere in the file.

Tell-tale: the file is large but ffprobe returns "moov atom not found" and duration is reported as 0 or "N/A".

This is the most-recoverable case.

Pattern 2: MOOV exists but has timescale = 0 or duration = 0

The MOOV is there; the duration field inside mvhd is set to zero (or the timescale is zero, which makes the displayed duration zero by division). This sometimes happens with partial-write MOOVs that didn't finish populating duration before the camera died.

Tell-tale: ffprobe returns a stream count and codec info but a duration of 0 or N/A. The file plays but the player can't seek and shows no progress bar.

Often fixed by a re-mux that recomputes duration from frame timestamps:

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

FFmpeg recalculates duration from the codec-level timestamps and writes a fresh MOOV.

Pattern 3: integer overflow on very long recordings

Less common. Some old tools store duration as a 32-bit value with a high timescale, which overflows for recordings longer than a few hours. The value either wraps to a negative number or reads as zero.

Tell-tale: the file is from a multi-hour recording (security camera, livestream, long event). FFmpeg's re-mux fixes this by writing a 64-bit duration where needed.

How to figure out which pattern

ffprobe -v error -show_format broken.mp4

Look at the output:

If duration is real but wrong — e.g. file shows 12 minutes but the recording was actually 47 minutes — that's a separate "wrong duration" pattern, usually a timescale mismatch. Re-mux with FFmpeg fixes it most of the time.

What you can try yourself

For pattern 1: see the MOOV recovery guide.

For patterns 2 and 3, the simplest fix is FFmpeg re-mux:

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

This rewrites the MOOV with duration computed from frame timestamps. It usually works.

If -c copy doesn't fix duration, force re-encode of the audio stream (which reliably regenerates timestamp metadata):

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

If neither works, the timestamp data in the codec stream is also damaged and you're in the harder recovery territory.

How our recovery handles zero-duration files

• Pattern 1 — full MOOV synthesis from frames. Duration is computed from the count and timing of detected frames in mdat.
• Pattern 2 / 3 — MOOV is reconstructed from scratch (we don't trust the existing one). Duration written with 64-bit values when the recording length warrants it; timescale chosen to match the codec's natural rate.
• co64 for files over 4 GB so chunk offsets don't overflow alongside the duration fix.

What you do

1. Upload the file.
2. Free 5-second preview ~1 minute later. Duration in the recovered file will show the actual recording length.
3. Pay only if it works.

FAQ

My file shows the right duration in VLC but 0:00 in QuickTime. Permissive vs strict reader. VLC computes duration from frame timestamps even when MOOV says 0; QuickTime trusts MOOV. Re-mux fixes both.

The file is from a security camera / dashcam — duration is wrong on multi-hour recordings. Likely pattern 3 (integer overflow). FFmpeg re-mux with current builds fixes this in most cases.

My recovered file has a duration but the player won't seek. Often a missing stss (sync sample table) — the player has duration but no keyframe map to seek to. Recovery rebuilds stss from observed IDR / keyframe positions.

I get duration zero on a file from another tool's recovery. Their recovery may have produced a partial MOOV. Upload the original (pre-recovery) file — we'll redo it from scratch.

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

Related

• MOOV atom not found
• Cannot find essential data
• How our recovery engine works

Upload your file →