← All articles

The DaVinci Resolve "punch in" on the first and last frames of an export

September 20, 2026

You export a clip from DaVinci Resolve, open the file to check it, and something is off at the very start. For a few frames the image is zoomed in slightly, then it snaps back to normal and plays clean the rest of the way. The same thing happens at the tail. A little pop at the head, a little pop at the end.

The maddening part is that the timeline looks fine. Scrub it, play it, loop the in and out points — the punch isn't there. It only appears in the exported file. So you re-export, and it's still there.

If you've been searching for this, you already know it isn't just you. There's an active Blackmagic Design forum thread from April 2025 describing exactly this, and no official fix in it. Blackmagic hasn't acknowledged it as a formal bug. That's the frustrating state of things: real, repeatable, and unowned.

What's actually happening

The punch shows up on clips that carry a timeline effect — a transform or resize, a stabilization, or an optical-flow retime — and most often when you're exporting clips individually rather than one long timeline.

The head and tail frames end up rendered at a slightly different scale than the rest of the clip, which has settled into its intended transform. So the first and last few frames read as zoomed in, and everything in between is correct. It's a boundary problem, right at the edges of the render.

That also explains the thing that makes this so confusing: it does not happen on every clip. A clip with no transform, no stabilization, and no optical-flow retime exports clean. Only the ones carrying that kind of effect pop. So half your batch looks perfect and the other half has a flicker at each end, with no obvious reason why.

The fix that gets repeated but often doesn't work

The most common advice you'll find is to set "Add 0 frame handles" in the render settings. It sounds right, and sometimes people report it helped. But plenty of shooters already have handles set to 0 and still see the punch. If that were the whole story, it wouldn't be a recurring thread with no resolution. Treat it as one thing to check, not the answer.

Worth testing in Resolve first

Before you reach for anything else, two things are worth trying. Either may or may not fix your particular case — this bug doesn't behave the same for everyone — but they're quick and they cost nothing.

Do these on one clip, not your whole batch. You're diagnosing, not committing.

The reliable fix: trim the bad frames

Here's the honest version of what this bug is. The punch is a handful of wrong frames at each end of an otherwise perfect clip. The dependable way to deal with a few bad frames at the head and tail is to trim them off. Not re-render the timeline, not fight the render settings — just remove the frames that popped.

That's what MetaMule's new Fix step does, automatically. It:

Fix is the first stop in the MetaMule pipeline: Fix → Prep → Tag & Export → Deliver. You clean the export, then prep, keyword and export to each marketplace's format, then deliver.

Why this matters if you sell the footage

If you contribute to Getty, Pond5, Adobe Stock, or Shutterstock, a popped frame isn't just ugly. A reviewer scrubbing your clip can land on one of those zoomed frames and read it as a technical flaw, and a technical flaw is a reason a clip gets bounced. Even when it clears review, a buyer previewing the file sees a stutter at the open. On footage you're asking people to license, the first frame is doing a job.

So it's worth fixing, and it's worth fixing in a way that leaves the good frames exactly as you graded them. Trim the few that broke, keep the rest untouched, and move on to keywording.

MetaMule cleans the Resolve punch-in for you

The Fix step detects which exported clips actually popped, trims only the affected head and tail frames in batch, and stays lossless on ProRes — then hands off to keywording and export.

See how MetaMule works