Streaming Bandwidth Calculator: How Much Do You Need?

Why Bandwidth Matters for Streaming

Bandwidth is the single most critical infrastructure factor in any streaming operation. Whether you are running a small single-stream setup or managing hundreds of concurrent channels, understanding your bandwidth requirements determines everything from server selection to monthly operating costs. Underestimate your bandwidth needs and viewers experience buffering, dropped frames, and degraded quality. Overestimate and you waste money on capacity you never use.

For IPTV operators and streaming businesses, bandwidth planning is not a one-time calculation. As your viewer base grows, as you add channels or restreaming destinations, and as you increase quality tiers, your bandwidth requirements scale accordingly. This guide provides the formulas and reference data you need to plan accurately.

Per-Stream Bandwidth by Quality

Each stream consumes a specific amount of bandwidth based on its resolution, bitrate, and frame rate. Here are the standard requirements for a single stream at each quality level:

• 4K (2160p): ~15 Mbps per stream — approximately 4.9 TB per month if running 24/7
• 1080p (Full HD): ~5 Mbps per stream — approximately 1.6 TB per month if running 24/7
• 720p (HD): ~3 Mbps per stream — approximately 970 GB per month if running 24/7
• 480p (SD): ~1.5 Mbps per stream — approximately 485 GB per month if running 24/7
• 360p (Low): ~0.8 Mbps per stream — approximately 260 GB per month if running 24/7

These figures represent video bitrate only. Audio adds between 64 kbps and 320 kbps on top of these numbers, though for planning purposes the video bitrate dominates the calculation.

Restreaming Bandwidth Requirements

Restreaming is one of the most bandwidth-intensive operations in any streaming workflow. When you restream a channel to multiple destinations, each destination requires the full stream bitrate as a separate outbound connection. There is no way to share bandwidth between destinations since each platform receives its own independent copy of the stream.

For example, if you are restreaming a 1080p stream at 5 Mbps to three platforms simultaneously (YouTube, Twitch, and Facebook), your upload bandwidth requirement is:

3 destinations x 5 Mbps = 15 Mbps upload bandwidth

This is in addition to the inbound bandwidth required to receive the original stream. Many operators underestimate restreaming costs because they assume the stream is sent once and distributed, but each destination is a separate, full-bitrate connection from your server.

Audio Streaming Bandwidth

For radio stations and audio-only streams, bandwidth requirements are significantly lower but still add up at scale. A single audio stream typically requires between 64 kbps and 320 kbps depending on codec and quality settings. At 128 kbps (a common setting for music streaming), each concurrent listener consumes 128 kbps of outbound bandwidth. With 1,000 concurrent listeners, that is 128 Mbps of bandwidth — a non-trivial amount that requires proper planning.

The Bandwidth Formula

Use this formula to calculate your total bandwidth requirement for any streaming setup:

Total Bandwidth = (Stream Bitrate x Number of Viewers) + (Restream Bitrate x Number of Destinations) + 20% Overhead

The 20% overhead accounts for protocol headers, retransmissions, control data, and occasional bitrate spikes. In practice, this overhead can range from 10% to 25% depending on the protocol and network conditions.

For a concrete example: suppose you have 5 live streams at 1080p (5 Mbps each) with an average of 50 viewers per stream, plus restreaming 2 of those streams to 3 external platforms each:

• Viewer delivery: 5 Mbps x 250 total viewers = 1,250 Mbps
• Restreaming: 5 Mbps x 6 total destinations = 30 Mbps
• Overhead (20%): 256 Mbps
• Total: approximately 1,536 Mbps (1.5 Gbps)

Concurrent Viewer Capacity by Bandwidth

Knowing your available bandwidth, you can calculate how many concurrent viewers your server can support:

• 100 Mbps connection: ~20 viewers at 1080p, ~33 at 720p, ~66 at 480p
• 1 Gbps connection: ~200 viewers at 1080p, ~333 at 720p, ~666 at 480p
• 10 Gbps connection: ~2,000 viewers at 1080p, ~3,333 at 720p, ~6,666 at 480p

These numbers assume direct server delivery without a CDN. In practice, most operations serving more than a few hundred concurrent viewers should integrate a CDN to distribute the load.

CDN Integration for Scaling

A Content Delivery Network (CDN) fundamentally changes the bandwidth equation. Instead of your origin server delivering every stream to every viewer, the CDN edge servers cache and distribute content from points of presence around the world. Your origin server only needs to push one copy of each stream to the CDN, and the CDN handles fan-out to thousands or millions of viewers.

With CDN integration, your origin server bandwidth requirement drops to: Number of Streams x Stream Bitrate x 1.2 (overhead). For 10 streams at 5 Mbps, that is only 60 Mbps from your origin regardless of how many viewers are watching.

Tips for Reducing Bandwidth Usage

If bandwidth is a constraint, there are several strategies to reduce consumption without sacrificing the viewer experience:

• Use Passthrough Mode: When your input stream is already at the desired quality, use passthrough transcoding to avoid re-encoding. This does not directly reduce bandwidth, but it eliminates CPU overhead and allows you to allocate resources to serving more streams.
• Lower Quality for Mobile: Serve 480p or 360p to mobile viewers on cellular connections. Most mobile screens cannot display the difference between 720p and 1080p at typical viewing distances.
• Adaptive Bitrate Streaming (ABR): Implement ABR to automatically adjust stream quality based on each viewer's available bandwidth. This prevents buffering and reduces average bandwidth per viewer.
• Optimize Encoding Settings: Use efficient codecs like H.265/HEVC which can deliver the same quality at roughly half the bitrate of H.264. This directly halves your bandwidth requirement per stream.
• Schedule Non-Critical Streams: If you have limited bandwidth, stagger non-critical streams to avoid peak concurrent usage.