How many viewers can a 10 Gbps streaming server handle?

A 10 Gbps server run at a safe 80%, or 8 Gbps, can serve about 1,000 concurrent viewers of a 1080p stream at 7.8 Mbps, 1,700 at 720p, 470 in 4K and 62,500 audio-only listeners. The formula is viewers = usable capacity ÷ bitrate per viewer, so the bitrate you choose matters more than the hardware.

The short version: viewers on 8 Gbps

Eighty percent of a 10 Gbps port, with each viewer receiving one video rendition plus 128 kbps of stereo AAC audio:

Apple’s figures are average bitrates from its HLS authoring specification. Its H.264 tiers keep the source frame rate from 540p upward, so a 60 fps event stays at 60 fps; its HEVC figures are given for 30 fps. YouTube’s are what it asks encoders to send it, not what it delivers to viewers: they show what happens when a server relays the encoder’s stream untouched. Passing a 1080p60 feed through at 17 Mbps cuts the audience by more than half compared with transcoding it to 7.8 Mbps.

How many viewers can a 10 Gbps server handle?

Viewers = usable capacity ÷ bitrate per viewer. Three inputs decide the answer:

• Usable capacity. Plan on about 80% of the port. Encoders overshoot: Apple’s specification lets a live stream’s measured peak reach 125% of its declared bandwidth, and its one-hour average 110% of the declared average. TCP/IP and HTTP add overhead on top.
• Bitrate per viewer. Video plus audio. YouTube recommends 128 kbps for stereo audio; Apple’s range for stereo AAC is 32 to 160 kbps.
• Which rendition people watch. With adaptive bitrate, phones and slow connections pick lower tiers, so the real average sits below the top tier. Sizing on the top tier is the safe assumption.

The port is only half of the path. Every viewer also needs that bitrate all the way to the screen, and on every network the uplinks beyond a server’s port are shared. Test real routes with our network speed test guide before a big event.

Bandwidth for 1,000 viewers

Multiply the per-viewer bitrate by 1,000: about 17 Gbps in 4K, 7.9 Gbps at 1080p with 7.8 Mbps video, 4.6 Gbps at 720p, 1.2 Gbps at 480p-class quality and 0.13 Gbps for audio only. A thousand 1080p viewers fill one 10 Gbps port to the 80% line; the same audience in 4K needs three servers.

Monthly traffic, and what a CDN would charge

One viewer watching for an hour at 1 Mbps transfers 0.45 GB: 1 Mbps × 3,600 seconds ÷ 8 bits per byte. Monthly traffic is therefore concurrent viewers × Mbps per viewer × hours a day × 30 × 0.45 GB. For 1,000 viewers of a 7.93 Mbps stream four hours a day: 1,000 × 7.93 × 4 × 30 × 0.45 = 428,000 GB, about 428 TB.

List prices as of October 2026, excluding taxes and request fees, counting 1 TB as 1,000 GB. Amazon CloudFront charges $0.085 per GB for the first 10 TB a month in the United States and Europe, falling by tier to $0.04 between 150 and 500 TB and to $0.02 beyond 5 PB. bunny.net charges $0.01 per GB in Europe and North America on its Standard network ($0.03 in Asia and Oceania), and on its 10-location Volume network $0.005 per GB for the first 500 TB, $0.004 up to 1 PB and $0.002 up to 2 PB.

Origin and edges in several cities

Self-hosted delivery splits the work. One origin takes the encoder’s feed over SRT or RTMP, transcodes it into a ladder and packages HLS. Edges in the cities where your viewers are pull each segment once and serve it many times. SRS’s documentation gives the arithmetic: a 1 Mbps stream watched by 1,000 viewers through NGINX edges puts 1 Gbps on the edges and only 1 Mbps on the origin, and ten edges with 10 Gbps each reach 100,000 viewers at that bitrate.

