Encoding Ladder: HLS Bitrate Table and Renditions (2026)

Updated October 2026: rungs and the H.264 profile cap re-checked against Apple's current HLS Authoring Specification (now with its HEVC ladder), a new HLS encoding section with a tested FFmpeg command, live-sports and low-bandwidth ladders, 2026 CDN prices and measured per-title savings.

Why this matters

If you are a founder, product manager, or first-time streaming CTO, the encoding ladder is the first technical decision that touches every part of your business at once: it sets how good your service looks, how much storage your catalog needs, and — through the bytes it sends to viewers — the single largest line on your monthly bill. Most teams accept whatever default ladder their encoder ships with, never realizing that the default is built for someone else's content and audience. This article gives you the mental model to read, question, and size a ladder: what each rung is made of, why the ladder exists at all, how many rungs you actually need, and how a ladder choice becomes a number in dollars. By the end you will be able to look at any encoding ladder and ask the three questions that matter — is the top rung too high, are there enough low rungs, and is this ladder tuned to my content or just a copy of Apple's example.

What is an encoding ladder?

Short answer: an encoding ladder — also called a bitrate ladder, ABR ladder or HLS ladder — is the set of renditions of one video, each a resolution-and-bitrate pair, that an adaptive player switches between as the network changes. Apple's reference H.264 ladder (HLS Authoring Specification, revised June 2025) has nine rungs, from 416×234 at 145 kbps to 1920×1080 at 7,800 kbps; most services ship five to nine rungs and tune them to their own content.

Start with the problem the ladder solves. Your viewers do not all have the same internet connection. One is on home fiber, another on a train with a flickering mobile signal, a third on hotel Wi-Fi shared with two hundred guests. If you served everyone the same high-quality video file, the fiber viewer would be fine and everyone else would stare at a spinning buffer wheel. If you served everyone a low-quality file to be safe, the fiber viewer would get a soft, blocky picture on a 65-inch screen and wonder why they pay you.

The fix is to make several versions of every title and let each viewer's player pick the one their connection can handle right now. That set of versions is the encoding ladder (also called a bitrate ladder), and each individual version is a rendition. A useful picture: an encoding ladder is the set of seat classes on a single flight. Same plane, same destination, different price and comfort — and the player books the best class the network can afford at that moment, downgrading to economy when the signal weakens and upgrading back when it recovers.

Each version sits one step above or below the next, so the set is drawn as a ladder with rungs. The bottom rung is a small, low-quality rendition that almost any connection can pull down without stalling. The top rung is a large, high-quality rendition for fast networks and big screens. In between sit the middle rungs, where most real viewing actually happens. The technique of switching between these rungs as conditions change is called adaptive bitrate streaming (ABR); the player measures the network and the health of its own buffer, then climbs to a higher rung or drops to a lower one. We keep the player's switching logic at arm's length here — the detailed mechanics live in our adaptive bitrate streaming guide in the Video Streaming section. For the ladder, the only thing you need from ABR is this: the ladder is the menu, and ABR is the diner choosing a dish every few seconds.

Figure 1. One source, many rungs. The player starts on a safe middle rung, climbs when the network is strong, and drops before the buffer runs dry — the whole point of building a ladder instead of a single file.

What a single rung is made of

A rung is not just "720p." It is a small bundle of decisions, and getting the bundle right is most of the craft. Four properties define every rung.

The first is resolution — the pixel dimensions of the picture, such as 1920×1080 (called 1080p) or 640×360 (360p). More pixels means a sharper image on a big screen, but more pixels also need more data to describe, so resolution and cost rise together.

The second is bitrate — how much data per second the rendition uses, measured in kilobits or megabits per second (kbps or Mbps). Bitrate is the lever that matters most for both quality and cost. A higher bitrate carries more detail and motion cleanly; a bitrate set too low for the resolution produces blocky artifacts and smeared motion. Crucially, bitrate is what you pay to deliver: a content delivery network bills you for bytes sent, so every rung's bitrate is also its price tag.

