Last updated: 2026-06-24

Streaming Bandwidth

Streaming bandwidth is the total upload capacity needed to deliver live video to an audience watching at the same time. It matters when sizing an origin server, an upstream internet link, or a venue's network before a broadcast, where under-provisioning shows up as buffering and dropped frames the moment the audience grows.

The formula

where $n$ is the number of concurrent viewers, $b$ is the per-viewer encoding bitrate in bits per second, $h$ is the fractional headroom margin, $B_r$ is the raw bandwidth, and $B$ is the recommended provisioning target. The model assumes unicast delivery, where each viewer receives an independent copy of the stream, so bandwidth scales linearly with the audience.

Worked example. Streaming 1080p video at 5 Mbps to 100 concurrent viewers with 20% headroom:

The raw floor is 500 Mbps, and the 20% margin lifts the recommended target to 600 Mbps. With no headroom the target would equal the raw figure; the margin exists to absorb the bursts and overhead that a constant-bitrate assumption ignores.

Why bandwidth scales with the audience

In a unicast model every viewer needs their own stream, so the cost grows in direct proportion to the number of people watching:

• Linear scaling. Doubling the audience doubles the bandwidth. Ten thousand viewers at 5 Mbps demand 50 Gbps raw — far beyond a single origin link.
• Bitrate dominates. Moving from 1080p at 5 Mbps to 4K at 20 Mbps quadruples the per-viewer cost before a single extra viewer joins.
• Adaptive bitrate adds renditions. Real services encode several quality levels at once, so the effective per-viewer cost is usually higher than one nominal bitrate.

Because of this scaling, large broadcasts almost never serve every viewer from the origin. A content delivery network replicates the stream across edge servers, so the origin only uploads a handful of copies and each edge node handles the local fan-out.

Choosing a per-viewer bitrate

Fast-moving content such as sports or gameplay sits at the high end of each band to avoid blocking artefacts, while talking-head and screen-share content can use the low end. When in doubt, size for the bitrate your encoder actually outputs rather than a nominal target.

Why headroom matters

The raw figure is a minimum that assumes a constant bitrate and a fixed audience. Three things break that assumption in practice:

• Variable bitrate. Modern codecs spike during complex, high-motion scenes and dip during static ones, so peak demand sits above the average.
• Protocol overhead. Packet headers, retransmissions, and segment requests add a few percent that the payload-only formula leaves out.
• Audience growth. Viewer counts rarely hold steady, and a popular moment can add subscribers faster than you can re-provision.

A 20–30% margin keeps the link off its ceiling when several of these line up at once. Running a link at full utilisation causes queuing, latency, and dropped frames, so the headroom is cheap insurance against a visibly degraded stream.

Related calculators

To work out the per-viewer bitrate from a target file size or to size on-demand encodes, use the Video Bitrate & File Size Calculator calculator. To estimate how long it takes to move a finished recording across a link, see the Data Transfer Time Calculator calculator. To convert a rate between bits-per-second and bytes-per-second units, use the Throughput (bps) Converter calculator.