Stream Using SFU and MCU

To create a conference app to stream media, we need to create streams and establish the connection.

Streams

You've learned that local media captures the audio and video data of the local user, and that remote media displays the audio and video feeds of other users. The object that ties them together is called stream.

There are two types of streams:

  • Bi-directional streams that send and receive data.
  • Uni-directional streams that either send data (are called upstreams) or receive data (are called downstreams).

Connections

A connection is an object that communicates between two endpoints using the LiveSwitch Media Server. Our Getting Started guide teaches you how to create the SFU and MCU connections.

SFU

SFU stands for Selective Forwarding Unit. An SFU is an endpoint in a media session that enhances the scalability of video conferencing sessions by forwarding audio, video, and binary data that it receives from connected users. In an SFU configuration, each user only has one upstream connection to the server, substantially reducing the amount of upload bandwidth required to run a video conference. An SFU is a good middle-ground scaling option when you have an excess of bandwidth and a limited amount of CPU power.

When creating an SFU session, there are two different types of connections:

  • Upstream connection: Forwards your own video, audio, and binary data to the server, which then forwards it to other participants. Each participant in an SFU session has one upstream connection in a video conference.
  • Downstream connection: Receives video, audio, and binary data from the server. Each participant has one downstream connection for every other participant in a video conference.
graph LR A((A)) -.->|A|s(SFU)-->|B|A B((B))-.->|B|s-->|A|B C((C))-.->|C|s-->|A|C s-->|C|A s-->|C|B s-->|B|C classDef default fill: #D8EFF9,stroke:#86CBEE;

MCU

MCU stands for Multipoint Control Unit. An MCU is an endpoint in a media session that allows large amount of users to participate in a video conferencing session by mixing their audio and video streams together on the server. Each participant in a video conference connects directly to the MCU, and the MCU creates one combined audio and video stream, which it then sends back to everyone. For session participants, this mode uses the least amount of bandwidth and CPU, as each participant only has one upstream and one downstream connection. However, the downside is that this mode uses the largest amount of bandwidth and CPU resources on the server side, as the MCU is responsible for performing all audio and video mixing.

graph LR A((A)) -.->|A|M(MCU)-->|ABC|A B((B)) -.->|B|M-->|ABC|B C((C)) -.->|C|M-->|ABC|C classDef default fill: #D8EFF9,stroke:#86CBEE;

SFU vs MCU

When should you choose SFU and when should you choose MCU? In general, SFU is our recommended connection type in the most situations.

The following table compares the two:

Criteria SFU MCU
Server cost Low High
Bandwidth cost Unpredictable Predictable
Layout Participants have different video layouts Participants have the same video layouts
End-to-end encryption Yes No
Good for
  1. Broadcasting (one-to-many) or smaller video conferences of 15 people sending video or less.
  2. Can be optimized to handle larger numbers up to ~30 people streaming video.
  1. Many-to-many situations where the number of streaming participants is over 12-15.
  2. Can be optimized for larger sessions, and may need to split users into multiple MCU grids to achieve very large numbers.
  3. SIP or apps for lower powered devices such as Raspberry Pis, older phones, SoC boards, and AR/VR devices.

Next, we'll build two conference apps: one using the SFU connection; one using the MCU connection. Before we start, make a copy of the Remote Media app you have created earlier because we'll build two apps on top of it.