WebRTC SFU vs MCU: Key Differences Explained

Multi-party video conferencing in WebRTC relies on different backend architectures to connect multiple participants. This article explains the fundamental differences between a Selective Forwarding Unit (SFU) and a Multipoint Control Unit (MCU), focusing on how they handle media routing, server CPU utilization, bandwidth consumption, and client-side processing.

The Core Architectural Difference

The fundamental difference lies in how these two systems handle media streams.

An MCU (Multipoint Control Unit) acts as a centralized mixer. It receives audio and video streams from all participants, decodes them, mixes them into a single customized video grid and audio stream, encodes this new stream, and sends it back to each participant.

An SFU (Selective Forwarding Unit) acts as a media router. It receives media streams from all participants and forwards them to the other participants without decoding, mixing, or re-encoding them. The server simply decides which packets go to which destination.

Server-Side CPU and Scalability

Because an MCU must decode, composite, and re-encode video streams for every participant, it requires immense server-side CPU processing power. This computational overhead strictly limits the number of concurrent users an MCU server can support, making it highly expensive to scale.

Conversely, an SFU does not perform media transcoding. Because it merely routes network packets, its server-side CPU utilization is extremely low. A single SFU server can handle thousands of concurrent streams, making it highly scalable and cost-effective.

Bandwidth and Client-Side Processing

The trade-off for the SFU’s server-side efficiency is shifted to the client devices and network connections.

• Downlink Bandwidth: In an MCU architecture, each client only downloads a single incoming stream (the mixed layout). In an SFU architecture, if there are \(N\) participants, each client must download \(N-1\) individual video streams, requiring significantly higher downlink bandwidth.
• Client-Side CPU: An MCU client only decodes a single video stream, resulting in low CPU usage on user devices. An SFU client must decode multiple incoming video streams simultaneously, which can drain battery life and strain CPU resources on older or mobile devices.

Layout Flexibility and Customization

With an MCU, the video layout (e.g., active speaker, grid view) is decided and rendered by the server. Users have limited control over how they view other participants because everyone receives the same pre-mixed video feed.

With an SFU, because the client receives all individual streams separately, the client-side application has complete control over the layout. Users can customize their user interface dynamically—such as pinning specific speakers, resizing windows, or filtering video feeds—without impacting other participants.

Latency

The heavy processing required by MCUs to decode, mix, and encode media streams introduces noticeable latency into the conversation. SFUs, by avoiding the transcoding pipeline altogether, route packets almost instantaneously, resulting in much lower latency and a more natural conversational flow.