Video Render Time Calculator (From a Timed Test Render)

Background.

This calculator will not ask what graphics card you own, and that is the point. There is no honest way to predict render time from hardware specifications: codec, preset, effect stack, resolution, colour management, GPU versus CPU path, disk throughput, cache state and the actual content of the frames all move the answer, and none of them is published anywhere as a constant you could look up. Any tool that takes a CPU model and hands back hours is inventing its coefficients. This one contains no hardware table, no codec factor and no efficiency fudge. Every throughput figure comes from your own machine.

What it does supply is the part people get wrong by hand: the frame arithmetic, the linear extrapolation and the parallel division. There are two ways in.

The first is a timed sample. Render a short, representative section, time it on the clock, and the calculator scales that measurement to the whole job. This is the most reliable estimate you can get, because the sample already contains everything a specification sheet cannot — your codec, your effects, your machine, your storage, on this project. FFmpeg is built around exactly this workflow: the -t option will "stop writing the output after its duration reaches duration", and -stats logs encoding progress by default, so a one-line command gives you both halves of the measurement. Every editing application can do the same by exporting an in-to-out range.

The second is seconds per frame, which is how frame-based renderers and render managers think. AWS Deadline Cloud's own terminology is explicit about it: a task "is the smallest unit of work" and "in rendering jobs, a task often renders a single frame", while a step "often defines the command for rendering a frame and uses the frame number as the task parameter". If your renderer prints a per-frame time, that number is all you need.

Both routes converge on the same three lines. Frames equals running time times frame rate. Total single-machine time equals frames times seconds per frame. Wall-clock time equals that, divided by the number of machines working in parallel. Nothing else is going on, and nothing else is assumed.

A word about that division, because it is the one place this page could mislead you. Dividing by the worker count is a best case. Real fleets scale sublinearly, and the reason is in the same AWS documentation: sessions "often have setup actions which configure environments and load assets before running the task actions". Every worker pays that setup, every worker pulls the same textures over the same network, and licences and storage bandwidth are shared. Doubling a two-machine farm usually gets close to halving the time; doubling a two-hundred-machine farm often does not. Treat the parallel figure as the floor and add your own margin.

The outputs are built for planning rather than for reassurance. Alongside the wall-clock time you get the frame count, the per-frame cost, the realtime factor — how many minutes of machine time each minute of finished video costs — and the fleet's frames per hour, which is the number you actually need when you are working backwards from a delivery deadline to a farm size.

What is video render time calculator?

Render time is the wall-clock duration a machine needs to turn a timeline or a 3D scene into finished frames. It is not a property of the footage and it is not a property of the computer alone; it is a property of a particular project on a particular machine with a particular set of settings, which is why it can only be measured rather than predicted. The standard way to express it is either as seconds per frame, which is how frame-based renderers and render-management systems schedule work, or as a multiple of real time, which is how video encoders report progress — a 2x factor means a ten-minute video takes twenty minutes to export. This calculator converts between those two views and scales either of them to a full job. It takes a measurement you made, works out how many frames the finished piece contains, multiplies, and divides by however many machines are working in parallel. It deliberately contains no assumptions about hardware, because assumptions about hardware are exactly what makes other render-time estimates wrong.

How to use this calculator.

1. 01Pick how you know your speed. Choose the timed sample if you are exporting an edit; choose seconds per frame if your renderer reports per-frame times, which most 3D renderers do.
2. 02For the timed sample, render a genuinely representative section — a stretch carrying your heaviest grade, noise reduction or effects, not thirty seconds of slate. An unrepresentative sample is the main source of error in this method, not the arithmetic.
3. 03Enter the length of the finished piece and its frame rate. Use the real rate: 29.97 rather than 30, 23.976 rather than 24. Those are 30/1.001 and 24/1.001, and rounding them costs you about 3.6 seconds of frames per hour.
4. 04Enter the number of machines rendering in parallel. Leave it at 1 for a single computer.
5. 05Read the wall-clock figure, then read the realtime factor beside it. The factor is the number worth remembering, because it stays true for the rest of the project: at 2.4x, any cut of any length will take 2.4 times its own running time to export on that machine with those settings.
6. 06If you are sizing a farm, work from frames per hour instead. Divide the frames you have to deliver by the hours you have left, then raise the worker count until the throughput clears it — and add margin, because the parallel division here does not model per-worker setup.

The formula.

Start with the unit of work. A render is a sequence of frames, and the number of them is the running time multiplied by the frame rate: twelve minutes at 30 fps is 720 seconds times 30, or 21,600 frames. Use the exact rate here — 29.97 fps is 30/1.001, so an hour of it is 107,892 frames rather than 108,000, and rounding the rate up costs you 108 frames an hour of imaginary work.

Next, the cost of one frame on one machine. In seconds-per-frame mode you supply it directly. In timed-sample mode it is derived: the wall-clock time of the sample, divided by the number of frames the sample contained, which is itself the sample's duration times the frame rate. A 60-second sample at 30 fps is 1,800 frames, so a 144-second render works out at 0.08 seconds per frame.

Multiply the two and you have the single-machine job: 21,600 frames at 0.08 seconds each is 1,728 seconds. Divide by the number of machines to get the wall clock. With one machine that is 1,728 seconds, or 28 minutes 48 seconds.

The realtime factor is the render time divided by the running time of the piece — here 1,728 divided by 720, which is 2.4. Notice that this is the same as the sample's own factor, 144 divided by 60. It has to be: the extrapolation is linear, so the ratio is scale-invariant. That is what makes the factor worth writing down. It is a property of your project and machine that stays true whatever length you export next.

Fleet throughput inverts the per-frame cost: 3,600 seconds in an hour, divided by the seconds per frame, multiplied by the number of workers. At 0.08 seconds per frame one machine delivers 45,000 frames an hour.

The assumption doing all the work here is linearity, and it is worth naming. Frame times are assumed constant across the project, and workers are assumed to add throughput without interfering. Neither is exactly true. A title sequence with heavy compositing costs more per frame than a locked-off interview, and every machine you add pays its own scene-loading and asset-transfer overhead. The estimate is therefore a floor, and a good one — but it is a floor.

A worked example.

Frequently asked questions.

References& sources.

1. [1]AWS, Deadline Cloud User Guide, "Concepts and terminology". Source of the per-frame unit of work and the parallel-worker model: "A task is the smallest unit of work in Deadline Cloud... In rendering jobs, a task often renders a single frame"; a step "often defines the command for rendering a frame and uses the frame number as the task parameter"; "Workers are part of a fleet and execute tasks from jobs". Also the basis for the sublinear-scaling caveat: "Sessions often have setup actions which configure environments and load assets before running the task actions."
2. [2]FFmpeg documentation, ffmpeg.html. Source for the timed-sample method: "-t duration ... When used as an output option (before an output url), stop writing the output after its duration reaches duration", and "-stats ... Log encoding progress/statistics as 'info'-level log (see -loglevel). It is on by default, to explicitly disable it you need to specify -nostats." The -progress option additionally sends "program-friendly progress information" for scripted timing.
3. [3]Recommendation ITU-R BT.2020-2, Table 2, Picture temporal characteristics: "Frame frequency (Hz) 120, 120/1.001, 100, 60, 60/1.001, 50, 30, 30/1.001, 25, 24, 24/1.001". Source for treating 23.976, 29.97 and 59.94 as exact fractions when converting a running time to a frame count.
4. [4]SMPTE ST 12-3:2016, section 6.4.2. States the fractional relationship directly — a television system "operating at a frame rate multiple of 30/1.001 frames per second" — which is why an hour of 29.97 material is 107,892 frames rather than 108,000.