Live Streaming & HLS Bitrate Calculator

Choose a codec and the highest resolution you will offer, and the calculator lays out the HLS bitrate ladder Apple publishes for it, with your audio added to every rung. Add the segment length, the number of people watching at once and how long the stream runs. It then works out the upload for the top rung, the size of each top-rung segment, the least delay HLS players allow, the bandwidth your servers or CDN must deliver, and the total data. Everything recalculates in the browser as you type.

How the figures are worked out

Every rung of the ladder carries video and audio, so a viewer on that rung downloads the two added together:

rung = video + audio

A segment holds that bit rate for its length, divided by eight to turn bits into bytes. RFC 8216 defines a segment's bit rate the same way in reverse, as its size divided by its duration.

segment MB = rung kbps × 1,000 × seconds ÷ 8 ÷ 10⁶

Delivery assumes the worst case for your servers, every viewer on the top rung, and the data delivered is that rate held for the whole stream:

Gbps = viewers × top rung kbps ÷ 10⁶

GB = viewers × top rung kbps × 1,000 × hours × 3,600 ÷ 8 ÷ 10⁹

The delay comes from a rule for players. A playlist declares a target duration, a whole number of seconds that no segment may exceed once rounded, and players start at least three target durations from the end of it:

delay ≥ 3 × target duration

Take the defaults: H.264 topping out at 1080p, 128 kbps of audio, 6-second segments, 1,000 viewers and a two-hour stream. Apple's top 1080p rung is 7,800 kbps, so with audio it is 7,928 kbps, and sending it needs 7.928 Mbps of upload. One 6-second segment holds 7,928,000 × 6 ÷ 8 = 5,946,000 bytes, or 5.946 MB. Each viewer pulls 7,928,000 × 3,600 ÷ 8 = 3,567,600,000 bytes an hour, which is 3.5676 GB and shows in the ladder table as 3.57. A thousand viewers need 7.928 Gbps, and over two hours that comes to 7,135.2 GB. Six-second segments give a target duration of 6, so players start at least 18 seconds behind live.

Apple's bitrate ladder

The rungs come from Apple's HLS Authoring Specification for Apple Devices, as published when this page last checked it on October 21, 2026. Apple gives them as average bit rates in kilobits per second for 16:9 video and calls them "initial encoding targets for typical content", to be tested against your own footage and adjusted.

Apple stops the H.264 ladder at 1080p and lists 1440p and 4K only for HEVC. Its HEVC columns are headed 30 fps, and it advises cutting them by about 20 percent for 24 fps content. The bottom four rungs of each ladder run at 30 fps or less, while the rest keep the frame rate of the source. Several resolutions appear twice at different bit rates. Apple says the default variant, the one listed first in the playlist, should be the 2,000 kbit/s rung, and that some UHD variants should stay at 15 Mbit/s or less for the widest compatibility.

Where HLS came from

Roger Pantos of Apple posted the first draft of HTTP Live Streaming to the IETF on 1 May 2009, describing "a protocol for transmitting unbounded streams of multimedia data over HTTP". Because the stream arrives as short files over ordinary HTTP, Apple's own overview notes that it can be served "from an ordinary web server" and passes through the caches, edge servers and firewalls already built for the web. The first draft called a target duration of 10 seconds typical. HLS shipped that year, and the draft went through 23 revisions before it was published as RFC 8216 in August 2017, co-written with William May of MLB Advanced Media and describing version 7 of the protocol. The RFC kept the sentence about 10-second target durations.

Apple's rules grew alongside the protocol. Its authoring specification added HEVC in June 2017 and HDR that September, split the bitrate ladder into separate H.264 and HEVC tables in April 2018, and now says target durations should be 6 seconds. At WWDC in June 2019 Apple introduced Low-Latency HLS, which it says brings latency under two seconds over public networks at scale, and it added Low-Latency HLS to the authoring specification in June 2020. The international standard that does the same job, MPEG-DASH, was published as ISO/IEC 23009-1 in April 2012.

Segments, keyframes and delay

Every HLS video segment must start with a keyframe, and Apple asks for one every two seconds, so a 6-second segment holds three. RFC 8216 tells players not to start less than three target durations from the end of the playlist, which sets the floor this calculator reports: 18 seconds for 6-second segments and 30 seconds for the 10-second segments the early drafts treated as typical. Real delay is longer, because the encoder must finish a segment before it can be listed, and the trip through the CDN adds more. Shorter segments lower the floor but make every player reload the playlist more often, since RFC 8216 has players wait at least one target duration between reloads. Low-Latency HLS splits segments into parts, with one second as Apple's recommended part duration, and holds players at least three parts back instead.

