DaVinci Resolve Error: Clip Has Invalid Duration (Fix)

Is the file actually corrupted, or is this just a metadata problem?

Usually it's just a metadata problem, and that distinction matters because it changes what you should do next. A corrupted file has damaged picture or audio data. A metadata problem has an intact file with a wrong or missing description of that data's length, which is a much easier and safer thing to repair.

Per Repairit's explanation of the moov atom, "when recording suddenly stops, such as through unexpected device shutdown or power loss, the moov atom becomes missing," and this happens because "it does not know the video's duration while you are recording it," so the index can only be finalized once recording ends cleanly. Practical triggers include:

• A phone or camera battery dying mid-recording
• Force-quitting a screen recorder instead of stopping it properly
• A file transfer, upload, or cloud sync getting interrupted partway through
• A crash in the recording or editing app that wrote the file

None of these destroy the actual video frames sitting in the file. They just leave the "table of contents" describing that video incomplete, which is exactly the kind of mismatch that trips Resolve's duration check on import.

Quick diagnostic table

If the file plays cleanly start to finish in VLC, QuickTime, or your phone's own gallery app, treat it as a metadata problem, not data loss. Players like VLC are famously forgiving about broken headers and will often play a file Resolve won't touch, which tells you the video itself is fine and the fix is a remux or a transcode, not a data recovery job.

Does variable frame rate footage cause invalid duration errors?

Yes, and it's one of the most common real triggers behind this error. Variable frame rate, or VFR, footage records an irregular gap between frames instead of a fixed interval, and it's the default output of a lot of everyday recording tools, not an obscure edge case.

Dan Swierenga, writing for the Frame.io blog on mixed frame rates in Resolve, put it plainly: "Frame rates and metadata can be tricky. It isn't always clear from looking at the FPS metadata column what is going on with the files." (source) That ambiguity is exactly the gap VFR footage exploits. A VFR file's container often reports a single average frame rate, but the actual spacing between frames varies shot to shot. Resolve calculates duration by multiplying frame count against a constant rate, and when the real timing doesn't match that assumption closely enough, the reported duration and the decoded frame count disagree.

Variable frame rate turns a video file into a stopwatch that speeds up and slows down while claiming to tick at a constant rate.

Common VFR sources worth checking first:

