How much CPU does 1080p live transcoding need? Measured numbers

Live video costs CPU only where it is decoded and encoded again. Forwarding and recording a 1080p stream as it arrives uses almost nothing; making an adaptive bitrate ladder of 720p, 480p and 360p from one 1080p live costs about 0.6 of a CPU core with x264 at a fast preset. Size a server by how many streams you transcode, not by how many you receive.

Measured numbers

All were measured on the creekX server; your content and hardware will differ. Busy, detailed pictures (sport, confetti) cost more to encode than talking heads.

Why forwarding is cheap

A server that only repackages, for example RTMP in and HLS or WebRTC out, never touches the pixels. It copies compressed frames from one container to another. The limits are network and disk: a 5 Mbit/s stream writes about 2.3 GB an hour.

Why a ladder costs what it does

An ABR ladder decodes the 1080p input once and encodes it again at each lower resolution. Encoding cost grows roughly with pixels per second, so 720p costs about half of 1080p, 480p a quarter and 360p an eighth. A full 1080p re-encode would cost more than the whole ladder below it, which is why passing the original through as the top rung saves the most.

The preset is the biggest dial

x264 presets trade CPU for compression. Each step slower (veryfast, faster, fast, medium) saves some bitrate at the same quality and costs noticeably more CPU. For live work the encoder must finish each frame in real time with headroom, so live ladders normally run at veryfast or faster. Library conversion, which is not real time, can afford slower presets.

A sizing rule of thumb

1. Count the lives that need a ladder; allow about 0.6 of a core each at 1080p.
2. Count 24/7 channels; allow about 5% of a core each.
3. Keep 30% headroom so spikes in picture complexity do not drop frames.
4. Then check the network: viewers, not CPU, fill the port.