DaVinci Resolve Pixelated? Proxies and Viewer Fixes

You drop a clip on the timeline and it looks like a mosaic. Or the edit looked fine, you exported, and the file is soft and blocky. DaVinci Resolve has many places where quality is traded for speed, and a few of them are on by default or get switched on by accident.

The key question is the first one: is the pixelation in your footage, in the viewer, or in the export? The answer decides everything else. Here is how I would find out, in order.

Step one: look at the original file outside Resolve

Open the original clip in a plain media player, at full screen, and pause on a frame that looks bad in Resolve. If the clip looks clean there, your footage is fine, and the problem is in Resolve’s playback or render settings. If it looks blocky there too, the footage itself is damaged or low quality, and you are in a different situation (see why a video is pixelated).

This takes thirty seconds and prevents hours of fiddling with settings that do not matter.

Step two: proxy mode and optimized media

Resolve can use two kinds of stand-in files to make editing smoother: proxy media and optimized media. They are lower-resolution or easier-to-decode copies of your clips. When they are in use, the viewer shows them instead of the original, and they can look soft or blocky.

How to check:

• In the Playback menu, find Proxy Mode. If it is set to Half Resolution or Quarter Resolution, the viewer shows reduced quality.
• In the Playback menu, also look at Timeline Proxy Resolution.
• In the project settings, under Master Settings, look at the Optimized Media and Render Cache sections to see what resolution they are set to.

If you have generated proxies, a media-pool clip may use the proxy file when Proxy Mode is on. Turn it off, and the viewer goes back to the original. Do not be alarmed if playback gets slower, because that is the whole reason proxies exist.

Step three: the viewer’s own resolution

The viewer has a separate quality setting. In the Playback menu you can choose timeline resolution options such as full, half and quarter, and the viewer may also show a lower resolution while playing back to keep up. If playback stutters, Resolve may drop to a lower resolution on the fly.

Pause on a frame. If the picture sharpens when you stop, it is a playback resolution setting, not damage. If it stays blocky when paused at full resolution, look further.

Also check that the viewer is not zoomed above 100 percent. Zooming into a 1080p frame on a big display simply enlarges pixels, which looks blocky and is normal.

Step four: timeline resolution

Your timeline has its own resolution, set in the project settings under Master Settings. If your footage is 4K and your timeline is 1280 by 720, Resolve scales everything down, and your export will be 720p. If your footage is 720p and your timeline is 4K, everything is scaled up and looks soft.

Match the timeline to your delivery size. For 4K footage delivered at 1080p, a 1920 by 1080 timeline is fine. Resolve scales cleanly at render time, and the scaling quality is controlled by the setting in the next step.

Also look at the Image Scaling settings in the project. The Mismatched Resolution Files option controls how clips that do not match the timeline are scaled. Common choices are Center crop with no resizing, Scale entire image to fit, and Stretch. Pick one that suits your footage, since an accidental stretch or crop produces softness.

Step five: render cache

Smart Cache and render cache store pre-rendered frames for effects-heavy sections. If you set the cache to a low-quality format, such as a lightweight codec at a reduced resolution, you may see blocks in cached sections that disappear when the cache is off.

To check, turn off the cache temporarily from the Playback menu (Render Cache, None), and see if the blocks vanish. If so, change the cache format in Master Settings to a higher quality codec, or just leave it off for color work.

Step six: the export settings

If the viewer looks fine and the exported file is bad, the deliver page is the next suspect. Look at:

Resolution and frame rate. Match your timeline, or the delivery target.

Codec and quality. For H.264, the quality setting offers Automatic, Best, High, Medium, Low and Restrict to a bitrate. If you chose Restrict to and typed a low number, such as 2,000 kbps, your 1080p file will look blocky. A 1080p video at 2 Mbps is thin. In my bitrate test on a 1080p clip, 2 Mbps gave 34.7 dB PSNR against 38.7 dB at 4 Mbps and 42.7 dB at 8 Mbps, and 0.5 Mbps looked like a paint smear. For delivery, 10 to 16 Mbps for 1080p is a safe choice, more for 60 fps.

