WebRTC Mesh vs SFU vs MCU: How P2P Video Topologies Actually Differ

Mesh, SFU, and MCU all get filed under "P2P video architecture," which invites a mix-up worth clearing up before going further: this is about how N people in a live video call see each other, a completely different problem from the content-delivery mesh covered in the CDN edge node article, where cached copies of one broadcast fan out to many viewers. Same word, two unrelated architectures. This one is about real-time, many-to-many communication, and which of the three topologies handles it depends entirely on how many people are actually in the room.

TL;DR:

• Mesh (full P2P): every participant connects directly to every other participant. For N people that's N×(N-1) total streams, a 4-person call already means 12 streams and 3 Mbps of upload for each participant. It holds up for 3-4 people and falls apart past five.
• SFU (Selective Forwarding Unit): a server receives one upload per participant and forwards it to everyone else without decoding it. No re-encoding means low server CPU cost, roughly $0.0008-$0.003 per participant-minute. This is what Zoom, Google Meet, and Microsoft Teams actually run.
• MCU (Multipoint Control Unit): a server decodes every stream, mixes them into one composite picture, and re-encodes a single stream per viewer. That's 4-10x the compute cost of an SFU at the same participant count, $0.008-$0.025 per participant-minute, and it's kept alive today mainly for bandwidth-constrained clients, not because it's technically superior.
• Participant count maps almost directly to topology: mesh for 1-4, SFU from roughly 5 to a few hundred, and a hybrid SFU-plus-CDN approach once a broadcast scales into the thousands.
• None of this describes AIOZ Stream's current architecture. Its on-demand delivery runs on HLS today, not WebRTC, this is protocol-choice education relevant to interactive, many-to-many use cases rather than AIOZ Stream's present one-to-many broadcast model.

Mesh: the math that breaks it

Full mesh is the simplest topology to reason about and the fastest to outgrow: every participant opens a direct connection to every other participant, with no server touching the media at all. For N participants that works out to N×(N-1) total streams in the call, since each person both sends to and receives from every other person. A 4-person call means 4×3 = 12 total streams, and each individual participant is running 3 upload streams and 3 download streams simultaneously, at 1 Mbps per stream that's already 3 Mbps of upload bandwidth and real CPU load just for one person's device to encode three separate outgoing copies. The often-cited real-world ceiling: mesh "holds up for 3-4 people on decent devices; past five it burns mobile batteries and saturates uplinks," since the growth is quadratic, not linear, doubling the room size roughly quadruples the total bandwidth in play. No server means no infrastructure cost, which is exactly why mesh remains the right default for a small 1:1 or small-group call and exactly why it's the wrong choice for anything bigger.

SFU: forward, don't decode

An SFU breaks mesh's quadratic growth by putting a server in the middle, but the specific thing that server does, or rather doesn't do, is what makes it scale. Each participant uploads their stream exactly once, to the server, and the SFU forwards that same encoded stream out to whichever other participants need it, without decoding or re-encoding it at any point. That single design choice is why per-participant server CPU stays low and latency stays close to a direct connection's, the server is doing packet routing, not video processing. That efficiency is exactly why Zoom, Google Meet, and Microsoft Teams all run SFU-based architectures today, with simulcast layered on top so a single meeting can serve a participant on a phone and a participant on a 4K monitor different quality streams of the same source without any server-side transcoding. Cost reflects the light server load directly: SFU infrastructure runs roughly $0.0008 to $0.003 per participant-minute, cheap enough that SFU is the default choice from small group calls up through several hundred simultaneous participants.

MCU: mix everything into one stream

An MCU takes the opposite approach: it decodes every incoming stream, composites them into a single mixed picture, typically the familiar grid layout, re-encodes that composite, and sends one stream to each viewer. That's real, expensive video processing happening continuously on the server for the entire duration of the call, and it shows directly in cost: decoding and re-encoding N streams in real time typically runs 4 to 10 times the compute of an SFU at the same participant count, reflected in MCU pricing of roughly $0.008 to $0.025 per participant-minute versus SFU's lower tier. Given that cost gap, MCU isn't kept around because it's technically better, every major platform runs SFU-first architecture specifically because it scales better and costs less. MCU earns its keep in a narrower case: when the constraint is on the receiving end, a low-bandwidth dial-in connection, a 2G mobile link, or a thin client that can't afford to decode and render multiple separate video streams at once, since an MCU hands that client exactly one already-composited stream to display instead of several it would have to manage itself.

