Measure once instead of predicting from specifications
The reason generic render-time predictions do not work is that the answer depends on the interaction of half a dozen things nobody can look up: the source format, the effects on the timeline, the output codec, how much of the work sits on dedicated hardware, how the software schedules it, and whether the machine can sustain its peak speed for an hour without heat forcing it back down. A table of hardware against times cannot capture any of that, which is why such tables are consistently wrong for real projects.
A measurement can. Export sixty seconds of representative footage, time it with a stopwatch, and you have a ratio that already contains every one of those variables for your machine, your project and your settings. Multiply out and you have an estimate that is worth something. The word representative is doing real work in that sentence: exporting the title card gives a ratio that describes exporting title cards.
The render ratio and what it tells you
A ratio of 1.0 means the export runs at real time — a twenty-four minute timeline takes twenty-four minutes. Below 1.0 is faster than real time. Above 1.0 the machine is doing more work than simply reading and writing frames, and the further above, the more of the time is going into something specific: an effect that cannot use the hardware encoder, a source format that has to be decoded expensively, or a scaling and colour operation on every frame.
That makes the ratio diagnostic as well as predictive. If a simple cuts-only timeline exports at 0.4 and adding a colour pass takes it to 6, the colour pass is not slightly expensive, it is the entire job. That is worth knowing before you spend anything on hardware, because the fix might be a proxy workflow, a cached intermediate, or one badly chosen plugin rather than a new machine.
Why the estimate splits heavy sections out
Timelines are rarely uniform. A documentary edit might be forty minutes of straightforward cuts and four minutes of stabilised, noise-reduced, heavily graded material that runs five times slower. Applying an average ratio to the whole thing is fine if the test clip happened to be average, and badly wrong if it did not.
| What is on the section | Typical effect on the ratio | Whether it can be moved |
|---|---|---|
| Cuts and simple transitions | Baseline | Nothing to move |
| Colour correction and grading | Moderate, often hardware accelerated | Sometimes, by rendering a graded intermediate |
| Noise reduction and stabilisation | Large, frequently the dominant cost | Yes — render those clips once and cut with the result |
| Motion graphics and nested sequences | Large and unpredictable | Yes, by pre-rendering to a flat clip |
| Scaling from a higher source resolution | Moderate and constant across the timeline | Only by changing the delivery format |
The rightmost column is where the useful decisions live. Anything that can be rendered once and reused stops being a cost you pay on every export, and if you are exporting several deliverables from one timeline that saving multiplies.
The error band is the honest part
An estimate built from a single sixty-second measurement deserves a wide band, and thirty percent either way is not pessimistic. Several things push the real figure up and comparatively few push it down. Sustained load makes the machine hot, and a hot machine runs slower than a cold one, so the second hour is slower than the first minute — which means a short test systematically overestimates speed. Background work steals capacity unpredictably. A single clip in an unusual format can dominate a section. Memory pressure on a long timeline can turn a smooth job into a crawl.
This is why the range is asymmetric in practice even though the arithmetic is symmetric: plan around the high end. If a job has a deadline, the number that matters is the one you would not be embarrassed to have promised.
Making the number smaller
Before buying anything, four things are worth trying, roughly in order of how often they help. Render heavy effects into intermediates so the cost is paid once. Check whether the export settings are actually using hardware encoding, since a setting change is occasionally worth more than a hardware upgrade. Make sure the storage is not the bottleneck, which is easy to test by watching whether the drive or the processor is saturated. And schedule long exports for when you are not waiting, since eight hours overnight costs nothing and eight hours during the working day costs a day.
If the export is going out as a stream rather than a file, the constraint moves from the machine to the connection and the streaming bitrate calculator is the relevant one. If it is going to storage, the video file size calculator sizes the output and the storage array capacity calculator deals with where a year of those files ends up. And if the machine is drawing several hundred watts for hours at a time, that is a heat problem as much as a cost one, which the case airflow calculator takes on.
Questions people ask
Why is my second export slower than the test clip suggested?
Almost always heat. A machine starting cold runs at its highest sustained speed for the first minutes and then settles back as temperatures rise and the firmware reduces clocks to stay within limits. A sixty-second test measures the fast part; a two-hour export spends nearly all of its time in the slower steady state. This is the single most common reason a short measurement overestimates. If you want a tighter band, time a five-minute section instead of a one-minute one and take the ratio from that.
Does more memory make renders faster?
Only if you were short of it, and then dramatically. Below the amount a project needs, the system starts moving data to disk and the export slows by far more than the memory shortfall suggests. Above that point, extra memory does nothing for render speed at all. The test is to watch memory use during a real export: if it is pinned near the limit and the disk is busy, more memory will help; if there is room to spare, it will not. This is worth checking before spending, because the symptom of being slightly short looks like a slow machine rather than a memory problem.
Should I trust an estimate the software itself shows?
For the first minute, no. Most progress estimates extrapolate from work completed so far, so they are wildly optimistic while the export is on the easy opening section and correct themselves later, sometimes upward by a large factor. They become reasonable at around the halfway point. The value of a calculated estimate is that you have it before you start, which is when it is useful for deciding whether to run the job now or overnight.
Is exporting in sections a good idea?
For long jobs, often. The total time is slightly higher because the fixed overhead is paid per section, but a failure at ninety percent costs you one section instead of the whole export, and you can start reviewing the early parts while the rest runs. The cost is that joining the sections is another step with its own opportunity for error, and re-encoding at the join point loses a little quality unless the format allows a clean concatenation. Worth it above a few hours, rarely worth it below one.
How do I get a ratio for a job I have not shot yet?
Use the closest comparable project you have already exported and widen the error band substantially — fifty percent rather than thirty. A ratio from a past job on the same machine with similar footage and a similar effects load is a genuinely useful starting figure. A ratio from a different machine, a different codec, or someone else's workflow is not, and it is better to say the estimate is unknown than to build a schedule on one.