The third is the codec — the compression method used to shrink the video, such as H.264, HEVC, or AV1. A more efficient codec delivers the same picture at a lower bitrate, which is why codec choice is really a cost-and-reach decision. We treat that decision on its own in codec strategy for OTT, and the underlying codec mechanics live in our Video Encoding section. For the ladder, hold one fact: the same rung costs fewer bytes on a newer codec, but only devices that understand that codec can play it.

The fourth is the frame rate — how many images per second, such as 30 or 60. Frame rate usually stays constant across the ladder (you do not change how smooth the motion is, only how sharp the picture is), though very low rungs sometimes halve it to save data. Alongside these four sit the codec profile and level, a compatibility setting that caps how demanding the stream is allowed to be; Apple's authoring rules, discussed below, ask for some H.264 rungs at or below High Profile, Level 4.1 (and none above Level 5.2) so that the stream plays on the broad base of devices.

Figure 2. A rung is a bundle of four decisions plus a compatibility cap. Bitrate is highlighted because it is the property that becomes a delivery bill.

How the ladder lives inside the manifest

The ladder is not an abstract idea inside the encoder; it is written down, in plain text, in the file the player reads first. That file is the manifest — a small text document that lists every rung and where to fetch it. The player downloads the manifest, sees the menu of rungs, and starts choosing.

In HLS (HTTP Live Streaming, the Apple-created delivery format defined in IETF RFC 8216; its second edition, draft-pantos-hls-rfc8216bis-22, has been in the RFC Editor queue since May 2026), the manifest is the multivariant playlist (called the master playlist in RFC 8216), and each rung is one EXT-X-STREAM-INF entry. The tag carries the rung's peak bandwidth, average bandwidth, resolution, and codec, then points to that rung's own playlist of video segments. A trimmed three-rung example:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=6500000,AVERAGE-BANDWIDTH=6000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",FRAME-RATE=30.000
v_1080p_6000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2200000,AVERAGE-BANDWIDTH=2000000,RESOLUTION=960x540,CODECS="avc1.64001f,mp4a.40.2",FRAME-RATE=30.000
v_540p_2000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=820000,AVERAGE-BANDWIDTH=730000,RESOLUTION=768x432,CODECS="avc1.64001e,mp4a.40.2",FRAME-RATE=30.000
v_432p_730.m3u8

Each EXT-X-STREAM-INF line is one rung of your ladder; BANDWIDTH is the peak the player must sustain and AVERAGE-BANDWIDTH is the typical rate. The structure is defined in RFC 8216 §4.3.4.2. The other major delivery format, MPEG-DASH (Dynamic Adaptive Streaming over HTTP, ISO/IEC 23009-1, sixth edition published June 2026), expresses the identical idea with different words: one AdaptationSet holds several Representation elements, each carrying a bandwidth, width, height, and codecs attribute. A Representation in DASH is the same thing as a variant stream in HLS — one rung of the ladder.

Two formats, one ladder. You do not build the ladder twice. Modern platforms encode the renditions once and package them into both HLS and DASH from a single set of segments using CMAF (Common Media Application Format, ISO/IEC 23000-19), the converged fragmented-MP4 format that both protocols can read. The product framing of that "encode once, package for everyone" step is covered in packaging: CMAF, HLS, and DASH from one mezzanine; the takeaway for the ladder is that your rungs are codec-and-bitrate decisions, made once, then served in whatever format a given player needs.

A representative ladder, rung by rung

Numbers make the ladder concrete, so here is a seven-rung H.264 ladder for 16:9 video, taken from the nine-rung reference table in Apple's HLS Authoring Specification (last revised June 2025, checked October 2026). H.264 is the right codec to illustrate with because it plays on essentially every device made in the last decade — it is the reach baseline every platform ships. The shape below follows Apple's HLS Authoring Specification recommendations and common industry practice; treat the exact bitrates as sensible starting points to tune against your own content, not as immutable law.

Table 1. Seven of the nine rungs in Apple's H.264 reference ladder. Apple's full table also lists 1920×1080 at 7,800 kbps and 640×360 at 365 kbps; rungs at 432p and below are capped at 30 fps, rungs from 540p up keep the source frame rate. The rung count and spacing are the product decisions you actually make.

