All posts
By Pravit Gandhi··12 min read

Why your 4K render is taking hours

Why is my 4K render taking 20 hours? The real causes in order, the local fixes that actually work, and the honest answer when the machine is the limit.

Twenty hours for a six minute 4K video is not normal, but it is also not mysterious. A render that slow is almost never one problem. It is a stack of them, and each layer multiplies the one below it. The useful move is to find out which layer you are actually stuck on before you change anything, because the fixes are cheap and specific once you know, and expensive and useless when you guess.

The ladder below goes from most common to least. Work down it in order rather than skipping to the bottom, because a fix applied to the wrong rung looks like it did nothing.

Time the right thing first

Before touching a setting, get one number: how long does the same timeline take to export at a low resolution with all effects disabled?

If that is still slow, your problem is decode or disk, and it is on the input side. If it is fast, your problem is on the output side, in effects or encode. This single test separates two completely different sets of fixes, and skipping it is why so many render threads end with the person having changed nine settings and improved nothing.

A second useful number: watch whether the render slows down as it goes. A render that starts at a reasonable pace and settles into a crawl after ten minutes is a thermal story, not a settings story. That one has its own rung below.

The cause ladder

One: the source codec has to be reassembled before it can be seen

This is the most common cause by a wide margin, and it is invisible in every settings menu.

Camera H.264 and H.265 are long-GOP codecs, which means most frames on your timeline do not exist as pictures. Frame.io's codec guide sets out the three types: I-frames get spatial compression only and act as the reference for the rest, P-frames are predictive and rely on a frame earlier in the sequence, and B-frames are bidirectional and can pull data from frames earlier or later. To display one arbitrary B-frame, the decoder has to find the nearest I-frame, decode forward through everything between, and often decode a future frame too.

Compare that with an intermediate codec. Apple's ProRes white paper puts it in one line: in ProRes, "each frame is encoded and decoded independently of any other frame." No reconstruction, no dependency chain, no seeking penalty. That difference is the entire reason professional post has used intermediates for decades, and it is why a 4K ProRes timeline can render faster than a 4K H.265 timeline whose files are a fraction of the size.

The trap here is that file size fools people. A small file is not a cheap file. Long-GOP is small precisely because it made the decoder do more work.

Two: something on the timeline needs more than the current frame

Effects are not equally priced. Most of them look at one frame and are effectively free at export. A few look at many frames, and those are the ones that turn a render into an overnight job.

Temporal noise reduction is the headline offender. Blackmagic lists temporal and AI spatial noise reduction among the tools in DaVinci Resolve Studio, and temporal noise reduction works by comparing a frame against its neighbors to separate noise from detail. That means every output frame requires several input frames to be decoded and analyzed, which is expensive on its own and catastrophic on top of long-GOP source, because now each of those neighbor frames also has to be reconstructed.

Optical flow retiming, stabilization, and motion estimation of any kind belong to the same family. So does anything applied on an adjustment layer spanning the whole timeline, because it runs on every frame including the ones that did not need it.

Three: no hardware encoder is doing the encoding

Modern machines contain dedicated silicon for video encode and decode that has nothing to do with the CPU or the GPU's shader cores. If your software is not using it, the CPU is doing by arithmetic what a fixed function block was built to do.

NVIDIA's support matrix documents NVENC, its hardware encoder, covering H.264, HEVC and AV1, and NVDEC, its decoder, covering MPEG-2, VC-1, H.264, H.265, VP8, VP9 and AV1. Apple's Mac mini specifications list a media engine on M4 and M4 Pro with hardware accelerated H.264, HEVC, ProRes and ProRes RAW, a video decode engine, a video encode engine, a separate ProRes encode and decode engine, and AV1 decode.