Upload: one rung or the whole ladder

The upload figure assumes your encoder sends only the top rung and something further along builds the rest: a cloud transcoder, a packager or a streaming platform. Encode the whole ladder on your own machine and you upload every rung. At the defaults the nine H.264 rungs add up to 25,640 kbps of video. With one shared audio track that is 25,768 kbps, and with the audio carried inside each variant it is 26,792 kbps. Offering HEVC as well as H.264, as Apple expects for older devices, adds a second ladder on top.

A platform that transcodes your feed asks for more than a delivery rung. YouTube says it "will automatically transcode your live stream to create many different output formats" and recommends 17 Mbps for 1080p at 60 fps in H.264, or 12 Mbps in AV1 or HEVC, with a keyframe every 2 seconds and never more than 4 apart, and 128 Kbps for stereo audio.

What the estimate leaves out

The figures are encoder bit rates, and the traffic on the wire runs a little higher. Segments wrap the video and audio in a container, either MPEG-2 transport stream packets of 188 bytes or fragmented MP4, and RFC 8216 counts that container overhead in the BANDWIDTH a playlist declares. HTTP, TCP and IP headers then add their share. Apple's figures are averages, and its rules only require a live stream's measured peak to stay under 125 percent of the BANDWIDTH it declares.

The delivery figures assume every viewer sits on the top rung for the whole stream. Players on slower connections step down the ladder, and audiences come and go, so real traffic usually lands below the ceiling shown here. The calculator also gives every rung the same audio. At 128 kbps that is almost half of the smallest rung's 273 kbps, and Apple allows lighter audio, such as HE-AAC at 64 kbit/s or less, and stereo offered at several bit rates. To price the data, carry the gigabytes into the cloud egress cost calculator or the bandwidth overage calculator.

Frequently asked questions

What bitrate should I use for a 1080p live stream?

Apple's HLS ladder gives 1080p two rungs, 6,000 and 7,800 kbps in H.264 or 4,500 and 5,800 kbps in HEVC, and calls them initial targets to test against your own footage. That is what viewers receive. What you send to a platform can be higher: YouTube recommends 17 Mbps for 1080p at 60 fps in H.264, or 12 Mbps in AV1 or HEVC, because it transcodes your stream into its own set of formats.

How much upload speed do I need to live stream?

At least the bitrate you send, with room to spare for anything else on the line. Sending only the 1080p H.264 top rung with 128 kbps of audio needs 7.928 Mbps. If your own machine encodes and uploads all nine H.264 rungs, the video alone comes to 25,640 kbps, and with one shared audio track it is 25,768 kbps, more than three times as much.

How much bandwidth do 1,000 viewers need?

If all 1,000 watch a 7,928 kbps top rung, your origin or CDN sends 1,000 × 7.928 Mbps, which is 7.928 Gbps. Over a two-hour stream that adds up to 7,135.2 GB. Viewers on slower connections drop to lower rungs, so real traffic usually comes in under this, but the top-rung figure is the ceiling to plan for.

Why are HLS segments 6 seconds long?

Apple's HLS Authoring Specification says target durations should be 6 seconds, shorter than the 10 seconds that the first 2009 draft and RFC 8216 call typical. RFC 8216 tells players to start at least three target durations from the end of the playlist, so 6-second segments put viewers at least 18 seconds behind live and 10-second segments at least 30. Shorter segments cut that delay but make players reload the playlist more often.

How much data does an hour of live streaming use?

Each viewer downloads the rung's bitrate for 3,600 seconds, divided by 8 to turn bits into bytes. At 7,928 kbps that is 3.5676 GB an hour. At Apple's default 2,000 kbps rung plus 128 kbps of audio it is 0.9576 GB. The ladder table lists the figure for every rung at the audio bitrate you enter.

Should I use HEVC or H.264 for HLS?

HEVC reaches each picture size in fewer bits. Apple's top 1080p rung is 5,800 kbps in HEVC against 7,800 kbps in H.264, about a quarter less, and Apple lists 1440p and 4K rungs only for HEVC. Apple still says some content should be encoded in H.264 for older devices, so many services publish both ladders, which means encoding and storing both.

Sources

1. HLS Authoring Specification for Apple Devices, Apple Developer
2. RFC 8216: HTTP Live Streaming, RFC Editor, Independent Submission, 2017
3. HTTP Live Streaming, draft-pantos-http-live-streaming-00, Internet Engineering Task Force, 2009
4. HTTP Live Streaming Overview, Apple Developer Documentation Archive, 2016
5. Introducing Low-Latency HLS (WWDC19 session 502), Apple Developer, 2019
6. Choose live encoder settings, bitrates, and resolutions, YouTube Help