Estimate video render time from duration and encoder speed

Enter the program duration, output width and height, video frame rate, and the encoder throughput you have measured at that resolution. The calculator converts duration into a frame count, divides those frames by the encoder speed, and returns a readable render time alongside the exact estimate. It also shows the real-time factor so you can quickly see whether the encoder is expected to finish faster or slower than playback.

Start with measurements that describe the same job

A useful render estimate depends on consistent inputs. Duration should describe the complete timeline that will be encoded, including titles, credits, or padding that remains in the export. Frame rate must be the actual output rate rather than a rounded label copied from a project name; for example, 29.97 and 30 frames per second produce slightly different frame totals over a long program. Width and height record the target output resolution. They do not directly change the arithmetic because encoder throughput is already expressed as frames processed per second, but they make the estimate auditable: a throughput result measured for one resolution should not be reused blindly for a substantially larger frame. Measure encoder speed with the same codec, preset, bit depth, filters, hardware, and resolution whenever practical. If you only have an early benchmark, use a conservative throughput figure rather than the best momentary reading. The result is an operational estimate, not a guarantee, because real encoders can slow down on complex scenes, thermal limits, or competing workloads.

Understand the calculation and the real-time factor

The calculator first multiplies duration in seconds by the output frame rate to obtain the number of frames in the job. It then divides that frame count by the measured encoder throughput in frames per second. A two-minute, 30 fps program contains 3,600 frames; an encoder sustaining 60 fps needs about one minute to process it. The reported real-time factor is encoder throughput divided by program frame rate. A value above one means the encode is faster than playback, a value of one means approximately real time, and a value below one means the encode is slower than playback. Resolution is included in the output so benchmark records remain tied to their intended raster size. Fractional frame totals can occur when decimal duration is combined with fractional frame rate. The tool preserves that mathematical estimate rather than silently changing the supplied duration. Displayed render time is rounded to the nearest millisecond, while numeric fields use stable decimal rounding for predictable API and browser results.

Plan a schedule with realistic safety margin

Treat the result as the active encoding time under the conditions represented by your speed measurement. A full delivery schedule may also need time for source transfer, cache preparation, audio analysis, multipass setup, file muxing, checksum generation, upload, and quality control. Those stages are not represented by an encoder speed measured in frames per second, so add them separately. For a batch, calculate representative jobs at the slowest expected throughput, then include a margin based on past variance. If a system reports unstable performance, a lower percentile throughput is more useful for deadlines than an average boosted by easy scenes. Recalculate when you change resolution, codec, preset, denoising, scaling, color conversion, or hardware acceleration, because each can materially change throughput. The estimate costs $0.002 per API request, while the tier-A browser path can run the same deterministic calculation locally. No media is uploaded: the calculation uses only the numeric properties you enter, and it does not inspect or encode a video file.