Simulcast means your camera is encoded three times and all three versions are sent. The intuition that follows is that it costs three times the uplink. It doesn't — it costs about twenty percent more.
The intuition is wrong for a reason worth understanding, because the same reasoning explains when simulcast genuinely does become expensive, and why the real cost is not bandwidth at all.
What is simulcast, precisely
The publisher encodes the same camera feed at several resolutions simultaneously — typically three — and sends all of them to the media server. The server then chooses which one to forward to each subscriber, independently, and can switch between them mid-call.
This matters because subscribers are not alike. Someone viewing you as a thumbnail in a grid of twenty does not need 720p. Someone on a congested mobile connection cannot receive it. Someone who has pinned you full-screen on a desktop does. Without simulcast the server has exactly one version of your stream and must send it to all three, which means either wasting bandwidth on the thumbnail or degrading quality for the person watching you full-screen.
Only an SFU can do this, because it forwards streams rather than mixing them. An MCU produces a single composited picture, so there is nothing to select — the topology comparison covers why that difference matters. It is part of why the industry converged on SFUs.
So the server gets per-subscriber choice. The question is what the publisher pays for it.
What is simulcast actually costing you?
Video bitrate scales roughly with pixel count, and the lower layers have very few pixels. A typical published ladder:
The two extra layers cost 525 kbps on top of 2.5 Mbps. That is a multiplier of about 1.2x — roughly a fifth more uplink, not three times.
Note that the medium layer has a quarter of the pixels of the high layer but uses a sixth of the bitrate. That is deliberate: a stream destined for a small tile can be encoded more aggressively than one destined for full-screen, because the viewer will never see the difference at that size. Well-built ladders exploit this, which is part of why the overhead is as low as it is.
A note on the 17% figure
You will see this overhead quoted as 17%. Check the denominator before repeating it. 525 kbps against the 3,025 kbps total is 17.4%, but against the 2,500 kbps you were sending before simulcast it is 21%. The second is the number that answers "what does turning this on cost me?" Expressing overhead as a share of the new total is a common way to make an increase look smaller, and technical readers notice.
Twenty percent is cheap, and trivial next to what it saves the server. But bandwidth is not where simulcast actually bills you.
The real cost is the encoder, not the network
Three layers means three encoders running in parallel on the publishing device, in real time, on top of capture and everything else the application is doing.
On a desktop with hardware encoding, this is usually unremarkable. On a mid-range phone it is the binding constraint, and it shows up as thermal throttling, battery drain, and frame drops that look like network problems but are not. The pattern is recognisable: a call that is fine for ten minutes and degrades steadily afterwards, on a device that is warm to the touch, with network statistics that look healthy throughout.
This is why most mobile SDKs publish two layers rather than three, or drop to a single layer when the device reports thermal pressure. If you are configuring a ladder yourself, the number of layers is a device-capability decision before it is a bandwidth decision.
There is one form of layering that is genuinely free, and it is worth knowing about.
Temporal layers are free; spatial layers are not
Everything above concerns spatial layers — different resolutions, separate encodes. Temporal layers are different. A single encoded stream can be structured so that dropping every other frame still produces a decodable 15 fps stream from a 30 fps original, because of how frames reference each other.
That costs no additional bitrate and no additional encoder, and it gives the server another dimension to degrade along. When a subscriber's connection deteriorates, dropping frame rate is often less objectionable than dropping resolution — particularly for screen sharing and slide content, where sharpness matters more than motion.
Most implementations combine both: three spatial layers, two or three temporal layers within each. The server picks a point in that grid per subscriber. Only the spatial dimension carries the encoder cost.
Which brings us to the configuration mistake that produces most of the complaints about simulcast.
The ladder mistake that nearly doubles your uplink
The 1.2x figure depends entirely on the lower layers being small. Spacing them too closely destroys it.
Same three layers, same top resolution, and the second configuration costs nearly twice the uplink instead of a fifth more — because 540p has more than half the pixels of 720p, so it costs more than half the bitrate.
This is where "simulcast tripled my bandwidth" reports come from. It is almost never simulcast; it is a ladder whose layers are too close together to be worth having. A useful rule of thumb is that each step down should roughly halve the linear dimensions, which quarters the pixel count. 720p, 360p, 180p follows this. 720p, 540p, 360p does not.
Even a correctly configured ladder is not always worth enabling, though.
When simulcast wastes bandwidth
Four situations where it costs more than it returns.
- One-to-one calls. With a single subscriber there is nothing to select between — that subscriber gets the layer their connection supports, which is what adaptive bitrate would have given them anyway. The extra layers are pure overhead.
- Small rooms with full-screen layouts. If everyone renders everyone at full size, every subscriber wants the top layer, and the lower ones are never forwarded.
- Publishers already constrained on uplink. If someone has 3 Mbps up, spending 20% of it on layers is worse than publishing a single well-chosen stream. Bandwidth estimation will strip the top layer anyway, so you pay the encoder cost for layers that get discarded.
- Screen sharing of static content. A slide deck at 5 fps has an unusual bitrate profile and the lower spatial layers frequently render text illegibly. Temporal layers serve this case far better than spatial ones.
When simulcast earns its keep
It pays off wherever your subscribers differ from one another, which in practice means most real deployments.
- Grid layouts. The whole point: twenty thumbnails receive 125 kbps each instead of 2.5 Mbps each. In a 20-person room that is the difference between 2.5 Mbps and 50 Mbps of downlink per participant.
- Mixed device and network populations. One participant on fibre and one on a train, in the same call, each getting something appropriate.
- Large rooms generally, because the average forwarded bitrate is multiplied by N x (N-1) on the server side. Dropping the average from 2.5 Mbps to 600 kbps cuts the server's egress bill by roughly three quarters, which is far more consequential than the publisher's 20%.
That last point is the one that usually settles it. Simulcast costs one publisher a fifth more uplink and saves the server a multiple of that on every subscriber, which is a good trade at almost any room size above a handful.
Simulcast or SVC?
SVC — scalable video coding, available with VP9 and AV1 — achieves the same per-subscriber selection within a single encoded stream rather than several. In principle it is strictly better: lower total bitrate than simulcast, and one encoder instead of three, which removes the device cost entirely.
In practice the tradeoffs are real. AV1 encoding is computationally heavy in its own right, hardware support is less widespread than for H.264, and SFU support for SVC layer selection is less mature and less uniform across implementations than simulcast, which has been deployed for a decade. Simulcast is the safe default today. SVC is the direction of travel, and worth re-evaluating on a schedule rather than deciding once.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit all support simulcast, and building means you control the ladder, the layer-selection policy and the device-capability fallbacks. Layer selection is one of the two levers that change SFU scaling arithmetic. That control matters because the defaults are tuned for general use and the ladder mistake above is easy to make. It also means you own the mobile thermal behaviour, which is the part teams discover late.
Buy a cloud video API
Per-minute providers configure simulcast for you, usually sensibly. The limits are that you generally cannot tune the ladder for an unusual layout, and you may not be able to see which layer each subscriber is receiving — which is the single most useful diagnostic when quality complaints arrive.
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. Simulcast configuration matters here because average forwarded bitrate determines the egress on your own contract rather than a vendor's margin. It is resilient by design rather than something you assemble.
Where it does not fit: if your product is one-to-one calling, simulcast is not doing anything for you and none of this applies. And if you need to modify layer-selection behaviour at the source level, building on open source is the honest answer.
The Bottom Line
Simulcast costs the publisher about 20% more uplink, not 300% — because bitrate scales with pixel count and the lower layers are tiny. If your measured overhead is closer to 80%, your ladder steps are too close together, not your simulcast implementation.
The real cost is three parallel encoders on the publishing device, which is why mobile clients often publish two layers instead of three. And the real benefit lands on the server, where a lower average forwarded bitrate is multiplied across every subscriber in the room.
What's Next
The average forwarded bitrate discussed above drives the egress bill in what scaling past a single media server costs. If you are still choosing a routing model, SFU vs MCU vs mesh explains why only one of the three can do any of this.
Frequently Asked Questions
What is simulcast in WebRTC?
Simulcast is when a publisher encodes the same camera feed at several resolutions at once and sends all of them to the media server, which then chooses which version to forward to each subscriber independently. It lets one person's stream arrive as 720p for someone viewing full-screen and 180p for someone viewing a thumbnail, without the publisher sending two separate calls' worth of video.
Does simulcast use three times the bandwidth?
No. A typical ladder of 720p at 2.5 Mbps, 360p at 400 kbps and 180p at 125 kbps totals about 3.0 Mbps against 2.5 Mbps for the top layer alone — roughly 20% more. Bitrate scales with pixel count, and the lower layers have a fraction of the pixels.
Why did enabling simulcast nearly double my uplink?
Almost certainly the ladder spacing. If your layers are 720p, 540p and 360p, the middle layer alone costs more than half the top layer, and the total lands near 1.8x instead of 1.2x. Each step should roughly halve the width and height, which quarters the pixel count.
Does simulcast slow down the client?
It can. Three spatial layers means three encoders running in parallel on the publishing device. On desktops with hardware encoding this is usually fine; on mid-range phones it causes thermal throttling and battery drain that looks like a network problem. Many mobile implementations publish two layers instead of three for this reason.
When should I turn simulcast off?
For one-to-one calls, where there is only one subscriber and nothing to select between. For small rooms where everyone renders everyone full-screen. And for publishers whose uplink is already tight, since bandwidth estimation will strip the upper layer anyway and you pay the encoder cost regardless.
What is the difference between simulcast and SVC?
Simulcast sends several independently encoded streams; SVC encodes one stream in layers that can be selectively decoded. SVC uses less total bitrate and only one encoder, but hardware support is narrower and SFU handling of it is less mature. Simulcast is the safer default today.
Does simulcast help the server or the client?
Both, but the server gains more. The publisher pays about 20% extra uplink once; the server saves that difference on every subscriber it forwards to, and server egress is multiplied by N x (N-1). Lowering the average forwarded bitrate is the highest-leverage change available in a large room.