• Screen recorders (OBS on variable-rate settings, macOS's built-in screen recording, most phone screen capture tools)
• Many Android phone cameras, particularly in low light where the sensor drops frames to expose longer
• Some iPhone modes, especially Live Photos exported as video and certain third-party camera apps
• Older GoPro and action cam firmware in specific recording modes

The fix is to convert the file to constant frame rate, CFR, before it ever reaches Resolve. HandBrake's own documentation describes its Constant Framerate setting as making "your new video exactly one frame rate throughout," which is the exact property Resolve needs to trust a duration calculation. Set HandBrake's Framerate mode to Constant, match the target rate to the source's nominal rate, and re-encode before reimporting. If you already read our guide on why a clip plays too fast because of the wrong frame rate, this is the same root cause showing up as a hard rejection instead of a playback speed problem. Sometimes VFR footage imports fine and just plays wrong; other times, when the mismatch is bad enough, Resolve refuses the import outright with an invalid duration error instead.

Can a broken or gapped image sequence trigger this error?

Yes, and this is one of the least intuitive causes because a still image doesn't obviously have a "duration" the way a video clip does. DaVinci Resolve constructs a sequence clip's length by counting consecutive, correctly numbered image files in a folder, and anything that breaks that numbering breaks the duration math along with it.

Per one image-sequence import guide, "DaVinci Resolve supports several image formats, including JPG, JPEG, TIFF, and EXR" for sequence recognition, and "inaccurate or missing numbers can confuse the software," preventing it from building one clean, continuous clip (source: Filmora's DaVinci Resolve image sequence guide). A single missing frame number, a duplicate number, or inconsistent zero-padding (frame_001.jpg next to frame_2.jpg) is enough to confuse Resolve's sequence detection.

Editors on the Blackmagic forum have separately reported that when a sequence contains missing frames, Resolve doesn't quietly skip the gap. Instead it splits what should be one shot into dozens or hundreds of tiny separate clips, one per unbroken run of consecutive numbers, each with its own tiny and frequently invalid duration (see the Blackmagic Forum thread on missing frames in an imported image sequence).

An image sequence with one missing frame doesn't shrink your shot. It splits it into dozens of unusable pieces, each one reporting its own broken duration.

A related and separately documented version of this problem hits single still images, not sequences. On the Blackmagic forum thread about clip duration stuck at 00:00:00:02 for images, users described images that wouldn't accept the standard still-image duration and instead locked at a two-frame length, flickering back to that value every time they tried typing in a new number. The reported workaround was making sure image filenames were unique with no trailing numbers, since Resolve's sequence detection can mistake a folder of similarly numbered stills for a fragmented sequence and gets confused about what duration each individual frame should carry.

How to fix a gapped or broken image sequence

1. Open the folder in a file browser and sort by name to visually confirm the numbering is continuous with no gaps.
2. Duplicate the nearest existing frame and rename the copy to fill any missing number, rather than leaving a hole in the sequence.
3. Make sure padding is consistent across every file (all four digits, or all five, never mixed).
4. Rename any single non-sequence stills so they don't share a numeric pattern with an unrelated sequence in the same folder.
5. Reimport the folder as a fresh sequence clip rather than trying to repair the broken one already in your Media Pool.

Why do GIFs and screen recordings throw invalid duration errors?

GIFs and many screen recordings share a structural quirk that video files don't have: neither format stores a single, authoritative duration the way an MP4 or MOV does. That absence is exactly the gap where this error tends to appear.

A GIF's timing isn't a duration field at all. It's a series of individual per-frame delay values, one attached to each frame in the file, and the total "length" of a GIF only exists as the sum of those delays. Different conversion tools handle rounding, minimum delay values, and looping metadata inconsistently, and a GIF converted by one tool can produce a total that a strict duration check like Resolve's doesn't reconcile cleanly with the frame count it actually decodes. There's been ongoing discussion on the Blackmagic forum about whether Resolve will natively support GIF import precisely because the format behaves differently from Resolve's native video pipeline.

Screen recordings run into the same problem from a different angle. Most screen capture tools, including OBS in certain encoder configurations and several built-in OS recorders, default to variable frame rate output for the exact reason discussed above: it's more efficient to only write a new frame when the screen actually changes, rather than duplicating identical frames at a fixed rate. That efficiency is great for file size and terrible for a strict duration check, since long stretches of an unchanging screen can compress the reported timing in ways a constant-rate calculation doesn't expect.

The fix for both is the same: convert before you import.

• For GIFs, convert to an MP4 or MOV first using a dedicated converter, or import as a numbered image sequence if you need frame-accurate control, rather than dragging the raw .gif into the Media Pool.
• For screen recordings, run the file through HandBrake or a similar tool set to Constant Framerate before bringing it into Resolve, the same fix as any other VFR source.

Does importing via XML, AAF, or EDL cause invalid duration on conform?

Yes, and this version of the error shows up on people who never touched a raw camera file directly. It happens during conform, the process where Resolve matches an imported timeline's edit decisions back to actual media on disk.

DaVinci Resolve's own reference manual dedicates a full section to conforming clips during XML and AAF import, because that handoff is where duration mismatches between two different applications' understanding of the same file most often surface. An XML, AAF, or EDL doesn't carry the media itself. It carries in and out points, expressed as timecode or frame numbers, that reference source files sitting somewhere on disk. If the exporting application and Resolve disagree about that source file's frame rate, or if the source file was re-encoded or trimmed after the edit was exported, the referenced in and out range can land outside what the actual file on disk supports, which reads to Resolve as an invalid duration rather than a simple offline clip.

This is closely related to Resolve's Mixed Frame Rate Format setting under Conform Options, which the reference manual documents as controlling how Resolve reconciles clips of different native frame rates during import. Get that setting wrong, or leave source media mismatched against the edit's expectations, and duration conflicts on conform are the direct result.

If you round-trip footage between Premiere and Resolve regularly, this pairs with a problem we've covered in more depth in our guide to DaVinci Resolve's XML import from Premiere Pro not working, which walks through the broader family of conform failures beyond just duration.

A timeline import doesn't fail because the edit is wrong. It fails because the file on disk stopped matching what the edit assumed about it.

What to check before you reimport an XML, AAF, or EDL

• Confirm the source media files are the exact same files, not re-encoded copies, that were used when the timeline was originally exported.
• Check that every clip's frame rate in the exporting application matches what Resolve reads for that same file.
• If the export included handles or head/tail room, verify the source files are long enough to actually contain that extra range.
• Re-export the timeline as a fresh XML or AAF rather than reusing an old one if any source media has changed since the original export.

Can scripts or the DaVinci Resolve API cause this error?

Yes, this is a real cause and one that's easy to overlook if you're not the one who wrote the script. DaVinci Resolve's scripting API lets Python or Lua scripts build timelines automatically, and one of its core functions, AppendToTimeline, places a clip using explicit startFrame and endFrame values pulled from the source clip.

The v20.3 Python scripting API reference documents this pattern directly, using int(video_clip.GetClipProperty("Frames")) - 1 to calculate a safe endFrame value (source: DaVinci Resolve Python Scripting API Reference, v20.3). That minus-one exists because frame indices in the API are zero-based, so the true last frame of a clip is one less than its total frame count. A script that skips that subtraction, hardcodes a frame range, or reads a stale frame count before a proxy or transcode finished can hand Resolve a startFrame and endFrame pair that doesn't correspond to a real, valid range inside the source clip.

If your team uses automation tools for batch imports, auto-editing plugins, or third-party integrations that talk to Resolve through its scripting API, a duration error appearing only on script-generated timeline items, and never on the same clips added manually through the Media Pool, is a strong signal the script's frame range math is the actual cause, not the source media.

The fix here isn't inside Resolve's interface at all. It's in the script: confirm frame counts are read after any transcode or proxy generation completes, and confirm endFrame is always calculated as frames minus one, not the raw frame count.

Can proxy media cause an invalid duration error?

Yes, and this version catches people who never had a problem with the original camera file at all. DaVinci Resolve treats a proxy as a stand-in for the original, but only if the two agree on a strict set of technical details, and a mismatch on any of them can surface as a duration conflict instead of a clear proxy warning.

Per a troubleshooting guide on proxy media in Resolve, the software demands "the exact same file name (excluding extension), the exact same audio channel count, and the exact same timecode" between a proxy and its source (source: Cutsio's guide to fixing proxy media issues in DaVinci Resolve). A proxy with four silent audio channels padded in to match a four-channel original is normal and expected. A proxy generated with a different starting timecode, or trimmed by a third-party transcoder that dropped a few frames off the head or tail, is not, and Resolve reads that overlap failure as an invalid range on the clip rather than a simple "proxy doesn't match" notice.

A proxy file only works if it agrees with the original down to the frame. Anything less and Resolve treats the whole clip as unreliable, not just the proxy.

This is most common when proxies come from outside Resolve entirely, generated by a camera's companion app, a separate transcoding tool, or a batch script that re-encodes footage without preserving the source timecode track. Resolve's own built-in proxy generation, reached by right-clicking a clip and choosing Generate Proxy Media, always preserves timecode and channel count automatically, which is why duration conflicts on proxies are rare when you let Resolve build them itself.

How to fix a proxy-related duration error

1. Right-click the affected clip in the Media Pool and unlink the proxy.
2. Delete the mismatched proxy file from wherever it's stored, so Resolve can't accidentally relink to it later.
3. Regenerate the proxy natively inside Resolve instead of reusing one from an external tool.
4. If you must use proxies from a third-party pipeline, confirm the tool preserves source timecode and audio channel count before you trust its output on an active project.

How do you check a clip's real duration before you touch anything in Resolve?

You check it with a dedicated media analysis tool, not by trusting what your operating system's file browser or a general media player tells you, since both can display a duration they've quietly guessed or rounded rather than one they've verified. The free tool MediaInfo is the standard choice among editors for exactly this reason, and it's the same tool we recommend readers reach for in our guide to DaVinci Resolve saying a clip has no video track, since both errors start with the same first move: find out what's actually inside the file before guessing.

Drag the problem file directly onto MediaInfo and read the report in its default view. Here's what to look for and what each result tells you:

If General > Duration and Video > Duration disagree by more than a fraction of a second, or if Frame rate mode reads Variable, you've confirmed your cause without opening Resolve at all. That confirmation matters because it tells you whether you're about to fix a source file problem (which you can) or chase a phantom setting inside Resolve (which doesn't exist for this error).

Worked example: diagnosing an OBS screen recording

Say a 12-minute OBS screen recording throws Clip Has Invalid Duration on import, but plays back fine in VLC. Here's how the diagnosis plays out using the table above.

Dragging the file onto MediaInfo shows General > Duration reading 12 minutes, roughly matching what you'd expect. But Video > Duration reads closer to 11 minutes and 40 seconds, a real gap rather than rounding noise. Video > Frame rate mode reads Variable. Frame count is present and non-zero.

That combination points straight at variable frame rate as the cause, not corruption. OBS defaults to VFR output in several encoder presets because it only writes a new frame when the screen content actually changes, which shrinks file size but produces exactly the kind of duration mismatch Resolve won't tolerate on import.

The fix follows the VFR path covered earlier in this guide: run the file through HandBrake with Framerate mode set to Constant, matched to OBS's nominal output rate (commonly 30 or 60 fps, check your OBS output settings to confirm), then reimport the converted file as a fresh Media Pool clip. Don't relink the original OBS recording to the converted file. Delete the broken import and drag the new one in clean, exactly as the general fix sequence below describes.

If General > Duration had instead read 0:00 or blank, with Frame count also missing, that would point to a genuinely incomplete index from an interrupted recording, which calls for a container remux or a dedicated repair tool instead of a frame rate conversion. The MediaInfo report is what tells you which of those two very different fixes actually applies before you spend time on the wrong one.

How do you actually fix Clip Has Invalid Duration in DaVinci Resolve?

You fix the source file or the way it was brought in, never a setting inside Resolve, since Resolve has no override for a duration it doesn't trust. Here's the sequence to work through, in order:

1. Confirm the file's real duration outside Resolve. Run it through MediaInfo first, as covered above, so you know which branch of this guide applies before you start changing anything.
2. Match your symptom to a cause. Use the table below to jump straight to your fix instead of trying every remedy in order.
3. Repair or transcode the source, never the Resolve import. Remux a corrupted container, convert VFR footage to constant frame rate, renumber a gapped image sequence, regenerate a mismatched proxy, or fix a script's frame range calculation, depending on which cause applies.
4. Reimport as a fresh Media Pool clip. Delete the broken clip from the Media Pool entirely and drag in the repaired file as a new import. Relinking the original broken clip to the fixed file often preserves the same cached duration metadata that caused the problem in the first place.
5. Clear the render cache and reconform any timeline that used the old clip. If the broken clip was ever placed on a timeline before you fixed it, go to Playback > Delete Render Cache > All, then place the new, repaired clip in fresh rather than relying on Resolve to automatically reconcile the old reference.

Cause-to-fix decision table

Worked example: remuxing a corrupted file with FFmpeg

If MediaInfo confirmed a genuine metadata problem, a command-line remux is often faster than hunting for repair software, provided you understand what it can and can't fix.

The free tool FFmpeg can repackage a file's existing audio and video streams into a new container without re-encoding them, using a command like:

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

That -c copy flag tells FFmpeg to copy the streams as-is rather than decode and re-encode them, which is fast and lossless. According to FFmpeg Cookbook's guide to the moov atom error, that command works by rebuilding the index, since the underlying frame data is intact and only the index describing it is broken or misplaced (source: FFmpeg Cookbook: Fixing the moov atom not found Error).

That same guide is explicit about where a remux stops working: "if the file is missing the moov atom because recording crashed, this command cannot repair it," since FFmpeg needs an existing index to read before it can copy anything into a new one. In that harder case, a dedicated recovery tool, or a reference file recorded on the same device with the same settings, becomes necessary to reconstruct a plausible index from scratch.

A remux can only rebuild an index that still exists somewhere in the file. It can't invent one that was never written.

For prevention, if you're re-encoding footage yourself, adding FFmpeg's -movflags +faststart flag writes that index at the front of the file instead of the end, which both speeds up progressive playback elsewhere and removes the specific failure window this whole guide is about, since there's no longer a final index write that a crash or interruption can catch mid-way.

If you'd rather have someone walk the actual dialog with you instead of matching a table to your screen, that's what TryUncle is for. It's an on-screen AI tutor for DaVinci Resolve on macOS: ask in plain words, and its assistant, Uncle, points at the exact control on your screen, whether that's the Relink button in the Media Pool or the render cache setting under Playback. It's a paid app at founder pricing, not a substitute for the fixes above, but it's one way to get an answer without leaving Resolve mid-troubleshoot.

What if the error keeps coming back after you think you've fixed it?

If you've repaired the source file and the error persists, the most likely explanation is that Resolve is still referencing cached information about the old, broken version of that clip rather than actually re-reading the fixed file. Three specific places hold onto stale state long enough to cause this:

Render cache. Resolve caches rendered frames and proxy data keyed partly to a clip's identity, and if that identity was established while the clip was still broken, a straightforward relink doesn't always force a full re-read. Go to Playback > Delete Render Cache > All and try again.

Relinking instead of reimporting. Right-click relinking a Media Pool clip to a fixed file is faster than reimporting, but it can carry forward cached duration metadata from the original broken import rather than reading the new file's metadata fresh. When in doubt, delete the broken clip entirely and drag in the repaired file as a brand-new import.

Timeline conform state. If the broken clip was ever placed on a timeline, the timeline keeps its own separate reference to that clip, called a conform, and that reference doesn't automatically update just because the underlying Media Pool clip got relinked. Right-click the clip on the timeline and choose Force Conform with Media Pool Clip, or remove and reinsert it fresh.

Project database corruption. Rare, but real. If invalid duration errors are appearing on clips that were previously working fine, with no changes to the source files, corruption in the project's own database is worth ruling out. Try creating a new project and importing the same media fresh. If the same clips error out in a brand-new project, the problem is genuinely the source file. If they import cleanly in a new project, something in the old project's saved state, not the media, was the actual cause.

Does this happen differently on Windows, Mac, and Linux?

Not in the core mechanism, since the duration check itself is part of Resolve's cross-platform media engine, but the codec and decoder differences between operating systems change which files are more likely to trigger it.

This matters practically because a file that shows "invalid duration" on Windows might show a different, codec-related error on Linux, and play with no complaint at all on macOS. If you're troubleshooting on Windows or Linux specifically, rule out a codec gap before you assume the duration itself is the whole problem. Our guide on DaVinci Resolve saying unsupported file format covers the platform-specific codec differences in more depth, since the two error families share more causes than their names suggest.

Is this different in the free version of DaVinci Resolve than in Studio?

No. Duration validation on import is part of Resolve's core media engine, and that engine is identical between the free version and Studio. Studio's differences are in encoding options, higher resolution and frame rate ceilings, AI-powered Neural Engine tools, and immersive audio, per Blackmagic's own tech specs page, not in how strictly it checks a file's duration metadata on the way in.

If a clip throws an invalid duration error in the free version, upgrading to Studio won't change that outcome, because the underlying file still has the same broken or mismatched metadata either way. The one place license tier does interact with this error indirectly is codec support on Linux, discussed above, where the free build's narrower decoder set can make a marginal file fail earlier and more completely than it would on Windows or Mac.

How do you stop invalid duration errors before they start?

The most reliable fix is never having the problem in the first place, and that comes down to a short ingest habit rather than a Resolve setting.

Before you import anything into a real project:

• Let recordings finish and stop cleanly. Avoid force-quitting a screen recorder or yanking a card before a camera has finished writing its final index.
• If footage comes from a phone, screen recorder, or action cam, check Frame rate mode in MediaInfo before you import a whole card's worth of clips. Catching one VFR file in a batch of thirty is far cheaper than troubleshooting it after the fact.
• Number image sequences with consistent, gapless, evenly padded filenames from the moment they're exported, not after the fact.
• Never edit a GIF's filename extension by hand to make it look like a video file. Convert it properly first.
• Generate proxies natively inside Resolve whenever possible, and if a third-party pipeline must produce them, confirm it preserves source timecode and audio channel count before trusting it on an active project.
• If you rely on scripted or automated imports, log frame counts at the point the script reads them, so a mismatch is traceable to a specific automation step instead of looking like a mystery Resolve error.

A duration error is your file's metadata failing a check, not your footage disappearing. Treat it as a five-minute diagnostic with MediaInfo, not a crisis, and in nearly every real case documented above, the actual video and audio you shot are sitting there completely intact, waiting for a container that describes them honestly.

The next time this error shows up, don't start clicking through Resolve's menus looking for a hidden fix. Open MediaInfo, find out which of the causes above actually applies to your file, and fix the file. That's the whole job, every time.