Whether your editor reaches for any of that is a settings question. Adobe's own hardware encoding notes describe dedicated H.264 and H.265 encoders from NVIDIA and AMD on Windows, note that an Intel CPU with Quick Sync support can also be used for hardware encoding, and state that on macOS hardware encoding runs through Video Toolbox. The same notes list the exclusions worth knowing before you go hunting: VBR 2 pass and 5K and 8K H.264 export are not supported by hardware encoding, and Premiere Pro uses only one GPU for it.

On the decode side, Puget Systems' testing of hardware decoding in Resolve notes that the Studio version has long been able to use hardware decoding, and that whether any particular file qualifies depends on the capability of the hardware in your system. Bit depth and chroma subsampling both matter. A 10-bit 4:2:2 clip and an 8-bit 4:2:0 clip from the same camera can take completely different paths.

Four: the machine cannot hold the clock it started at

If the render begins briskly and degrades, you are watching thermal throttling.

Puget Systems' guide to it is blunt about the mechanism: most CPUs have a maximum allowable temperature somewhere between 95C and 110C, usually 100C, and once the maximum is reached, the automatic reduction in power that prevents additional heat also produces lower clock speeds and slower computation. That guide does not single out laptops, but the mechanism explains why they suffer most, since one cooling system serves both CPU and GPU inside a chassis with very little room for air.

This rung is why laptop render times are so hard to predict. The first minute tells you what the machine can do. The next three hours tell you what it can sustain.

Five: the delivery format itself is expensive

Sometimes the render is slow because you asked for something genuinely large.

Apple publishes ProRes target data rates at 1920 x 1080 and 29.97 fps: roughly 45 Mbps for ProRes 422 Proxy, 102 for 422 LT, 147 for 422, 220 for 422 HQ, 330 for 4444 and 500 for 4444 XQ. Apple also states that a ProRes format's data rate is determined primarily by codec type, encoded frame size and frame rate, so moving to 4K multiplies those figures by the change in frame area. A 4K ProRes 4444 master is a very different ask from a 4K H.265 upload file, and if you are rendering the former when the client needs the latter, the slowness is self-inflicted.

Resolve users have one more constraint to check. Blackmagic's product page draws the free versus Studio line at virtually all 8-bit formats up to 60fps at up to Ultra HD 3840 x 2160 for the free version, with 10-bit video up to 120 frames per second and resolutions beyond 4K in Studio.

The fix ladder

Same order, matched to the causes above.

Transcode or proxy the source

This is the highest return fix available and most people skip it because it feels like extra work.

Final Cut Pro's approach is a useful template because Apple documents exactly what it does. Optimized media transcodes to ProRes 422 for better editing performance and faster render times. Proxy media transcodes to ProRes 422 Proxy or H.264 at frame sizes from 12.5 percent to 100 percent of the original, and Apple notes that the original media is always retained. Resolve calls the same two ideas optimized media and proxy files. Premiere has proxies too.

The important detail is what you render from. Proxies exist so that editing is responsive, and you switch back to full resolution masters for the final export. But if your export is the thing that is slow, a full transcode of the source to an intraframe intermediate is the fix, not a proxy, because then the final render also reads intraframe files.

Audit the timeline for the frames-plural effects

Turn off noise reduction and re-export the low resolution test from earlier. If the time collapses, you have found it.

Then decide whether you need the noise reduction at all, or need it only on the four shots that were underexposed. Applying it globally on an adjustment layer to catch those four shots costs you the whole render. This is the render-time version of a broader point about applying decisions per clip versus per scene, which we made in do you have to color grade every clip. If the noise came from lifting underexposed log, the real fix was upstream, which is the subject of why your S-Log3 footage looks washed out and how to expose S-Log3 correctly.

Turn the hardware encoder on, and pick the right one

In Premiere, that means selecting a hardware option in the export settings encoding preference. In Resolve, the deliver page exposes the encoder choice per format. On Apple Silicon, the media engine is doing the work when the codec is one it supports.