We run servers in Amsterdam, Frankfurt, London, Paris, Zürich, New York, Miami, Los Angeles, Singapore and Tokyo, each with its own 10 Gbps unmetered port, so an edge costs the same whether it moves 5 TB or 2 PB a month. At the 80% line, one edge carries about 1,000 viewers at 7.9 Mbps. In the 1,000-viewer, four-hours-a-day case above, even bunny.net’s volume rate comes to about $2,140 a month for delivery alone, while an origin at $159 and two edges at $55 each cost a fraction of that. Our survey of 10 Gbps unmetered pricing and our guide to how bandwidth is billed explain why flat ports change the math.

A CDN still wins in some cases:

• An audience spread thinly across the world. bunny.net’s Standard network alone lists 119 locations, against our ten cities.
• Spikes you can’t predict, far above your usual audience. A CDN absorbs them; your own edges stop at their ports.
• No one to run servers. Edges are simple caches, but someone has to patch, monitor and add them.

You can also combine both: your own edges for the regular audience, a CDN for the overflow.

Transcoding: x264 and x265 presets or NVENC

Transcoding turns one high-bitrate feed into the ladder viewers actually need. On a CPU, x264 and x265 trade speed for compression through presets, ordered from fastest to slowest: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo. x264’s own header warns that “the speed of these presets scales dramatically”: ultrafast is a full 100 times faster than placebo. Live encoding must keep up with real time on every rung of the ladder, so it lives at the fast end; MediaMTX’s own re-encoding example uses -preset ultrafast. x265’s zerolatency tune goes further, disabling B-frames, lookahead and frame parallelism to cut encoder delay. How many rungs a 16-core CPU sustains depends on preset, resolution and frame rate, so measure your ladder on the target server before an event.

A GPU moves that work to dedicated encoders. The RTX PRO 4000 Blackwell has two ninth-generation NVENC encoders, two sixth-generation NVDEC decoders and 24 GB of GDDR7 with ECC, for 145 W at most. NVIDIA’s support matrix lists H.264, HEVC and AV1 encoding and “Unrestricted” concurrent sessions, whereas GPUs outside NVIDIA’s qualified list are capped at 8 sessions per system. NVIDIA’s NVENC application note gives Blackwell throughput per encoder at 1080p, with low-latency tuning and constant bitrate:

NVIDIA measured these with Video Codec SDK 13.0 and says the driver balances sessions across a chip’s encoders, so two NVENCs roughly double them; they are NVIDIA’s benchmark figures, not measurements of our servers. A ladder needs more than its top rung: 720p, 540p, 432p and 234p together add about 90% to the pixels of a 1080p frame, so budget roughly two 1080p encodes per channel, assuming throughput follows pixel count. On that estimate one card carries about five 60 fps channels at P5, and more at faster presets.

Owncast, MediaMTX, SRS and nginx-rtmp

Owncast’s hardware encoding needs direct access to the GPU, which its documentation rules out on a shared VPS; a dedicated GPU server qualifies. Its object-storage bucket must be public and only ever holds the last few minutes of the stream. MediaMTX’s documentation notes that without re-encoding, which is how it works, the bottleneck is almost always bandwidth between server and viewers. The configuration examples below come from each project’s documentation.

nginx-rtmp’s README turns an RTMP application into HLS with three directives:

rtmp {
    server {
        listen 1935;
        application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
        }
    }
}

MediaMTX serves LL-HLS by default. These are the relevant lines of its default mediamtx.yml; its comments note that HTTPS is required for LL-HLS to work correctly on Apple devices:

hls: true
hlsAddress: :8888
hlsVariant: lowLatency
hlsSegmentCount: 7
hlsSegmentDuration: 1s
hlsPartDuration: 200ms

A MediaMTX read replica in another city pulls every path from the origin on demand:

paths:
  "~^(.+)$":
    source: rtsp://dns-of-origin:8554/$G1
    sourceOnDemand: yes