A few rules from Apple's HLS Authoring Specification shape this table and are worth knowing because they protect playback on real devices. For on-demand content, each rung's measured average bitrate must sit within 10% of its declared AVERAGE-BANDWIDTH, and its peak should stay within 200% of the average so a sudden complex scene does not blow the viewer's bandwidth budget; for live streams the measured peak must stay under 125% of the declared BANDWIDTH. For H.264 it asks for High Profile, with some rungs at or below Level 4.1 for maximum compatibility and none above Level 5.2. It recommends six-second segments with a keyframe every two seconds, which sets how quickly the player can switch rungs. It names the 2,000 kbps variant as the default first stream on Wi-Fi and the 730 kbps variant on cellular, because the first rung the player loads sets the viewer's first impression before ABR has measured anything. And for cellular delivery the multivariant playlist must include a variant whose peak is 192 kbps or less — which is the job of the 145 kbps floor rung.

Now the arithmetic that turns this table into storage. The cost of holding a title is driven by the sum of all rung bitrates, because you store every rendition. Add the column: 6,000 + 4,500 + 3,000 + 2,000 + 1,100 + 730 + 145 = 17,475 kbps, about 17.5 Mbps of aggregate stored bitrate. For a single two-hour film:

aggregate bitrate   = 17,475 kbps ≈ 17.5 Mbit/s
film length         = 2 hr × 3,600 s         = 7,200 s
stored data         = 17.5 Mbit/s × 7,200 s ÷ 8 = 15,750 MB ≈ 15.7 GB

So this ladder stores one two-hour film in roughly 15.7 GB across all seven rungs. Storage is cheap — at about $0.023 per gigabyte-month (Amazon S3 Standard list price, 2026) that film costs well under a dollar a month to hold — so the ladder's storage cost is rarely the thing that hurts. The thing that hurts is delivery, which we turn to next, and which depends not on the sum of the rungs but on which rung each viewer actually pulls.

The same ladder in HEVC and AV1

A newer codec moves every number in the ladder down. Apple publishes a separate HEVC reference ladder next to the H.264 one, and setting rungs of the same resolution side by side shows the saving directly:

Table 2. Apple's H.264 and HEVC reference ladders (HLS Authoring Specification, checked October 2026), matched rung for rung by resolution. HDR HEVC rungs run about 20% above the SDR values.

AV1 goes further. Apple added AV1 rules to its specification in June 2025 (fMP4 container only, Level 6.2 or below), and in December 2025 Netflix reported that AV1 already carried about 30% of its on-demand viewing, with AV1 sessions using roughly a third less bandwidth than AVC and HEVC. The practical ladder in 2026 is therefore two or three ladders in one playlist: an H.264 ladder for reach, plus HEVC or AV1 rungs that capable devices pick by their CODECS attribute. Which codec earns its own ladder is a decision we walk through in codec strategy for OTT.

HLS encoding: how to encode a ladder for HLS

Short answer: HLS encoding means encoding every rung of the ladder (H.264, HEVC or AV1) with keyframes aligned across all rungs, cutting each rung into segments of about six seconds, and listing every rung in one multivariant playlist with its bandwidth, resolution and codec. The player then switches rungs at any segment boundary.

1. Pick the rungs — start from Table 1, drop rungs your devices never play, and keep neighbouring rungs roughly 1.5–2× apart.
2. Align keyframes — a keyframe every two seconds at the same timestamps in every rung, with scene-cut keyframes switched off, so every segment of every rung starts on a keyframe.
3. Cap the bitrate — capped VBR keeps each rung inside its declared BANDWIDTH: Apple allows a VOD peak up to 200% of the average and a live peak under 125%, and many teams cap at about 110% for a margin.
4. Segment and package — six-second segments, fMP4/CMAF for HEVC and AV1 (and for H.264 if you also serve DASH), then the multivariant playlist. How the playlist and its tags work line by line is in our HLS playlists and tags guide.