Matching topology to participant count

Room size is the variable that actually decides which topology fits, more than any other factor: a 1:1 call defaults to direct P2P with a TURN relay as fallback; 3-8 participants work on either a small SFU or a capped mesh; 9-50 calls for an SFU with simulcast; 50-200 adds active-speaker detection and server-side recording on top of the SFU; and a 200-1,000-person broadcast typically runs an SFU cascade or an MCU paired with Low-Latency HLS for the audience beyond what direct WebRTC connections can serve. Past roughly a thousand viewers, the standard pattern shifts to a hybrid architecture entirely: an SFU handling the interactive origin side, with LL-HLS and ordinary CDN infrastructure fanning the stream out to the broader audience, the same core reasoning already covered in the HLS vs. WebRTC article: WebRTC alone doesn't cache, so genuinely large audiences need HTTP-cacheable delivery at some point in the pipeline regardless of how the interactive origin side is built.

Where this fits for AIOZ Stream

Worth being direct about scope: none of this describes AIOZ Stream's architecture today. Its on-demand delivery runs on HLS, not WebRTC, a choice that makes sense specifically because on-demand viewers aren't all watching the same second at the same time, so the low-latency, non-cacheable properties mesh/SFU/MCU topologies exist to solve don't apply to that use case at all. This article is general protocol education, relevant to interactive, many-to-many scenarios like live Q&A or multi-guest broadcasts, the kind of use case that becomes directly relevant once true low-latency live streaming ships. Worth repeating the disambiguation from the opening too, since it's easy to blur: AIOZ's own DePIN-based content-delivery network, covered in the CDN edge node article, distributes cached copies of already-encoded content across many operator-run nodes, a caching and delivery problem. Mesh/SFU/MCU is about real-time media routing between live participants before anything is ever cached, a different layer of the stack entirely, despite the overlapping "peer-to-peer" vocabulary.

Frequently Asked Questions

What's the actual difference between mesh, SFU, and MCU?
Mesh connects every participant directly to every other participant with no server. An SFU is a server that forwards streams without decoding them. An MCU is a server that decodes, mixes, and re-encodes all streams into one composite per viewer.

Why does mesh fall apart past 4-5 participants?
Total streams grow as N×(N-1), quadratic rather than linear, so bandwidth and CPU load on each device climb sharply as the room grows, saturating uplinks and draining mobile batteries well before large-group sizes.

Do Zoom and Google Meet use SFU or MCU?
SFU. Every major platform, Zoom, Google Meet, and Microsoft Teams, runs SFU-based architecture with simulcast, reserving MCU-style mixing only for narrow, bandwidth-constrained edge cases.

Is MCU ever actually the better choice?
Yes, specifically when the receiving client can't handle multiple incoming streams, low-bandwidth dial-in connections or thin clients. It's not chosen for quality or cost, both favor SFU, it's chosen when the endpoint itself is the real constraint.

Does AIOZ Stream use mesh, SFU, or MCU?
None currently. AIOZ Stream's on-demand delivery runs on HLS, a different protocol built for cacheable, non-real-time playback rather than live many-to-many communication.

Is this the same "P2P" AIOZ Stream's DePIN network uses?
No. AIOZ's DePIN content-delivery mesh distributes cached copies of already-encoded video across operator-run nodes. Mesh/SFU/MCU governs live, real-time routing between call participants before any caching happens, a different part of the stack.

Related Reading

• HLS vs WebRTC: Which Streaming Protocol Should You Choose: the broader protocol tradeoff this article's topology choices sit inside
• What Is Low-Latency HLS (LL-HLS) and When to Use It: the hybrid delivery layer large broadcasts pair with an SFU origin
• Glass-to-Glass Latency Explained: the latency budget that makes topology choice matter in the first place
• What Is a CDN Edge Node and How Content Caching Actually Works: the different, content-delivery meaning of "P2P" this article deliberately disambiguates from
• AIOZ Stream Explained: where HLS-based on-demand delivery fits into the platform's overall architecture today

References

• Fora Soft: SFU vs MCU vs P2P, Choose a WebRTC Architecture: the bandwidth math, CPU cost comparisons, and participant-count topology table quoted above
• Fora Soft: P2P vs MCU vs SFU for Video Conference Apps: additional architecture comparison corroborating the cost and scaling figures above
• DEV Community: How Zoom Delivers Low-Latency Video: the real-world SFU-based platform examples (Zoom, Meet, Teams) cited above