Per-title encoding and the cost of a one-size ladder
A slideshow with a talking head and a football match can both be encoded at 5 Mbps for 1080p. One of them will look the same to most viewers at half that, and the other will smear every blade of grass. A fixed ladder treats them the same because the ladder was written before the video arrived.
Complexity decides the bits
How many bits an encoder needs for a given quality depends on the content. Flat backgrounds, slow camera moves and little motion compress well, because most of each frame is predicted from the last one. Grain, fast pans and water compress badly, because the prediction misses and the difference has to be coded. Two files with the same resolution and frame rate can differ several times over in the bitrate they need to look good.
A fixed ladder has to pick one number per rung that survives the hardest content you expect. Simple titles then carry bits nobody can see. Hard titles may still fall short of the quality you wanted at their top rung. You are overspending on one end and underserving the other, with the same ladder file.
Per-title means measuring first
The usual approach is to encode a title at several bitrates and resolutions, measure quality for each, and plot quality against bitrate. For each resolution that gives a curve that rises steeply and then flattens. Plot the curves for 360p, 720p and 1080p together and they cross: at low bitrates a smaller resolution looks better, at higher bitrates the larger one wins. The upper envelope of those curves is the convex hull, and the points on it are the efficient choices. Rungs go where the hull is. An easy title's hull reaches the target quality at a lower bitrate, so its ladder is cheaper.
That is the concept. I did not build a real hull search, because the lab does not encode anything. Cloud Video Lab has a ladder mode of fixed or per-title, and a content complexity setting of low, medium or high. They are teaching parameters, and the source says so: model parameters, not measured encoder output.
COMPLEXITY_FACTOR = { low: 0.6, medium: 0.85, high: 1 };
REDUNDANT_RATIO = { low: 1.6, medium: 1.3, high: 0 };
Every rung's bitrate is multiplied by the factor and keeps its resolution. Then a middle rung is dropped if it sits within the ratio of the rung below it. The top and bottom rungs always survive. On the lab's four-rung preset (1080p at 5 Mbps down to 360p at 0.8 Mbps, selected with the Ladder = 4 setting and not the default, which is three rungs), low complexity gives 3, 1.5, 0.72 and 0.48 Mbps. The 480p rung is 1.5 times the 360p one, under the 1.6 limit. It goes, and the ladder has three rungs. At high nothing changes, which is the point: hard content gets the full ladder.
Where the saving lands
A cheaper ladder does not make everything cheaper. The lab prices a run in five stages, from ingest through transcode, package and storage to egress. Per file, the ladder changes two things. Encoded minutes follow the number of rungs, so dropping a rung cuts them. Packaged and stored gigabytes follow the bitrate, so lower bitrates cut those. Bitrate alone does not change encoded minutes. The run totals can still rise if more files finish in the window. Ingest does not move, because the source is landed once whatever the ladder is.
Egress is measured from what the simulated CDN served to the simulated viewers, so it follows how the player behaves on the new ladder. A lower top rung means fewer bytes per second watched. It can also mean a viewer on a fast connection gets a softer picture, which is a quality cost the dollar column does not show.
The comparison has one trap that the code comments on directly. In a VOD window, the per-title side can show a higher encode cost per hour simply because more files finished in the same time. So the VOD compare adds two rows. Files finished is one. Encode cost per finished file is the other, and it is the fair read: throughput and unit cost are different questions. Live runs do not have those rows.
Pricing the same work two ways
Cloud Video Lab can also price one measured run on two providers. The topology and the simulated traffic are identical on both sides, so the end-to-end timing row matches and only the price lines differ. Run the fixed and the per-title ladder on the same seed (the lab uses one, 674) and the ladder is the only variable.
Each price entry in the lab is a list price stored with the page and date it was read from, so I won't quote any here. Most of them are flagged unverified in the UI, which is another reason. What the lab does show is the shape of the bill. Encode cost is paid once per title and per rung, whether or not anyone watches. Delivery is paid on every view. A title watched a million times cares about the egress line. A title watched twice cares about the encode line, and about a rung nobody needed.
That is also why the lab keeps a cost against quality frontier. Each finished run becomes a dot, with cost per viewer-hour on one axis and rebuffer ratio, startup time or live latency on the other. A per-title run that moves left without moving up is the result you were after. One that moves left and up has traded a quality metric for the saving.