A three-rung 1080p / 720p / 480p H.264 ladder in one FFmpeg command (tested with FFmpeg on a synthetic source, October 2026). 480p is not in Apple's table; 1,400 kbps puts it between Apple's 432p and 540p rungs and keeps the spacing near 2×:

ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=3[a][b][c];[a]scale=-2:1080[v1080];[b]scale=-2:720[v720];[c]scale=-2:480[v480]" \
  -map "[v1080]" -map "[v720]" -map "[v480]" -map 0:a -map 0:a -map 0:a \
  -c:v libx264 -profile:v high -preset slow -sc_threshold 0 \
  -force_key_frames "expr:gte(t,n_forced*2)" \
  -b:v:0 6000k -maxrate:v:0 6600k -bufsize:v:0 12000k \
  -b:v:1 3000k -maxrate:v:1 3300k -bufsize:v:1 6000k \
  -b:v:2 1400k -maxrate:v:2 1540k -bufsize:v:2 2800k \
  -c:a aac -b:a 128k -ac 2 \
  -f hls -hls_time 6 -hls_playlist_type vod -hls_segment_type fmp4 \
  -hls_flags independent_segments -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" "stream_%v/index.m3u8"

The output is one master.m3u8 with three rungs and six-second fMP4 segments per rung. FFmpeg writes BANDWIDTH, RESOLUTION and CODECS but not AVERAGE-BANDWIDTH or FRAME-RATE, which Apple's rules use; add them in your packaging step and run Apple's mediastreamvalidator before you ship to Apple devices. For a catalog, the same settings live in an encoding service or pipeline rather than a shell script.

The product decisions that build a ladder

Here is the heart of the article: an encoding ladder is a set of choices, and copying someone else's choices is how money leaks. Five decisions define your ladder.

The first is the top rung — the highest quality you offer. Set it by what your content and audience justify, not by ego. A premium film service feeding 4K televisions needs a high top rung; a talking-head news service or a children's animation channel does not, because the extra bitrate buys no visible quality on that content and is delivered to every high-end viewer at full price. The top rung is the most expensive rung to deliver, so it deserves the most scrutiny.

The second is the number of rungs. Too few, and the jumps between rungs are large and jarring — the picture visibly lurches when the player switches. Too many, and you pay to encode and store renditions that sit so close together no viewer benefits from the difference. Five to nine rungs covers most catalogs; the right count depends on how wide a range of devices and networks you serve.

The third is the bitrate of each rung and how far apart the rungs sit. Good ladders space rungs so that each step roughly doubles or halves the bitrate of its neighbor, which keeps the quality jumps even and gives ABR clean, well-separated choices. Rungs crammed together waste encodes; rungs spaced too far apart make switching feel like a cliff.

The fourth is the resolution paired with each bitrate. A bitrate that is generous at 540p is starvation at 1080p, so resolution and bitrate move together up the ladder. A common error is holding resolution too high on low rungs — a 1080p rung at 800 kbps looks worse than a 540p rung at the same 800 kbps, because the bits are spread too thin across too many pixels.

The fifth is the codec and rate-control method — whether you encode H.264 for reach, HEVC or AV1 for efficiency, and whether you hold a constant bitrate or let it vary with scene complexity. These ride alongside every rung and are covered in their own articles, but they belong on the decision list because they change every number in the table.

To make these five decisions concrete and repeatable, we have packaged them into a one-page worksheet you can fill in for your own service before you ask an encoder vendor for a single quote.

Why a fixed ladder wastes money

Most platforms apply one fixed ladder — the same rungs at the same bitrates — to every title in the catalog. It is simple, and it is wrong for almost every individual title, because content is not equally hard to compress. A fast, grainy action film really needs 6,000 kbps at 1080p to look clean. A flat cartoon, a slide-based lecture, or a static talking head looks identical at half that bitrate, because there is simply less visual information to carry. A fixed ladder serves both the same way: it overspends on the easy content and, occasionally, underspends on the hardest.

