Bitrate ladder calculator
Your ladder — 6 rungs
| Rung | Resolution | Video | + audio | maxrate | Segment | Share |
|---|---|---|---|---|---|---|
| 1080pHigh | 1920×1080 | 6.10 Mbps | 6.23 Mbps | 9.20 Mbps | 4.67 MB | 36% |
| 720pHigh | 1280×720 | 2.75 Mbps | 2.88 Mbps | 4.15 Mbps | 2.16 MB | 27% |
| 480pMain | 854×480 | 1.30 Mbps | 1.43 Mbps | 1.95 Mbps | 1.07 MB | 18% |
| 360pMain | 640×360 | 730 kbps | 858 kbps | 1.10 Mbps | 0.64 MB | 10% |
| 240pBaseline | 426×240 | 250 kbps | 378 kbps | 380 kbps | 0.28 MB | 6% |
| 144pBaseline | 256×144 | 100 kbps | 228 kbps | 150 kbps | 0.17 MB | 3% |
Share is the assumed portion of viewer-hours landing on each rung, weighted to the top because ABR players climb to the highest rung the connection sustains. It drives the egress figure below and is the number most worth replacing with your own player analytics.
Storage per hour
5.40 GB
All 6 renditions of one hour of source, stored once.
Blended bitrate
3.38 Mbps
Weighted average actually delivered to a viewer.
Egress / 1,000 viewer-hours
1.52 TB
2.80 TB if every viewer pinned the top rung.
Storage is paid once per hour of content; egress is paid again for every hour watched. At any real audience size the second number is the bill — put it into the CDN cost calculator to see what it costs across providers.
How these numbers are produced
Bitrate is modelled as width × height × frame factor × bits-per-pixel × codec × content. The only empirical term is bits per pixel, which is tuned per rung so that the H.264 / 30fps / general column lands on the conventional published ladders — 1080p at about 6 Mbps, 720p at about 2.8 Mbps, 360p at about 730 kbps. Everything else is a multiplier off that anchor, and the per-rung bits-per-pixel figure is shown in the table so you can see which number to disagree with.
The frame-rate term is deliberately not linear. Doubling frame rate halves the difference between consecutive frames, so the encoder spends much less on each one — 60fps costs roughly 1.5× of 30fps rather than double, and a model that scales linearly will over-provision every high-frame-rate ladder it touches.
What it does not do
This is a static model, and a modern encoder doing per-title or per-shot analysis will beat it — that is the entire point of per-title encoding. Use this for the questions that come first: how many rungs, roughly what bitrates, how much storage, and how much egress. Then measure the real encodes against it.
The bottom two rungs are also not efficiency-optimised, and that is intentional. They exist so a stream survives a bad connection, so they run below the bits-per-pixel curve and accept the quality cost in exchange for staying reachable.
Where the ladder meets delivery
A ladder is only half the problem — the other half is whether the segments it produces are actually cached. Segments are immutable once written, so they should carry a year-long lifetime, while a live media playlist must expire faster than its segment duration. The Cache-Control generator has presets for both, and the cache header checker shows what your origin is sending today. For background on the formats themselves, see adaptive bitrate streaming and the HLS guide.
Frequently asked questions
- How many rungs should a bitrate ladder have?
- Five to seven for most catalogues. The constraint is not resolution coverage but switching behaviour: rungs spaced closer than about 1.5× apart give the player almost nothing to gain by switching, while gaps much wider than 2× make every switch a visible jump in quality. Below roughly 1.5× spacing you are paying storage and encoding for renditions that barely differ.
- What bitrate does 1080p video need?
- Around 6 Mbps for H.264 at 30fps on general content, about 4 Mbps for HEVC, and about 3.4 Mbps for AV1. Frame rate and content type move it substantially: the same 1080p rung carrying 60fps sports needs roughly double what a 25fps talking-head interview does, which is why a single published number is only ever right for one kind of content.
- How much bandwidth does AV1 actually save?
- Roughly 45% against H.264 at matched quality, with HEVC around 35% and VP9 around 30%. The saving is real but it is not free — AV1 encoding is far more expensive in CPU time, and hardware decode only reached mainstream devices recently. The usual approach is an AV1 ladder for devices that can decode it with an H.264 ladder alongside for everything else, which means paying storage twice to save egress.
- Why must the keyframe interval divide the segment duration?
- Because a player can only switch renditions at a segment boundary, and it can only start decoding a segment that begins with a keyframe. If the GOP length does not divide the segment duration exactly, boundaries drift away from keyframes and the player is forced to keep decoding the rendition it is already on. The symptom is a ladder that looks correct but refuses to adapt — set -g and -keyint_min to frame rate × segment duration, and disable scene-cut keyframe insertion.
- Is storage or egress the bigger cost for video?
- Egress, at any real audience size, and it is not close. Storage is paid once per hour of content encoded; egress is paid again for every hour anyone watches. A thousand viewer-hours of a 1080p ladder moves several terabytes while the ladder itself occupies a few gigabytes — which is why adding a rung is cheap and raising the bitrate of an existing one is not.
- Should I use a fixed ladder or per-title encoding?
- Per-title encoding wins when the catalogue is large and varied, because it analyses each source and spends bitrate where that specific content needs it — a fixed ladder has to be provisioned for the hardest content it will ever carry. A fixed ladder is the right answer for live, for small catalogues, and as the starting point you measure per-title results against.