Video Compression Artifacts After Rendering: Render and Export Settings That Help

A render can look clean in the viewport and then fall apart in the exported file: blocky shadows, smeared detail, ringing around edges. Video compression artifacts after rendering come from the encoder, and they can usually be reduced with better export settings.

This guide gives five fixes in the order that matters most. Every value below comes from the Blender Manual, the FFmpeg H.264 encoding guide, Apple’s ProRes white paper or YouTube’s upload guidance. Where an official source was not found, the text says so.

Why do video compression artifacts appear after rendering?

Artifacts appear because delivery codecs throw away information to shrink the file. Video compression artifacts after rendering get worse when the bitrate is low, the quality setting is aggressive, or the encoder uses a fast preset. Blender’s manual describes H.264 as a widely used lossy codec with a strong compression-to-quality ratio, and notes that a codec must be available on both the system that encodes the file and the device that plays it.

We found no official source stating that noise or grain makes artifacts worse, so treat that as our interpretation: detailed, noisy frames need more bitrate to survive. YouTube’s page also does not describe quality loss from its own re-encoding, so we cannot document that either.

Fix 1: Render an image sequence, not a video file

To limit video compression artifacts after rendering, render to an image sequence and encode afterwards. Blender’s manual states that it is not recommended to render directly to a video format in the first instance. A sequence keeps every frame uncompressed or lightly compressed, so you can re-encode if the first export looks wrong, and a crashed render does not lose finished frames.

In Blender’s Output properties, the media type Image saves each frame as a separate file, while Video encodes frames into a video container. We could not verify PNG or EXR specifics for other renderers from official pages, so check your renderer’s output formats.

Fix 2: Lower the CRF value

CRF is a constant-quality setting where a smaller number means better quality and a larger file. Lowering it is the quickest way to reduce video compression artifacts after rendering. The FFmpeg H.264 guide documents the 8-bit scale as 0 to 51, with 0 lossless, 23 the default and 51 the worst quality, and suggests a sane range of 17 to 28. Blender’s manual says the same direction: a smaller CRF gives better video quality at a larger file size.

If blocking is visible, drop the CRF a few points and compare. The manual’s Encoding panel also lists Keyframe Interval and Max B-frames; longer intervals generally mean smaller files but need a more capable player.

Fix 3: Use a slower encoder preset

A slower preset gives better quality at the same file size, at the cost of encode time, which makes it a cheap defence against video compression artifacts after rendering. The FFmpeg guide lists presets from ultrafast to placebo, with medium as the default, and says slower presets deliver more quality per file size. It recommends against placebo.

Blender’s manual describes its Encoding Speed option as a choice between a fast encode with a bigger file and more compression with a smaller file. For a final delivery file, a slow preset is rarely the bottleneck compared with the render itself.

FFmpeg also states that two-pass encoding targets a file size and does not improve quality over CRF, so use CRF when quality is the goal.

Fix 4: Keep a high-quality master and encode the delivery file once

Archive a high-quality master and make each delivery file from it, so quality is lost only once. Apple’s white paper states that ProRes 422 HQ is 10-bit and holds up through many generations. Apple’s listed target rate for ProRes 422 HQ at 1920 by 1080 and 24 frames per second is 176 Mb/s.

For the delivery encode, the FFmpeg guide advises the yuv420p pixel format because some players, QuickTime among them, support only 4:2:0 H.264. Our interpretation: encoding from a master rather than from a previous compressed export avoids stacking artifacts. For gradient problems that survive the encode, read banding in gradients after rendering.

Fix 5: Upload at or above the platform’s recommended bitrate

Match the upload to the platform’s specification when you want to limit video compression artifacts after rendering. YouTube recommends H.264 High Profile in an MP4 container with 4:2:0 and BT.709 for SDR, and lists bitrates by resolution and frame rate. These are recommendations, not guarantees that no artifacts will appear.

Keep the source frame rate and use the container details the page lists. If a long animation makes test exports slow, the render farm comparison explains how to move the rendering step elsewhere. The wider quality series is in Fixing Render Noise and Flicker.

Sources

• Blender Manual, video formats (main branch source): projects.blender.org; Output properties: docs.blender.org (5.2 LTS, checked 30 October 2026)
• FFmpeg, Encode/H.264 guide: trac.ffmpeg.org (accessed 30 October 2026)
• Apple ProRes White Paper: apple.com (April 2022 edition)
• YouTube recommended upload encoding settings: support.google.com (checked 30 October 2026)

FAQ