Transcode ladder cost per rung

An adaptive-bitrate ladder is one source encoded several times at several resolutions. Everyone knows the top rung is the expensive one. Here is how expensive, measured.

Short version. The 1080p rung cost more encode time than the other four rungs combined. And because our source is 720p, that rung is an upscale, so it bought 2.3x the bytes and 4x the time in exchange for no detail that was not already there.

Variant	Encode	Size	Cost
1080p	3853 ms	992.3 KB	$0.0063
720p	944 ms	433.0 KB	$0.0023
480p	598 ms	265.3 KB	$0.0027
360p	458 ms	188.0 KB	$0.0023
240p	289 ms fastest	80.1 KB	$0.0017

Measured 2026-08-20 on the Rendobar API. Encode time is the FFmpeg step alone, separated from download and upload. 5 of 5 runs succeeded. Sizes are exact and repeatable. Timings are a single sample and vary up to 2x run to run, so treat small differences as noise. Why.

The top rung is most of the bill#

The four lower rungs together take 2,289 ms. The 1080p rung alone takes 3,853 ms, which is 1.7x the rest of the ladder put together.

That is the shape to remember. Encode cost scales with pixel count, so each rung down is roughly a quarter of the one above, and the sum of everything below the top rung is smaller than the top rung. A ladder is not five equal costs. It is one big cost and four rounding errors.

The upscale trap#

Our source is 1280x720. The 1080p rung scales it up to 1920x1080 before encoding.

That rung cost 3,853 ms and 992 KB to deliver exactly the detail the 720p rung already had, stretched. There is no new information in it. An upscaled 1080p stream is a 720p stream that costs 4x as much to make and 2.3x as much to store and serve.

This happens constantly in real pipelines, because ladders are configured once as a fixed list of rungs and then pointed at whatever arrives. User-generated content arrives at every resolution, and every 720p upload silently pays for a 1080p rung that cannot improve on it.

The fix is to cap the ladder at the source resolution, which in FFmpeg is the force_original_aspect_ratio and min family of expressions rather than a hardcoded target. Probing the input first and dropping rungs above it is the single highest-value change most ladders can make. Reading the real dimensions back out of a file is one ffprobe call, and it is the call that makes the rest of this decidable.

The bottom rungs are nearly free#

240p cost 289 ms and produced 80 KB, which is 18% of the 720p rung’s bytes and under a third of its encode time.

That is worth knowing when someone proposes dropping the low rungs to save money. They are not where the money is. They are what keeps the stream playable on a bad connection, and they cost almost nothing to produce. Cut the top, not the bottom.

What the whole ladder cost#

Five rungs, $0.0154 in total, producing 1,959 KB across all outputs.

Scaled up, that is the real planning number: the full ladder costs 6.8x what the single 720p rung costs on its own, and most of that multiple is the top rung. If your source is 1080p and the top rung is genuine rather than an upscale, that multiple is money well spent. If it is an upscale, you are paying it for nothing.

Where this stops#

One 5-second 720p clip, libx264 at CRF 23 preset medium, audio stripped, so the figures are pure video encode. A real ladder would use per-rung bitrate caps rather than a flat CRF, which changes the size column but not the shape of the cost curve. That trade is measured separately in CRF versus target bitrate, and the preset choice that sets the per-rung floor is in x264 presets compared.

The pixel-count relationship is the durable part. Whatever your content, the top rung dominates and the bottom rungs are close to free.