How Livestream Bitrate Ladders and Adaptive Streaming Work

Overview

A livestream doesn't send one single video quality to every viewer. It's typically encoded simultaneously into a 'bitrate ladder' of several quality levels, and each viewer's player automatically and continuously chooses the best level for their current connection, switching in real time as conditions change.

Steps

Tested: keyframes, segments and the cost of switching

We tested Pro Tip 1 and steps 2 and 3 on 2026-09-28 with FFmpeg 8.1.2 (x264) on an Apple M1 Max Mac running macOS 26.6.2. The video was a minute of computer-generated 1080p footage at 25 frames a second, panning across detailed pictures, with 12 hard cuts at irregular times. We encoded it as a streamer's upload would be sent (x264 veryfast at 6 Mb/s) with four keyframe settings. Then we packaged each upload into HLS segments without re-encoding it, as a platform does when it passes your own quality straight through, and asked for 2-second segments every time.

Pro Tip 1 holds, and the table shows the reason. A segment can only start on a keyframe, so the packager ignored the 2 seconds we asked for and followed the upload. With a keyframe every 10 seconds, every segment was 10 seconds long. A player changes quality at the start of a segment (step 3), so on a passed-through stream a viewer's player waits up to that long for its next chance to switch. With x264's defaults the keyframes fell on the cuts, and the segments ran from 2.2 to 7.4 seconds, of uneven length. When a platform re-encodes your stream into its ladder, it sets its own keyframes, and this limit applies to its encoder rather than to yours.

A player moving between rungs expects each to be cut at the same points, so that the next segment it fetches starts where the last one ended. We encoded four rungs one at a time, from 1080p at 6 Mb/s down to 360p at 0.6 Mb/s. With a fixed 2-second interval they lined up exactly. With x264's defaults they also lined up, at the same 12 cuts, but only because every cut in our video is a hard one that the encoder detects the same way at every size. Fades and gradual changes were not tested. A fixed interval does not depend on that.

Short intervals cost picture quality, because a keyframe is coded without reference to the frames before it and takes far more bits. At a constant 3 Mb/s at 720p, the same bits for each, a keyframe every 4 seconds gave 36.6 dB PSNR and every 10 seconds 37.8 dB. Every 2 seconds gave 35.0 dB, and every second 34.8 dB, a difference within what separate runs of the same encode varied by. So 2 seconds is a trade: faster switching and regular segments, paid for in quality at a fixed upload rate. Going shorter than 2 seconds cost little more in this test.

Step 2 says the ladder is encoded in real time. One FFmpeg process made all four rungs from the 1080p source, and the 60-second video took 19 seconds, including decoding the lossless source, on a Mac that was busy with other work at the time. A platform does this on servers for every live channel at once, which this test does not measure.

To send a keyframe every 2 seconds, and at no other time, from FFmpeg at 30 frames a second: ffmpeg -i input -c:v libx264 -preset veryfast -b:v 6M -maxrate 6M -bufsize 12M -g 60 -keyint_min 60 -sc_threshold 0 -f flv rtmp://server/app/key

Validated. Measured 2026-09-28 with FFmpeg 8.1.2 (x264 and its HLS muxer) and numpy on an Apple M1 Max Mac running macOS 26.6.2. The video is computer-generated, with hard cuts only. We packaged the segments ourselves with FFmpeg. We did not test any platform's ladder or packager, or a player choosing between rungs over a real connection. Times are from a Mac running other software and will differ on other machines. x264's constant-bitrate encodes vary by about 0.1 dB PSNR from run to run.

Pro Tips

• Configure your own stream's keyframe interval according to your platform's recommendation. YouTube recommends 2 seconds and no more than 4, and Twitch gives 2 seconds in every configuration it recommends. This directly affects how quickly the platform's bitrate ladder segments can be created and how smoothly viewers' players can switch between quality levels.
• Send the highest-quality, well-configured source stream your upload bandwidth reliably supports. The platform's bitrate ladder is generated from your source, so a better source generally improves results across every quality tier viewers might see.
• Don't assume all your viewers are seeing your stream at your uploaded quality. Most are automatically receiving whichever ladder level best matches their own connection, which is normal, expected behavior, not a sign of a problem.