Advanced Settings. Here are options named something like “Use optimized media if available”, “Use proxy media if available” and “Use render cached images”. If proxy media is checked, the export can use the low-resolution files. Uncheck those for a final render. Also look at “Force sizing to highest quality” and “Force debayer to highest quality”, which matter when scaling or when working with RAW footage.

Encoder. Resolve’s hardware encoders (NVENC and similar) are fast, but at a given bitrate software encoding can look slightly better. If you are chasing quality, try the software option and compare.

I covered the logic of export bitrates in why a video looks pixelated after exporting.

Step seven: the footage’s codec and decoding

Long-GOP H.264 and HEVC footage from phones and cameras is heavy to decode. When a computer cannot decode it in real time, Resolve may drop frames or show glitchy blocks during playback, particularly after a cut or when scrubbing. The picture often fixes itself after a moment, or looks fine when you stop.

This is not damage in your footage. The cures are proxies, optimized media, or transcoding the clips to an editing-friendly codec before you start. Variable frame rate footage from phones can also confuse the timeline, producing stutter. Converting such clips to a constant frame rate, in a tool like FFmpeg, before importing avoids it:

ffmpeg -i phone_clip.mov -r 30 -c:v libx264 -crf 14 -preset slow -c:a copy phone_clip_cfr.mp4

Using a low CRF here keeps the copy close to the original. Be aware that this is a re-encode, so use a high quality value.

Step eight: color work can reveal blocks

Compressed footage, especially 8-bit H.264 from phones, has little room for aggressive grading. When you push contrast, lift shadows or crank saturation, you expose banding and block edges that were hidden. This is not Resolve being pixelated, but a limit of the footage. The fixes are: shoot in a higher quality mode if you can (10-bit, higher bitrate), grade more gently, add a light denoise before the grade, and consider adding a subtle grain at the end to hide banding.

For noisy low-light footage, the next article, grainy low-light fixes in CapCut, Premiere and DaVinci, goes into the noise reduction tools.

Step nine: how to use proxies without wrecking the export

Proxies are good. A 4K H.264 file on a laptop can be unusable without them. The key is a clear workflow:

1. Generate proxies from the media pool (right click, Generate Proxy Media), at half or quarter resolution, with a lightweight codec.
2. Turn Proxy Mode on while editing, to keep playback smooth.
3. Before the final render, turn Proxy Mode off, and make sure the deliver settings do not use proxy media.
4. Render, and check the output in a separate player at full size.

Many “my export is pixelated” posts come from skipping step 3.

Why a round trip through several tools adds up

Resolve users often move footage between programs: a phone app, a converter, an editor, a render, an upload site. Each step that re-encodes the video takes a bit more from it. I measured how much with a plain test. I took a 5 second 1080p clip and encoded it with x264 at CRF 23, then encoded the result again at CRF 23, and so on, five times, comparing each generation to the original.

Generation	File size	PSNR vs original	SSIM
1	3,806 kB	41.57 dB	0.9802
2	3,464 kB	39.88 dB	0.9714
3	3,243 kB	38.84 dB	0.9642
4	3,083 kB	38.09 dB	0.9579
5	2,959 kB	37.50 dB	0.9523

The first generation is the largest drop in absolute terms, but the next four still cost more than 4 dB combined, and the file shrinks every time, because each pass throws away more fine detail that the next one cannot recover. At CRF 23 the early generations are hard to spot by eye. By the fifth, soft areas and edges are visibly weaker.

The practical lesson for Resolve: edit from the camera originals, render once at a good quality, and avoid using a previously exported file as a source if you can. If you must work from an already compressed file, such as a download, render at a high quality setting to avoid adding more loss. A low-loss intermediate codec for in-between steps, like ProRes or DNxHR when you have the disk space, avoids the repeated damage altogether.

Reading what the viewer is really showing you

It helps to know which of Resolve’s displays is trustworthy for judging quality.

The viewer during playback is the least reliable. It may drop resolution, skip frames and use cached or proxy data. Use it for timing and flow.