The alternative is per-title encoding — analyzing each title and building a ladder tuned to its complexity, so simple content gets a lower, cheaper ladder and complex content gets the bitrate it actually needs. Netflix introduced the idea publicly in 2015 with a simple assertion: there is no one-size-fits-all ladder, and each title deserves its own. The method tests several encodes and plots quality against bitrate to find the most efficient set of rungs — the points along what engineers call the convex hull, the curve that bounds the best quality available at each bitrate. The plain-language version: stop paying 1080p prices to deliver a cartoon that looks perfect at a third of the bitrate.

Figure 3. On easy-to-compress content, a per-title ladder lowers the top rung and drops a redundant rung. Same picture to the viewer, fewer bytes to store and deliver.

The savings are real, and smaller than vendor headlines. AWS tested Automated ABR in Elemental MediaConvert, which builds a per-title ladder on top of its QVBR rate control, on 12 titles: the summed bitrate of the ladders fell from 160,979 kbps to 112,341 kbps, a 30% cut, and AWS quotes up to 40% less package size and origin storage than a fixed ladder (AWS, November 2020). For a single easy title the gap can be far larger: in Bitmovin's 2023 example, a 4K HEVC top rung matched the source at 1.9 Mbps against 15 Mbps on a static ladder. For planning, 20–30% across a mixed catalog is a safer number than the "half" in marketing copy. Because delivery is the dominant cost of a streaming platform, a percentage cut in delivered bitrate flows almost directly to the bottom line. We quantify the trade-off — the extra compute to analyze each title versus the storage and egress it saves — with worked arithmetic and a savings calculator in per-title and context-aware encoding: the economics, and the per-scene variant in per-title and per-scene encoding in the Video Encoding course.

Renditions per device: not every rung is for everyone

A ladder also has to respect the device on the other end, because a rung the device cannot use is a rung you paid to build for no one. A 4K rung streamed to a phone is wasted twice over: the phone's small screen cannot show the extra detail, and the phone would not request that rung anyway because its decoder and screen are capped lower. Meanwhile a cheap Android phone on a 2G signal really needs that tiny 234p floor rung that a 4K television will never touch.

This is why device classes map to subsets of the ladder rather than the whole thing. The table below sketches how rungs line up against device classes; the "uses this rung?" columns are the coverage view that keeps you from shipping renditions nobody plays.

Figure 4. Device classes use subsets of the ladder. Phones live on the low and middle rungs; the living room lives on the high ones. Rungs no device pulls are pure waste.

Table 3. Which device class actually uses which rung. The low rungs exist for phones on weak networks; the top rungs exist for the living room. Building 4K for a phone-only audience is pure waste.

The product lesson is to match the ladder to the audience you actually have. A mobile-first service in a market with modest data speeds should invest in well-tuned low and middle rungs and may skip 4K entirely; a premium living-room service should carry the high rungs and can thin out the very lowest. We map device classes to playback decisions across the whole client landscape in the OTT client matrix and dig into the rendition-per-device decision in renditions per device.

From ladder to bill: the arithmetic that matters

Tie the ladder back to money, because that is why the product decision matters. Storage, as shown above, depends on the sum of all rungs and is cheap. Delivery depends on which rung each viewer pulls, and it is the dominant cost. A content delivery network charges for bytes sent to viewers — a recurring fee called egress — and those bytes equal each viewer's watch-time multiplied by the bitrate of the rung they are watching.

Walk one viewer through it. Suppose most viewing lands on the middle rungs, so the average delivered bitrate is about 3 Mbps, and a viewer watches a two-hour film:

delivered bitrate   = 3 Mbit/s (average rung actually played)
watch length        = 2 hr × 3,600 s        = 7,200 s
data delivered      = 3 Mbit/s × 7,200 s ÷ 8 = 2,700 MB = 2.7 GB per full view

At Amazon CloudFront's October 2026 list price for the US — $0.085 per gigabyte after the first free terabyte, falling step by step to $0.020 per gigabyte above 5 PB a month — that single two-hour view costs between about 5 and 23 cents to deliver. Multiply by a real audience and the ladder's influence becomes obvious: if a better-tuned ladder lowers the average delivered bitrate from 3 Mbps to 2.4 Mbps for the same perceived quality, you have cut a fifth off every viewer's delivery cost, every month, forever. That is why the ladder is not a one-time encoding chore — it is a permanent setting on your margin. The full delivery-cost model, including how egress is tiered and discounted, lives in CDN cost engineering and the whole-platform view in the OTT cost model.

