Why we moved from fixed ladders to per-title encoding
For years the default way to encode adaptive video was a fixed bitrate ladder: 1080p at 5 Mbps, 720p at 3 Mbps, and so on, applied to every asset regardless of content. It's simple, predictable — and wasteful.
A screencast with a static slide and a talking-head webinar do not need the same bitrate to look identical. Neither does a fast-cut action trailer compared to a lecture. A fixed ladder either overspends on easy content or starves hard content of the bits it needs.
What per-title analysis actually does
Before encoding, we run a fast complexity pass over the source: spatial detail, motion, grain. That produces a per-title convex hull of quality-versus-bitrate, and we pick the rungs that sit on it. Simple content gets a lower ceiling; complex content keeps its bits.
Across a representative sample of customer catalogues, per-title encoding cut delivered bytes by 28–34% at matched visual quality (VMAF).
The catch: it has to be fast
An analysis pass that doubles encode time is a non-starter. The trick is that the complexity pass runs at a fraction of full resolution and shares its decode with the first rendition, so the marginal cost is small:
POST /v1/jobs
{ "input": "s3://uploads/lecture.mov", "profile": "auto" }
// profile:auto → per-title ladder selection
Setting profile to auto is all it takes. The response still returns a concrete renditions array so your player logic doesn't change.
When to keep a fixed ladder
Live is the obvious exception — there's no time for a look-ahead pass, so live streams use a tuned fixed ladder. And if you have strict per-rendition bitrate contracts with a distribution partner, a fixed ladder keeps you compliant. For everything on-demand, auto is the better default.