For standard HLS, SRS’s cluster guide uses NGINX as a caching edge, keeping playlists for 10 seconds and segments for 60 minutes. On an edge in another city, point proxy_pass at your origin instead of 127.0.0.1:

proxy_cache_path  /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;

server {
    listen       80;
    server_name your.domain.com;

    proxy_cache_valid  404      10s;
    proxy_cache_lock on;
    proxy_cache_lock_age 300s;
    proxy_cache_lock_timeout 300s;
    proxy_cache_min_uses 1;

    location ~ /.+/.*\.(m3u8)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri$args;
        proxy_cache_valid  200 302  10s;
    }
    location ~ /.+/.*\.(ts)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri;
        proxy_cache_valid  200 302  60m;
    }
}

HLS and LL-HLS in brief

HLS cuts a stream into short media segments listed in playlists, all fetched over plain HTTP, which is why ordinary web caches can serve it. Apple’s authoring specification asks for a keyframe every two seconds, 6-second target segment durations and a default variant of 2,000 kbps; YouTube likewise recommends 2-second keyframes and never more than 4. Players usually buffer about three segments before starting, as MediaMTX’s configuration notes, so 6-second segments leave viewers well behind live.

Low-Latency HLS adds partial segments, 200 ms long in Apple’s example, playlist delta updates, blocking playlist reloads, preload hints and rendition reports. Apple says it lowers latency over public networks “into the range of standard television broadcasts.” The catch is the delivery chain: every hop has to hold and answer blocking playlist requests as new parts appear, and a cache that keeps playlists for 10 seconds, like the NGINX example above, defeats the purpose. Run standard HLS through simple caches, and LL-HLS end to end on software that implements it, such as MediaMTX.

A setup that scales: origin, edges and a GPU

• Origin and packager: the Ryzen 9 9950X at $159 a month, with 16 Zen 5 cores, 128 GB of DDR5 and two 1.92 TB NVMe drives, to ingest, package HLS and run a CPU ladder you have measured. Delivered in about 15 minutes in Amsterdam, Frankfurt, London, New York, Miami, Los Angeles, Singapore and Tokyo.
• Edges: the Ryzen 5 7600 at $55 a month, with 6 cores, 32 GB and two 512 GB NVMe drives. A cache that doesn’t re-encode is limited by its port, not its CPU. It is available in eight of our ten cities; in Tokyo, use a Ryzen 9 9950X, and in Zürich a Xeon E-2488 at $95.
• Transcoding: the RTX PRO 4000 Blackwell server at $169 a month, built within 24 hours in Amsterdam, Frankfurt or New York, once you run several channels, 4K, HEVC or AV1.

Every server includes a 10 Gbps unmetered port and always-on DDoS mitigation, so an edge’s bill does not move with your audience. More layouts for live and on-demand video are on our streaming and CDN page. This guide assumes you stream your own content or live events you hold the rights to.

Sources

• Choose live encoder settings, bitrates, and resolutions — YouTube Help
• HTTP Live Streaming (HLS) authoring specification for Apple devices — Apple Developer
• Enabling Low-Latency HTTP Live Streaming (HLS) — Apple Developer
• AWS Price List: Amazon CloudFront — Amazon Web Services, published 3 October 2026
• CDN Pricing — bunny.net, checked October 2026
• RTX PRO 4000 Blackwell — NVIDIA; Video Encode and Decode Support Matrix — NVIDIA Developer
• NVENC Application Note — NVIDIA Video Codec SDK 13.0
• x264.h — VideoLAN x264; Preset Options — x265 documentation
• owncast/owncast, Hardware Accelerated Encoding & Codecs, Choose the Right Video Quality Settings and Use Object Storage to Save Bandwidth — Owncast
• bluenviron/mediamtx, mediamtx.yml, Scalability and Re-encoding — MediaMTX
• HLS Cluster — SRS documentation; ossrs/srs — GitHub
• arut/nginx-rtmp-module — GitHub