Ladders for live sports and low-bandwidth audiences

Live sports. The rule of thumb: keep the source frame rate (50 or 60 fps) on every rung from 540p up and drop to 30 fps at 432p and below, as Apple's tables do; encode capped VBR or CBR, because a live rung's peak must stay under 125% of its declared bandwidth; and let the CDN bill, not the encoder default, set the top rung. The arithmetic for one match: 100,000 viewers watching two hours at an average delivered 4 Mbps pull 3.6 GB each, 360 TB in total, which at volume CDN rates of $0.02–$0.04 per gigabyte is roughly $7,200–$14,400 per match. Every 1 Mbps taken off the average delivered bitrate removes 0.9 GB per viewer — a quarter of that bill — so a slightly lower top rung on HEVC or AV1 for capable TVs usually pays back faster than any other tweak. When the event pipeline itself is the work, our live and on-demand streaming software development team builds the ingest, transcoding and CDN side around these numbers.

Low-bandwidth markets and IPTV. Put more rungs below 1 Mbps — Apple's own table has four (145, 365, 730 and 1,100 kbps) — start playback on the 730 kbps rung instead of 2,000, and keep a variant at or below 192 kbps peak, which Apple requires for cellular. Where set-top boxes and phones decode HEVC, its 640×360 rung at 145 kbps looks far better than an H.264 234p rung at the same bitrate.

Low-end phones. Keep the lower rungs at 30 fps and at or below High Profile, Level 4.1, so older decoders play them, and let newer phones climb to the 1080p rungs only on strong Wi-Fi.

How video APIs pick a ladder on the fly. Automated per-title ladders analyse each file's complexity during the encode: in MediaConvert's Automated ABR you set only the maximum number of renditions and the minimum and maximum bitrate, and the service chooses the rungs. For live streams there is no finished file to analyse, so services usually apply a ladder chosen in advance per channel or event type.

A common mistake: shipping the default ladder

The single most common error we see is treating the ladder as a setting to accept rather than a decision to make. A team installs an encoder, keeps its factory ladder, and ships — never noticing that the default was designed for general content and a generic audience, not for their cartoons, their lectures, or their 4K films. Three specific faults follow from it.

The first is a top rung set too high for the content. Encoding a flat animation at 6,000 kbps delivers no visible benefit over 3,000 kbps but doubles the delivery cost for every viewer who reaches that rung. The fix is per-title tuning, or at minimum a content-aware top rung.

The second is too few low rungs. Teams obsess over the top of the ladder and forget the bottom, leaving viewers on weak networks with no rung small enough to play smoothly. They buffer, then they leave. A healthy 145–730 kbps floor is what keeps mobile viewers watching at all.

The third is resolution and bitrate that drift out of step — a 1080p rung starved at 1,500 kbps, which looks worse than a 720p rung at the same bitrate because the bits are spread across too many pixels. Pair each resolution with a bitrate that can actually feed it, and let resolution step down as bitrate steps down.

Encoding ladder FAQ

What is an encoding ladder?

An encoding ladder is the set of renditions of one video — each a resolution and bitrate pair — that an adaptive player switches between as network speed changes. It is written into the HLS multivariant playlist or the DASH MPD, one entry per rung.

Is a bitrate ladder the same as an ABR ladder or HLS ladder?

Yes. Encoding ladder, bitrate ladder, ABR ladder, resolution ladder and HLS ladder all name the same set of renditions; "HLS ladder" just means the ladder as listed in an HLS playlist.

How many rungs should an encoding ladder have?

Five to nine for most services. Apple's reference H.264 ladder has nine and its HEVC ladder twelve; drop rungs no device in your audience plays and keep neighbours about 1.5–2× apart.

What bitrate should the 1080p rung use in H.264?

