Seven ways a render lies to you

Seven failures and the mechanism behind each

An export that fails loudly is easy. The dangerous ones succeed and are wrong, and they are wrong in a small number of recognisable ways. Each of these has a cause you can name, which means each has a fix you can apply rather than a setting you can flail at.

1. The exported file looks washed out, or darker, than the timeline

This is the classic Mac gamma shift: Resolve shows the grade correctly, QuickTime plays the render noticeably lifted or crushed, and you regrade to compensate and now it is wrong everywhere else.

The cause is colour tagging. An H.264 or ProRes file carries metadata describing its colour primaries, transfer function and matrix. Some players trust that metadata, some ignore it and assume Rec.709, and some apply a further correction of their own. When the file is untagged or mis-tagged, two players disagree about the same bytes.

Fix it at the source: in Resolve's Deliver page, set the colour tag explicitly — Rec.709, Gamma 2.4 for broadcast or Rec.709-A for Apple-ecosystem web delivery — rather than leaving it automatic. Then verify by opening the render in two different players, and in a browser. Do not regrade to chase one player. You will be chasing it for ever.

2. Audio drifts out of sync over a long export

Not a constant offset, which would be a sync error from the edit. A drift that starts at zero and grows to half a second by the end.

The cause is almost always a variable frame rate source, or a sample-rate mismatch: 44.1 kHz audio in a 48 kHz timeline, resampled by something that rounded. Screen recordings, phone captures and game capture are the usual suspects.

Fix by converting sources to constant frame rate before import — the ffmpeg lesson has the command — and by keeping every asset at 48 kHz.

3. Green, black or garbled frames, usually near the start

The cause is hardware encoding or decoding. GPU encoders are enormously faster than software ones and occasionally produce broken output, particularly with older drivers or unusual resolutions.

Fix by switching the render to software encoding — in Resolve, the Advanced Settings on the Deliver page have a hardware acceleration toggle; in ffmpeg, use libx264 rather than h264_nvenc or h264_videotoolbox. It is slower and it is correct. If the corruption is in playback rather than export, turn hardware decoding off in preferences instead.

4. The export stops at 43% every time

A render that fails at the same point is telling you exactly where the problem is. Something at that timecode is unreadable: a partially copied file, a clip with a corrupt tail, a still image in a format the renderer cannot handle, a missing font.

Find it by bisecting. Set the render range to the first half. If it succeeds, the fault is in the second half; halve again. Four or five renders locates a single clip. Then re-transcode that clip to ProRes with ffmpeg and replace it — a transcode reads the file once, and it either succeeds, in which case you have a clean replacement, or it fails at the same frame, in which case you know the media itself is damaged and can go back to the card.

5. Silence on one platform, sound everywhere else

The cause is track layout. An export with four separate mono tracks plays as expected in a professional player and may be reduced to the first track, or to silence, by a consumer one. Or a stereo mix rendered with content only on the left plays silent in the right ear on headphones and perfectly on a phone, whose single speaker sums both.

Fix by rendering web deliveries as a single stereo pair, and checking the output on headphones before sending. Keep the multi-track version for broadcast, where the spec asks for it.

6. Motion judders although nothing juddered in the timeline

Two causes, and they look similar.

Frame rate conversion. A 25p timeline rendered at 29.97 must invent 4.97 frames per second, which it does by duplicating, and duplication under motion reads as a stutter. Match the timeline.

Field order. Interlaced material rendered with the fields swapped plays as a rapid back-and-forth judder on anything moving. If you are working with old broadcast material, check upper field first against lower field first, and prefer deinterlacing to progressive at import so the problem cannot reach the render at all.

7. The file is enormous, or absurdly small

Enormous usually means an intra-frame codec was selected by accident — ProRes where H.264 was intended — or that the quality slider was left at maximum with a bitrate ceiling removed.

Absurdly small usually means the render range was set to an in-and-out point you forgot about, and you have exported forty seconds of a nine-minute film. Always check the duration of the finished file against the timeline duration before sending anything. It takes two seconds and it catches a whole category of embarrassment.

The habit that prevents most of this

Render a 60-second test from the most difficult part of the timeline before committing to the full export. The difficult part means: the graded shot, the composited title, the section with the imported screen recording, the place where the music changes.

A minute of render tells you about gamma, about audio, about hardware artefacts and about file size per second, from which you can extrapolate the whole. Discovering a gamma shift after a four-hour 4K render is a particular kind of evening.

Honest limits

Some export failures are genuinely bugs in a specific version on specific hardware, and no amount of reasoning locates them. When you have bisected, switched to software encoding, checked the sources and it still fails, the remaining moves are: update or roll back the application, render in sections and join them, or render a ProRes master and convert with ffmpeg. The last of those works startlingly often, because it takes the editor's encoder out of the chain entirely.

Today

Render a 60-second test from the hardest minute of your current timeline. Open it in two different players and compare the brightness.