The viewer when paused at 100 percent zoom, with Proxy Mode off and the cache off, is a fair look at the decoded footage and the effects applied.

The rendered output played in a separate player is the truth. Always do your final check there, on the device where the video will be seen. If you export a short test section, a few seconds around the most difficult part, you can check it in a minute rather than waiting for the full render.

Make a habit of rendering a ten second test of the worst part of your timeline with the exact delivery settings. It shows bitrate problems, noise problems and scaling problems while you can still fix them cheaply.

Common settings mix-ups that look like pixelation

Wrong playback frame rate. The timeline frame rate differs from the footage, so frames are repeated or blended. Motion looks jerky, and combined with compression it reads as poor quality.

Retime and speed changes. Slow motion on footage that was not shot at a high frame rate relies on frame interpolation, which can produce smeared or blocky frames. Use optical flow at its higher quality setting, or shoot at a higher frame rate for slow motion.

Heavy sharpening in the color page. Strong sharpening exaggerates compression noise, and the encoder then has more difficult material to compress.

Noise reduction on at the wrong place in the node tree. Noise reduction should usually come early. If it is applied after color changes have exaggerated the noise, it works harder and smooths more.

Resize filter set to a soft option. In the project’s image scaling settings, the resize filter choices include bicubic, bilinear and sharper options. In my scaling test from 480p up to 1080p, the gap between good filters was small, about 0.2 dB between bicubic and lanczos, and bigger between them and nearest neighbour or bilinear, so the default is usually fine. Do not expect the resize filter to be the reason for heavy blockiness.

Hardware and memory problems

If the viewer shows odd colored blocks or flashes of corrupt frames, especially with GPU effects on, the cause may be a graphics driver or a GPU memory shortage rather than the footage. Signs are that the problem happens at different frames each time you play, and that it goes away after restarting Resolve or lowering the GPU memory load. Update the graphics driver, close other GPU-heavy programs, and try a smaller timeline resolution as a test.

If a clip shows pink or green blocks and the original does not look like that in another player, the file may have corrupted data that Resolve decodes badly. See how to fix a corrupted video file for a repair ladder.

A note on relinking and moved files

If you move or rename your original files, Resolve may fall back to proxies or show offline media. A clip that shows as the proxy only, with the original missing, will export at proxy quality or show the offline media frame. Keep the originals in place, or relink them from the media pool, before the final render.

A practical order of attack, if you are in a hurry

When a project is due and the picture looks bad, work in this order and stop as soon as it looks right:

1. Pause on a bad frame, set the viewer to 100 percent, and turn Proxy Mode off.
2. Turn the render cache off and check again.
3. Open the original clip in another player. If it is bad there, the footage is the issue.
4. Check the timeline resolution against the footage and the delivery size.
5. Render a ten second test at your delivery settings, with proxy media and cache options unchecked, and look at it in a separate player.
6. If the test is blocky, raise the bitrate or quality setting, or reduce noise in the footage.

Most of the time, the answer appears by step two or three, and a fresh render fixes the rest.

When the source is the weak point

If the footage was a low resolution download or a compressed screen recording, no Resolve setting will rescue it. You can reduce the damage before editing: deblock, denoise, and scale up with a good filter, then import the cleaned version. A cleanup pass takes a few minutes for a short clip, and you can see what it does on your own footage with the free preview.

What I would not bother with

Some popular suggestions rarely help. Reinstalling Resolve almost never fixes a blocky viewer, since the cause is a setting stored in the project or user preferences. Buying a faster computer will smooth playback, but it will not change the export quality. And switching codecs without changing the bitrate or quality value just moves the problem around. Settings and source quality decide the result, so put your time there.

Summary

Pixelation in Resolve is almost always a setting. Check the original in a separate player first. Then turn off proxy mode, make sure the viewer is at full resolution, match the timeline to your delivery size, disable or upgrade the render cache, and on the deliver page use a sensible bitrate with proxies and cache turned off. If the footage is heavy to decode, use proxies for editing, not for output. And if the source itself is damaged, clean it before it goes on the timeline.