Most IPTV operators undersize their pipe by 2× to 3× and find out the hard way — usually at 21:00 on a Saturday during a football match, when the panel goes red and 8,000 subscribers start refreshing simultaneously.

This post is the napkin math we walk every prospect through before they buy a server. No mystery, no "consult an architect" — just the four numbers that decide whether a 10G port is plenty or you're already cooked at sign-up.

The formula

Bandwidth out of your head-end at any moment is roughly:

Mbit/s = active_lines × concurrent_streams_per_line × avg_bitrate_mbps × abr_multiplier

That's it. Every term matters, and getting two of them wrong is enough to misorder by 10× in either direction.

Let's pull each one apart.

1. Active lines vs paying subscribers

When a reseller says "I have 50,000 subscribers", they usually mean "I sold 50,000 lines this year." Active lines — boxes that actually authenticate against the panel at least once a week — is typically 60–75 % of that on a healthy panel, much less on a stale one.

For sizing, assume 70 % unless you have telemetry that says otherwise. So 50K sold → 35K active.

2. Concurrency at peak

The most misunderstood number. People plug in "100 % concurrency" because they don't want to under-provision. That's nonsense — even live news during a national disaster doesn't pull every box.

Real numbers we've seen across hundreds of panels:

| Audience type | Off-peak concurrency | Peak hour concurrency | Major sport event | |---|---|---|---| | Mixed EU IPTV (news + entertainment) | 12–18 % | 32–40 % | 55–65 % | | MENA / sports-heavy panel | 18–25 % | 45–55 % | 70–80 % | | LatAm / single time zone | 15–22 % | 38–48 % | 60–72 % | | US adult content | 8–14 % | 22–30 % | n/a |

Peak hour is what you size for. Major sport events are what makes you buy headroom. Size for peak, plan headroom for events.

For a mixed EU panel of 35K active lines, peak ≈ 35K × 0.38 = 13,300 concurrent boxes.

3. Bitrate per stream

This is where codec and resolution decisions stack:

| Stream type | Codec | Bitrate (Mbps) | |---|---|---| | SD H.264 | x264 | 1.5 – 2.5 | | HD 720p H.264 | x264 | 3.0 – 4.5 | | HD 1080p H.264 | x264 | 5.0 – 7.0 | | HD 1080p H.265 | x265 | 3.0 – 4.5 | | 4K UHD H.264 | x264 | 18 – 25 | | 4K UHD H.265 | x265 | 12 – 18 |

For a typical mixed-resolution panel where about 70 % of boxes are on 1080p H.264, 20 % on 720p, and 10 % on SD, weighted average comes to roughly 5.2 Mbps per stream.

If you're delivering H.265 across the board, you can cut that by 35–40 %, but check your STB fleet — older MAG boxes and a chunk of Smart TVs don't decode HEVC reliably, and you'll spend more in support tickets than you save in bandwidth.

4. The ABR multiplier (the one everyone forgets)

If you serve a single bitrate to each subscriber, multiplier is 1.0. Easy.

If you're running an Adaptive Bitrate ladder (HLS or MPEG-DASH), the player switches between rungs — but you don't get to count only the active rung's bandwidth. Two things stack:

  1. Pre-fetch: most players keep 1–3 segments of the next-higher rung warm in buffer in case bandwidth improves. That's ongoing background traffic at roughly 1.15× to 1.3× the playing rate.
  2. Player churn: during scene changes and ad breaks, players burst-download the next 6 seconds in 1–2 seconds. Over a population of 13K viewers, this smooths out — but adds 1.05× to 1.10× to average egress.

Typical ABR multiplier: 1.25 for HLS, 1.20 for DASH.

Worked example: 50K-line mixed EU panel

Putting it together:

  • Sold lines: 50,000
  • Active: 50,000 × 0.70 = 35,000
  • Peak concurrency: 35,000 × 0.38 = 13,300 streams
  • Avg bitrate: 5.2 Mbps (mixed 720p/1080p H.264)
  • ABR multiplier: 1.25 (HLS)

Peak egress = 13,300 × 5.2 × 1.25 = 86,450 Mbps ≈ 86 Gbit/s.

That's your steady-state Saturday-evening number, not the spike. Headroom for an Champions League final (let's say 60 % concurrency instead of 38 %) pushes it to:

35,000 × 0.60 × 5.2 × 1.25 = 136 Gbit/s.

If your panel is anywhere near this scale, a single 100G port is the floor, not the ceiling. You want headroom for two reasons: events you don't expect (election night, royal funeral, derby with a late winner) and DDoS days when you're absorbing 30–50 Gbit/s of attack traffic alongside real subscribers.

