Corrupted render output files are usually incomplete writes, and most can be prevented by rendering image sequences and verifying every file.
Pipeline Brief // File Integrity, Prevention & Recovery
A practical look at why finished renders turn out unreadable, which output formats fail badly, and what can and cannot be recovered afterwards.
- Video Output Is Fragile: a default MP4 stores its index (the moov atom) at the end of the file, so a crash, full disk or killed process can leave a file that no player can open.
- Image Sequences Fail Small: one bad frame costs one frame. Blender’s manual itself advises rendering PNG or OpenEXR sequences first and encoding video afterwards.
- “File Exists” Is Not “File Is Good”: skip-existing and no-overwrite options work from file names, so a truncated or empty frame can be treated as finished work.
- Recovery Is Limited: tools such as untrunc can rebuild some truncated MP4 files, but they need a similar working video and success is not guaranteed.
- Practical Fix: write sequences, verify every frame after the job, and re-render only what fails. See how to find and re-render broken frames. Never trust a file because it exists.
Corrupted render output files are the failure you discover last: the job reports success, the progress bar hit 100%, and then the file will not open, a frame is cut off halfway, or a compositor refuses to read a sequence. This guide explains what actually goes wrong at the file level, how to design output so it survives interruptions, and what recovery options are realistic.
Contents
What causes corrupted render output files?
Almost every corrupted render file is an incomplete write. The renderer or a farm worker was stopped, ran out of space or lost its connection before the file was finished, and the operating system kept whatever bytes had arrived. This is different from a render that completes with wrong pixels, such as black frames, which is covered in The Render Finished but Half the Frames Are Black.
| Cause | Typical result | Prevention |
|---|---|---|
| Crash, power loss or killed process mid-write | Truncated frame, or video with no index | Image sequence output, per-frame verification |
| Disk or quota full | Short files, failed writes | Estimate output size first, monitor free space |
| Network share drops or stalls | Partial or zero-byte files | Render to local disk, copy afterwards, compare sizes |
| Several machines writing the same file | Overwritten or interleaved output | Unique frame numbers per file |
| Interrupted upload or download of results | File differs from what was rendered | Compare size or checksum after transfer |
Why do video files corrupt more often than image sequences?
A video file is one long object that is only valid once it is finalised. By default, FFmpeg’s MP4 muxer writes the moov atom, the index that tells a player where every frame lives, at the end of the file. If writing stops before that point, the frame data may be on disk but nothing describes it, so the file cannot be decoded. The FFmpeg formats documentation describes the faststart flag, which moves the index to the start in a second pass, and fragmented MP4 options (such as frag_keyframe), which keep the file decodable up to the last completed fragment if writing is interrupted.
An image sequence has no such shared index. Each frame is its own file, so a crash can damage at most the frame being written. Blender’s manual recommends exactly this approach: it advises against rendering directly to video and suggests rendering PNG or OpenEXR sequences first, then combining them, partly so you can restart from a failed frame (Blender manual, Output properties). The manual also lists Autosplit Output for video, which splits files larger than 2 GiB.
How do you prevent corrupted render output files?
Preventing corrupted render output files is mostly about choosing output that fails small and checking it before anyone relies on it. These steps apply to any renderer and any farm, whether automated, remote workstation or in-house.
- Render sequences, encode later. Use EXR, PNG, TIFF or similar for the render, then make the MP4 or ProRes from the finished sequence. If you must write video directly, prefer fragmented or hybrid options where your encoder supports them.
- Estimate output size before starting. Multiply a test frame’s size by the frame count and AOV or layer count, then compare with free space on every disk involved, including the farm’s result storage.
- Render locally, move afterwards. Writing straight to a network share exposes every frame to network hiccups. Copying finished files and comparing sizes or checksums afterwards is easier to verify.
- Give every frame a unique name. In After Effects, for example, the Deadline After Effects documentation notes that the “Use Comp Frame Number” option must be checked, otherwise every frame tries to write to the same file.
- Turn on minimum file size checks. The same Deadline page describes a Minimum Output File Size setting that requeues a task if its output is smaller than the threshold, and an option to delete files under it. Set the threshold from a known-good frame, with margin, because simple frames compress smaller.
- Verify after the job, not during. Run a decode check over every file (next section) before deleting scene files or releasing the farm machines.
How do you check whether a rendered file is actually valid?
To find corrupted render output files, check by decoding, not by file size alone. For video, a full decode that discards the output reports errors without writing anything. The FFmpeg documentation shows -f null - as a null output and -v error to limit logging to errors, so the combination below is a standard integrity test (this exact command is our assembly of those documented options, not a quoted example):
ffmpeg -v error -i render.mp4 -f null -No output and an exit code of 0 mean FFmpeg decoded every packet without reporting errors; it does not prove the picture looks right. A truncated MP4 with no index fails immediately with a “moov atom not found” message, which confirms the index problem described above.
For OpenEXR sequences, the OpenEXR project ships exrcheck, which reads files to validate their contents (exrcheck documentation). Its -m and -t options avoid excessive memory allocation and excessive time, with the caveat that some files will then not be fully checked, so avoid those flags for a real audit. The -c option adds core library checks. The documentation does not describe the exact error output, so test it once against a deliberately truncated copy before wiring it into a script.
A quick first pass for any sequence is to list file sizes and look for zero-byte files, gaps in the frame numbers, and sizes far from the neighbours. It catches the common cases cheaply, but only a decode proves a file is readable.
Why can skip-existing and placeholder options hide corrupted frames?
These options exist so several machines, or a restarted job, can share one output folder without repeating work. They work from what is on disk, not from whether a file is complete. Blender’s Output panel offers Overwrite (“Overwrite existing files when rendering”) and Placeholders (“Create empty placeholder frames while rendering”); the manual suggests disabling Overwrite and enabling Placeholders for rendering on several machines into one directory. That works because the placeholder is an empty file that claims the frame, so an empty file is a normal state mid-render, and a crashed machine can leave one behind.
After Effects multi-machine rendering depends on a similar mechanism. The Deadline documentation states it requires “Skip existing frames” to be enabled for each composition in the render queue, so a damaged frame left by an earlier attempt can be skipped on restart unless something deletes it first. The practical rule: after any interrupted job that used these modes, delete zero-byte and undersized frames before resubmitting, or use the minimum-size check described above. How a specific farm treats these cases differs, so confirm with its documentation. For the broader recovery workflow, see Rendering Overnight and Waking Up to a Crash.
Can you recover a corrupted render file?
Sometimes, depending on format. The honest ranking of corrupted render output files from most to least recoverable:
| Situation | Realistic option | Outlook |
|---|---|---|
| One bad frame in a sequence | Delete it and re-render that frame only | Reliable, costs one frame |
| Fragmented MP4 interrupted | Play or remux the completed fragments | Good up to the last full fragment |
| Standard MP4 or MOV missing its index | untrunc with a similar working video | Possible, not guaranteed |
| Truncated single image | Usually re-render | Partial data may open but is not trustworthy |
The untrunc project says it restores truncated mp4, m4v, mov and 3gp files, provided you have a similar working video, ideally from the same camera, and some luck; if the reference does not match, the chances of a fix are slim (untrunc on GitHub). For a render, a sensible reference is a few seconds encoded with the same settings and software version. Treat any repaired video as a rescue copy: check it frame by frame, and re-encode from the sequence if you still have it. Where the render took days, the repair attempt is worth trying, but do not plan a schedule around it.
What should you do on a render farm?
Farms differ in how they store and return results, so the safe habits against corrupted render output files are the same everywhere: request image sequences rather than a single movie, download the whole set, and run your own verification before you delete anything on the farm side. Compare the number of files with the frame range you submitted and confirm sizes look consistent. Some farms retain results for a limited time, so check the retention period in the farm’s own documentation before relying on re-download. If a file differs between farm and local copy, re-download before assuming the render is bad. For how farms handle errors on their side, see how render farms handle failed frames.
Conclusion
Corrupted render output files are mostly a design problem. Sequences instead of single videos, local writes instead of fragile network paths, minimum-size checks and a decode pass at the end turn a lost night of rendering into a handful of frames to redo. Recovery tools exist, but they are a last resort.
FAQ
Why does my rendered MP4 not play after a crash?
A default MP4 keeps its index (the moov atom) at the end of the file. If the render or encoder stops before the file is finalised, the video data exists but nothing describes it, so players cannot open it. Running ffmpeg with the error log level typically reports that the moov atom was not found.
Can I recover a corrupted MP4 from an interrupted render?
Sometimes. The untrunc tool attempts to restore truncated mp4, m4v, mov and 3gp files if you supply a similar working video, but success is not guaranteed. If you still have the frames, re-encoding from the image sequence is the reliable route.
Is an image sequence safer than rendering straight to video?
Yes, for interruptions. Each frame is a separate file, so a crash damages at most the frame being written, and you can re-render only that frame. Blender’s manual recommends rendering PNG or OpenEXR sequences first and encoding video afterwards.
How do I check every frame of a sequence for corruption?
List the files and look for zero-byte files, missing frame numbers and sizes far from their neighbours, then run a decoder over each file. For OpenEXR, the exrcheck tool reads files to validate their contents. Test your script once against a deliberately truncated copy.
Why did my render farm skip a frame that was damaged?
Skip-existing modes work from files already on disk. A truncated or empty frame left by an earlier attempt can be treated as done unless it is deleted first or a minimum file size check removes it. Check your farm’s documentation for how it handles this.
COMMENTS