Apple's 2026 reference ladder lists 1920×1080 at 6,000 and 7,800 kbps for H.264, and 4,500 and 5,800 kbps for HEVC. Easy content such as lectures or animation often looks the same at half that, which is what per-title encoding finds.

What is a sensible ladder for 480p, 720p and 1080p in FFmpeg?

About 1,400 kbps at 480p, 3,000 kbps at 720p and 6,000 kbps at 1080p in H.264, with a keyframe every two seconds and segments of six seconds; the full command is in the HLS encoding section above.

Which rung does the player start on?

The first variant listed in the playlist. Apple recommends the 2,000 kbps rung first on Wi-Fi and the 730 kbps rung first on cellular.

How much does per-title encoding save?

AWS measured a 30% lower summed ladder bitrate on 12 titles with Automated ABR and quotes up to 40% storage savings; plan on 20–30% across a mixed catalog, more on simple content.

Do I need a 4K rung?

Only if your audience watches on 4K TVs and your content benefits from it. In Apple's tables 4K appears only on the HEVC ladder, at 11,600 and 16,800 kbps, and a phone-only audience never requests it.

Where Fora Soft fits in

The ladder is where picture quality and delivery cost are decided together, and getting it right at scale — across a catalog of thousands of titles, a dozen device classes, and an audience that grows from a thousand viewers to a million — is an engineering discipline, not a checkbox. Fora Soft has built video streaming, OTT/Internet TV, e-learning, telemedicine, and video surveillance software since 2005, across 250+ shipped projects, and that work centers on exactly this kind of scale-and-cost engineering: tuning ladders to content, mapping rungs to the device matrix, moving popular titles to more efficient codecs, and wiring per-title encoding into the pipeline so the delivery bill stays under control as the audience grows. When a media company needs a streaming platform whose quality and unit economics both survive a real audience, that ladder-and-delivery engineering is the capability we bring. Per-title ladders ship as part of our OTT and Internet TV platform development, and the encoding pipeline behind them comes from our video transcoding and processing software development.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook that takes the whole video stack apart, from the pixel to production, across 9,000+ pages. Volume 1 is where this article keeps going: compression, codecs, rate control, and the quality metrics that tell you whether a rung earns its bitrate. Volume 2 covers the packaging and manifests that turn those renditions into HLS and DASH, and volume 3 covers the ABR logic, CDNs, and delivery economics that decide what the ladder costs you every month. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. HLS Authoring Specification for Apple Devices — Apple Inc. Recommended encoding ladder, peak-within-200%-of-average rule for VOD, High Profile with some variants at or below Level 4.1, 10% average and 125% live peak limits, cellular variant at or below 192 kbps, six-second segments with two-second keyframes, and first-variant (2,000 kbps Wi-Fi / 730 kbps cellular) guidance. Tier 3 (first-party standards-author). Revision history to 2025-06-26 (AV1 rules added 2025-06-24); H.264 and HEVC reference ladders. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices (accessed 2026-10-26)
2. RFC 8216 — HTTP Live Streaming (HLS) — IETF. The master playlist and EXT-X-STREAM-INF tag (§4.3.4.2) that defines each ladder rung's bandwidth, resolution, and codec. Tier 1 (official standard). https://www.rfc-editor.org/rfc/rfc8216 (accessed 2026-10-26). Second edition: draft-pantos-hls-rfc8216bis-22 (1 May 2026), sent to the RFC Editor, not yet published as of October 2026 — https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/
3. ISO/IEC 23009-1 — Dynamic Adaptive Streaming over HTTP (MPEG-DASH) — ISO/IEC. The MPD AdaptationSet/Representation model that expresses the ladder in DASH. Tier 1. Sixth edition, ISO/IEC 23009-1:2026 (June 2026), replaces the 2022 edition. https://www.iso.org/standard/89027.html (accessed 2026-10-26)
4. ISO/IEC 23000-19 — Common Media Application Format (CMAF) — ISO/IEC. One set of fragmented-MP4 segments serving both HLS and DASH from one ladder. Tier 1. https://www.iso.org/standard/85623.html (accessed 2026-06-16)
5. Per-Title Encode Optimization — Netflix Technology Blog (2015). The original case that each title deserves its own bitrate ladder; the convex-hull method for choosing rungs. Tier 4 (first-party engineering). https://netflixtechblog.com/per-title-encode-optimization-7e99442b62a2 (accessed 2026-06-16)
6. Per-Title Encoding Savings — Bitmovin (27 November 2023). Worked examples: 22.7% bitrate saving at 4K AVC; a 4K HEVC top rung at 1.9 Mbps against 15 Mbps on a static ladder. The "cut storage and CDN bills in half" headline is marketing and not used as a figure here. Tier 4 (vendor engineering). https://bitmovin.com/blog/per-title-encoding-savings/ (accessed 2026-10-26)
7. Encode video in a smarter way using Automated ABR — AWS for M&E Blog (12 November 2020). Per-title ladders on QVBR: summed bitrate on 12 titles 160,979 → 112,341 kbps (30%); up to 40% package-size and origin-storage reduction versus a fixed ladder; settings are max renditions and min/max bitrate. Tier 4. https://aws.amazon.com/blogs/media/introducing-automated-abr-adaptive-bit-rate-configuration-a-better-way-to-encode-vod-content-using-aws-elemental-mediaconvert/ (accessed 2026-10-26)
8. How to Build an Encoding Ladder: What You Need to Know — Jan Ozer, Streaming Learning Center. The explicit ladder decisions (codec, top rung, rung count, rate control, resolution per rung, keyframe interval) and a worked FFmpeg HEVC ladder. Tier 6 (educational). https://streaminglearningcenter.com/articles/how-to-build-an-encoding-ladder.html (accessed 2026-06-16)
9. Apple Makes Sweeping Changes to HLS Encoding Recommendations — Jan Ozer, Streaming Learning Center. Documents the Apple Devices spec ladder, the 200% constrained-VBR change, High Profile guidance, six-second segments, and first-variant defaults. Tier 6 (educational, quoting the spec). https://streaminglearningcenter.com/articles/apple-makes-sweeping-changes-to-hls-encoding-recommendations.html (accessed 2026-06-16)
10. Netflix Says AV1 Codec Now Powers 30% of Netflix VOD Streaming — Dan Rayburn, Streaming Media Blog (23 December 2025), reporting the Netflix Tech Blog: ~30% of on-demand viewing on AV1, about one-third less bandwidth than AVC and HEVC, 88% of large-screen devices certified 2021–2025 support AV1. Tier 5 (trade press quoting first party). https://www.streamingmediablog.com/2025/12/netflix-av1.html (accessed 2026-10-26)
11. Amazon CloudFront pay-as-you-go pricing — Amazon Web Services. US data transfer out: first 1 TB free, $0.085/GB next 9 TB, down to $0.020/GB over 5 PB per month. Tier 4 (vendor pricing). https://aws.amazon.com/cloudfront/pricing/pay-as-you-go/ (accessed 2026-10-26)
12. AWS S3 Pricing in 2026: What You'll Actually Pay — Filebase (22 June 2026). S3 Standard at $0.023 per GB-month for the first 50 TB in us-east-1. Tier 6 (secondary, used for the storage list price only). https://filebase.com/blog/aws-s3-pricing-in-2026-what-youll-actually-pay/ (accessed 2026-10-26)
13. FFmpeg Formats Documentation — hls muxer — FFmpeg project. var_stream_map, master_pl_name, hls_segment_type fmp4 and related options used in the HLS encoding example (command tested 2026-10-26). Tier 2 (official documentation). https://ffmpeg.org/ffmpeg-formats.html#hls-2 (accessed 2026-10-26)

Source note (per §4.3.2): the manifest structure of the ladder (HLS variant streams, DASH Representations, CMAF segments) traces to tier-1 standards (refs 2–4). Apple's recommended ladder shape and authoring rules trace to the first-party authoring specification (ref 1), with the educational sources (refs 8–9) used only to corroborate the spec's rules in plain language. Per-title savings figures are vendor-reported (refs 6–7) and labelled as such; no lower-tier source overrode a standard.