500 surveillance cameras streaming continuously cost less to run than a single fifty-person video meeting.
That is not a trick of the numbers. It is the central fact about SFU bandwidth cost, and it is invisible to any capacity model that counts users. Five hundred cameras are five hundred publishers and almost no viewers. Fifty people in a meeting are fifty publishers and fifty viewers each. The headcount says one is ten times bigger. The bill says the opposite.
The asymmetry: ingress is free, egress is the bill
A media server does two things with video. It receives streams from publishers, and it sends streams to viewers. These are not priced alike, and on most infrastructure they are not priced at all alike.
Every major cloud provider charges nothing for inbound data transfer. Outbound runs around $0.09 per GB. So on the server's side of the ledger, a publisher is free and a viewer costs real money — before you have written a line of application code, your cost model already has a zero on one side of it.
The stream counting works the same way. One publisher produces exactly one inbound stream no matter how popular they are. One viewer consumes one outbound stream per person they are watching. Publishers add linearly to a number that costs nothing; viewers multiply a number that costs everything.
This is why a media server's capacity is measured in consumers — one outbound stream to one receiver — rather than in participants. The unit exists because it is the unit that costs money.
Which makes the usual planning unit actively misleading.
Why "users" is the wrong unit for SFU bandwidth cost
Capacity plans get built from the numbers a business already has: seats sold, concurrent users, peak sessions. None of those distinguish between someone who is publishing and someone who is watching, and the difference between the two is the entire forecast.
Two deployments with identical user counts can differ by a factor of fifty in bandwidth. The variable is not scale. It is shape — specifically the ratio of publishers to viewers, and how many of those viewers each publisher reaches.
The general form: outbound streams equals the number of viewers multiplied by the number of publishers each viewer is subscribed to. In an all-see-all meeting, every participant is both, so it collapses to N x (N-1) and grows with the square of the room. In a webinar, one publisher reaches everyone, so it is simply the viewer count and grows linearly.
Put four real workload shapes side by side and the difference stops being abstract.
Four workload shapes, priced side by side
All four assume an average forwarded stream of 600 kbps, which is realistic with simulcast enabled and most viewers receiving a lower spatial layer. Egress priced at $0.09/GB, the standard major-cloud rate.
Read the first two rows together. Same fifty people, same hour, same software. A meeting costs fifty times a webinar, because in a meeting every person is a publisher reaching forty-nine viewers, and in a webinar one person is.
Then read the third. Five hundred cameras — ten times the endpoints of the meeting — cost about three percent of it. Publishing is nearly free; the three operators are the only thing generating a bill, and they are watching seventy-five tiles between them. That ceiling is a decode problem on the operator's workstation, not a bandwidth problem.
And the fourth shows the ceiling has nothing to do with user count either. One publisher, one stream in, and a quarter of a thousand dollars an hour going out.
What this changes about capacity planning
Three practical consequences, in the order they usually bite.
- Forecast from streams, not seats. Ask how many people will be watching how many other people simultaneously. A sales forecast of "1,000 concurrent users" is unpriceable until someone says whether that is 500 two-person calls or twenty fifty-person meetings — the second costs roughly sixty times the first.
- The expensive product is rarely the one that looks expensive. Broadcast and webinar features feel like heavy infrastructure and are cheap per head. Small interactive rooms feel lightweight and are the most costly thing per participant you can build, because everyone is a publisher.
- Growth in room size is not growth in users. Going from 10-person to 25-person rooms is a 2.5x increase in headcount and a 6.7x increase in bandwidth. Budgets that track headcount growth will be wrong by a widening margin, and the error compounds exactly when a product is succeeding.
The good news is that two levers move this number substantially, and neither requires more hardware.
The two levers that move your SFU bandwidth cost
Both operate on the same equation: streams out multiplied by average bitrate.
1. Cap the number of streams each viewer receives
This is the larger of the two by a wide margin. If a client renders nine tiles rather than all fifty, the server forwards nine streams to it instead of forty-nine. The 50-person meeting above drops from 2,450 outbound streams to 450 — an 82% reduction — and the growth curve flattens from quadratic to linear.
Speaker-based forwarding is how essentially every large video product does this, and it is usually the difference between a room size that is viable and one that is not. It is a product decision as much as an infrastructure one, since it changes what users see — and it is one of the two levers in where the bottleneck moves as you scale an SFU.
2. Lower the average forwarded bitrate
Because average bitrate multiplies every outbound stream, a small reduction compounds. Simulcast is the mechanism: the server forwards a 180p layer to a thumbnail rather than 720p to everyone. Moving the average from 2.5 Mbps to 600 kbps cuts the bill by roughly three-quarters across the entire deployment.
Worth measuring rather than assuming. The average matters far more than the peak, because it is what gets multiplied — and most teams have never looked at which layer their subscribers are actually receiving.
There are limits to how far the publisher-is-free framing holds, and they are worth stating plainly.
Where the asymmetry breaks down
The bandwidth story is clean. The complete picture is not, and a capacity model built only on egress will miss three things.
- Publishers do cost server CPU. Each inbound stream needs decryption, per-producer state, and RTCP handling, and a publisher with simulcast delivers three streams to track rather than one. This is a small cost per publisher, but a 500-publisher deployment feels it even while its bandwidth bill stays trivial.
- Publishers cost the client heavily. Encoding is expensive, and with simulcast it is three parallel encoders. The cost did not vanish — it moved onto the publishing device, where it shows up as battery drain and thermal throttling rather than as an invoice.
- Recording inverts the whole model. Recording is driven by publishers, not viewers, so a 500-camera deployment with continuous recording has a large storage and processing bill attached to the side of the ledger that was free. If you record, the asymmetry described here applies to your bandwidth and not to your total cost.
One more, worth naming because it catches people out: per-minute video APIs generally bill participant-minutes regardless of whether someone is publishing or watching. That inverts these economics entirely — the webinar shape that is cheapest to self-host is the one where per-minute billing costs most. That comparison deserves its own treatment and gets one separately; the point here is only that the arithmetic above describes infrastructure you run, not every pricing model you might buy.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit all expose per-consumer metrics, which is what makes this measurable rather than theoretical — you can see exactly how many streams each subscriber is receiving and at what layer. Building also means you control tile caps and forwarding policy, which is the larger of the two levers above. The cost is that egress lands on your infrastructure contract, so where you host becomes the dominant variable.
Buy a cloud video API
Per-minute providers absorb the bandwidth question, which is genuinely valuable when your workload shape is unpredictable or your volume is low. The limits are that you generally cannot see per-consumer metrics, cannot tune the forwarding policy, and are billed on a model whose shape may not match your workload's shape.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control — which matters directly here, because it is what puts the egress on your own contract and makes the levers above yours to pull. It is resilient by design rather than something you assemble.
Where it does not fit: at genuinely small or highly irregular volume, a per-minute API costs less and involves fewer decisions. And if your workload is overwhelmingly publish-heavy with almost no viewers — a pure recording or archival pipeline — none of the bandwidth arithmetic in this post is your constraint, and you should be optimising storage instead.
The Bottom Line
Publishers are close to free on a media server and viewers are the entire bandwidth bill, because inbound transfer costs nothing and outbound costs around nine cents a gigabyte. Any forecast built on user counts is blind to the one ratio that decides the number.
Forecast in outbound streams instead: viewers multiplied by how many publishers each of them is subscribed to. Then attack that product directly — cap the tiles each client renders, and lower the average forwarded bitrate. Those two do more than any amount of additional hardware.
What's Next
Once you know your stream count, what scaling past a single media server costs prices it against different hosting venues — a difference of roughly 90x. For the surveillance shape specifically, why watching 500 cameras is a decode problem goes deeper.
Frequently Asked Questions
Why does SFU bandwidth cost depend on viewers rather than publishers?
Because media servers pay for outbound traffic, not inbound. Every major cloud charges nothing for data transfer in and around $0.09 per GB for data transfer out. A publisher sends one stream in; each viewer pulls one stream out for every person they are watching. Publishers add to a free number, viewers multiply a costly one.
How do I estimate my video bandwidth bill?
Multiply outbound streams by average forwarded bitrate by hours. Outbound streams equals viewers times the number of publishers each viewer subscribes to. At 600 kbps, one viewer-stream is about 0.27 GB per hour, or roughly 2.4 cents at standard cloud egress rates. At full 2.5 Mbps HD it is about 1.13 GB and 10 cents.
Why do 500 cameras cost less than a 50-person meeting?
Because almost nobody is watching the cameras. Five hundred publishers with three operators viewing 25 tiles each generates 75 outbound streams. A 50-person all-see-all meeting generates 2,450, because every participant is watching all 49 others. Endpoints are not the unit; outbound streams are.
Is a webinar cheaper to run than a meeting with the same number of people?
Dramatically — roughly 50x cheaper at 50 people. In a webinar one person publishes and everyone receives one stream, so outbound scales linearly with the audience. In an all-see-all meeting everyone publishes to everyone, so it scales with the square of the room.
What is the single biggest way to reduce SFU bandwidth cost?
Cap how many streams each client receives. If a viewer renders nine tiles instead of forty-nine, the server forwards nine streams to them. In a 50-person room that is an 82% reduction, and it changes growth from quadratic to linear. Lowering average forwarded bitrate through simulcast is the second lever and typically cuts the remainder by around three-quarters.
Does this mean publishers are free?
Free in bandwidth, not in total. Each inbound stream still costs server CPU for decryption and state tracking, and encoding is expensive on the publishing device — especially with simulcast, which means three parallel encoders. Recording also scales with publishers rather than viewers, so a publish-heavy deployment that records has a substantial bill on the side of the ledger that looked free.
Can I keep the egress on my own infrastructure contract?
Yes, if the platform is deployed on infrastructure you choose rather than consumed as a metered service. Samvyo works this way, keeping the media path, TURN and recording under your control. That matters here because where the traffic leaves from, and at what rate, is the largest single variable in the total.
