Adaptive bitrate streaming: several qualities from one live, and the CPU it costs

Adaptive bitrate (ABR) means the server encodes one live input into several renditions (here 1080p as received, plus 720p, 480p and 360p) and publishes them in one HLS multivariant playlist; the player picks a rendition per segment from its measured throughput. The cost is all on the server: each extra rendition is a real-time encode, about 0.6 of a core per 1080p input for the three-rung ladder below.

How a ladder works

The player downloads a master playlist that lists every quality with its bitrate and size. It starts on one, measures how fast segments arrive, and moves up or down. Because every quality has its keyframes at the same moments, the player can switch at a segment boundary without stopping. Two rules make a ladder efficient:

• Pass the top through. The original is already encoded; re-encoding it only loses quality and costs processor.
• Only make smaller copies that matter. A 768-line source gains nothing from a 720p copy. Skip rungs within about 10% of the source.

What it costs, measured

On a 4-core laptop processor, we made 720p, 480p and 360p copies of a 1080p30 live with three different x264 presets, and measured the processor while someone was watching:

Ultrafast produces slightly larger files for the same quality. In return it keeps up: in a separate test on the same busy laptop, a 1080p encode on veryfast ran at only 0.83× real time, and in live video that means a backlog that only grows. For small copies watched on phones, the trade is clearly worth it.

Plan for it

• Only encode while someone is watching. A ladder nobody watches is wasted processor.
• Cap the number of lives with a ladder. creekX makes copies for up to two lives at a time per server by default; beyond that, lives are served in their original quality, and the app says why.
• Leave headroom. An encoder at 100% falls behind and never catches up.

And WebRTC?

WebRTC adapts differently: the sender changes its bitrate, or sends several layers at once (simulcast). In creekX, WebRTC viewers get the original quality with sub-second delay, and the ladder serves HLS viewers. Sizing the rest of the server is covered in how to size a streaming server.

Turning it on

Per stream in the app, or from code with one flag. HLS viewers then get the ladder; WebRTC viewers are unchanged:

curl -X PATCH https://live.example.com/v1/streams/STREAM_ID \
  -H "X-CreekX-Key: YOUR-API-KEY" -H "content-type: application/json" \
  -d '{"qualities":true}'

The master playlist creekX served for our 720p test camera with this turned on (real output). The 720p original passes through; 480p and 360p are the copies:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=3064776,AVERAGE-BANDWIDTH=2730387,RESOLUTION=1280x720
index_0.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1709546,AVERAGE-BANDWIDTH=1443840,RESOLUTION=854x480
index_1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1056058,AVERAGE-BANDWIDTH=921618,RESOLUTION=640x360
index_2.m3u8