Then check you have not disqualified yourself. Per Adobe's notes, asking for VBR 2 pass, or an H.264 export above 4K, drops you back to software encoding without announcing it. If you turned hardware encoding on and nothing changed, that is the first thing to look at.

Give the machine air and one job

Raise the laptop so its intakes are not flat against a desk. Run the export on mains power rather than battery. Close the browser with forty tabs open. Do not render and edit at the same time.

None of this is glamorous and all of it pushes back the point where the machine starts throttling. It does not turn a twenty hour render into a twenty minute one. It buys back whatever you were losing to heat, which on a hot laptop is not nothing.

Match the delivery codec to where the file is going

Render one master in the format the archive needs, if it needs one, and one delivery file in the format the destination wants. Rendering an H.265 upload file from a ProRes master you already made is fast, because the source is now intraframe. Rendering both from the original long-GOP camera files twice is the slow way to arrive at the same place.

When the ladder runs out

Sometimes you do all of that and the answer is still six hours, because the machine is what it is and the deadline is tomorrow. At that point the problem has stopped being a settings problem and become an architecture one: the render is happening on the wrong computer.

There are three honest options.

A desktop with a current GPU is the most straightforward. It fixes throttling by having room to cool, it fixes hardware encode by having a modern encoder block, and it stays fixed. It also costs money you may not want to spend, and it does nothing for you tonight.

A render farm is the traditional distributed answer, and for heavy VFX or animation work it remains the right one. For an ordinary graded timeline it tends to be more setup than the job deserves.

The third is rendering in the browser, which is where our product sits, disclosed plainly. Leumos AI is a browser-based AI color grading studio: upload your edit, and it detects scene cuts, grades every shot to match a reference image, and renders 4K ProRes or H.265 in the cloud — no GPU and no install required. The relevant part for this page is that the encode is not happening on your laptop, so thermal ceilings, missing encoder blocks and long-GOP decode on a weak CPU stop being your problem. The input side is ACES based, with transforms for Canon Log, Log 2 and Log 3, S-Log2 and S-Log3, ARRI LogC, V-Log, F-Log, N-Log, Apple Log, Log3G10, BMDFilm and GoPro Protune.

The limits are worth stating with equal clarity. It grades and renders, it does not edit, so picture has to be locked in your NLE first and exported as one file. It is a color tool, not an NLE, with no audio, no titling and no timeline editing. And it is in closed beta as of Q3 2026, so it is not something you can put on tonight's deadline.

If you are weighing browser tools generally rather than ours specifically, we compared the category in the best browser color grading tools, and the workflow question of grading without a heavy install is covered in how to grade log footage without DaVinci Resolve. If the slow render is on a multicam job where the grade is also fighting you, why your cameras don't match is the companion piece.

Frequently asked questions

Why is my 4K render taking 20 hours for a six minute video?

Almost always long-GOP source material being decoded frame by reconstructed frame, plus at least one effect that needs multiple frames, plus a software encoder doing work a hardware block could do. Run the low resolution, effects-off test first to find out which of the three dominates, then fix that one rather than all of them.

Why is my render slow when my CPU and GPU are barely being used?

Low utilization with slow output usually means the bottleneck is serial. A single threaded decode stage, a disk that cannot feed the pipeline, or an effect that cannot be parallelized will all leave your monitoring graphs looking idle while the render crawls. Transcoding the source to an intraframe codec is the fix that most often moves this particular needle.

Does turning on hardware encoding hurt quality?

At sensible bitrates the difference is small, and for delivery files bound for a streaming platform that will re-encode them anyway, it is usually irrelevant. Where it matters is archival masters and heavy grading downstream, and there the answer is not to use a hardware H.264 encoder at all, it is to render an intraframe master.

Will more RAM make my render faster?

Rarely, unless you were actually running out and swapping to disk. Render time is dominated by decode, effect processing and encode. RAM only becomes the limit at very high resolutions, with large caches, or when several applications are competing. Check whether the machine is paging before spending anything.

Sources