This is exactly why our dedicated server tier ships with 100 Gbit/s unmetered ports as standard and why our IPTV-panel hosting plans jump to 400G for anything past 100K-line scale.

Where smaller panels live

For context — most resellers don't operate at 50K lines. The honest distribution:

| Scale | Active lines | Peak Mbps | Recommended port | |---|---|---|---| | Starter reseller | < 500 | < 1 Gbps | Shared 1 Gbit/s on a panel-only VPS | | Growing reseller | 500 – 5,000 | 1 – 13 Gbps | 10 G shared / 10 G dedicated | | Established panel | 5,000 – 30,000 | 13 – 80 Gbps | 25 G or shared 100 G port | | National-scale | 30,000 – 100,000 | 80 – 250 Gbps | Dedicated 100 G, multi-PoP | | Multi-country / wholesaler | 100K+ | 250 Gbps+ | 400 G, anycast, edge fleet |

The jump from "I have a panel and a few thousand boxes" to "national-scale IPTV" is the point where most operators hit the wall — usually because they're still on a single 10G port. By the time you're saturating 10G nightly, you're already losing subscribers to buffering complaints, and the next move (a single 25G uplink) buys you maybe 4 months before you're back in the same place.

The math says: once you cross 5K active lines, your next server should already have a 100G uplink even if you're not using it yet. The cost delta between 10G and 100G ports on bare metal is much smaller than the cost of migrating subscribers off a hot box.

Headroom and the DDoS Saturday

Real numbers from one of our customers (a mid-size MENA panel, ~28K active lines):

  • Average peak hour: 71 Gbit/s
  • Champions League final 2024: 119 Gbit/s
  • A 240 Gbit/s SYN flood mid-stream on a derby evening: legit traffic dropped from 89 Gbit/s to 22 Gbit/s while our DDoS scrubbing absorbed and dropped the attack — total port utilisation peaked at 167 Gbit/s of legit + 73 Gbit/s of scrubbed garbage. The customer never knew until they read our incident report on Monday.

Sizing for attack days is not paranoid. If you have any volume of subscribers, somebody is pointing a booter at you, and once that becomes regular, you need either real on-net scrubbing or you're forced to null-route — which means subscribers don't watch.

Storage and transcode: the second pipe

Live IPTV is one bandwidth problem. VOD and catch-up are a different one.

VOD streams are typically delivered from the same head-end but pull from a separate storage cluster — usually NFS or S3-compatible. If 8 % of your peak hour subscribers are watching VOD instead of live, that's 1,000+ concurrent reads from your storage backend. At 5.2 Mbps each, your storage→head-end internal link needs roughly 5–6 Gbit/s of read throughput on top of the egress numbers above.

Transcoding is the third pipe. If you ingest 60 SD channels from a satellite/IPTV source and need to produce an ABR ladder (1080p + 720p + 480p) for each, that's roughly 18 GPU-hours per day per source assuming hardware encode (NVENC on RTX-class cards). Our GPU servers with RTX PRO 4500 or 6000 Blackwell handle 8–12 concurrent 1080p ABR ladders and 30–50 SD ladders respectively.

You can do transcoding on CPU — but if you're past 40 channels, CPU costs (in cores and power) cross over with GPU rapidly. Most serious panels move transcode to GPU between 30 and 50 simultaneous output streams.

What we sell, and why

This isn't theory. We size every server order with these numbers:

  • 5K–30K lines: usually a bare-metal dedicated with a 25 G port and SSD-backed VOD storage, single PoP. From around $300/mo.
  • 30K–100K lines: dedicated with 100 G unmetered, plus a storage server for VOD, plus optional GPU for live transcode. Multi-PoP if subscribers span Europe + Middle East.
  • 100K+ lines / wholesale: 400 G port, own AS announcement for routing control, edge nodes at our 4 PoPs (Amsterdam, Kyiv, Warsaw, Miami), GPU fleet for transcode.

Provisioning is hours, not days. You can configure a panel-ready box from the catalogue, or talk to engineering if your sizing falls between rows in the table above.

TL;DR

  • Sold lines ≠ active lines. Use 70 %.
  • Peak concurrency for mixed IPTV is 32–40 %, not 100 %.
  • Average bitrate for typical H.264 panels is around 5.2 Mbps.
  • ABR multiplier is 1.25, not 1.0.
  • Order ports for peak × headroom, not for average traffic.
  • A 50K-line panel needs ~86 Gbit/s steady, ~136 Gbit/s for events.
  • DDoS days are normal; if your port has no headroom for the attack, your subscribers stop watching when somebody pays $5 on a booter.

If your numbers don't fit cleanly into the table above, write us — we'll size it together, no upsell unless you actually need the bigger box.