Stream Using SFU and MCU
To create a conference app to stream media, we need to create streams and establish the connection.
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).
A connection is an object that communicates between two endpoints using the LiveSwitch Media Server. Our Getting Started guide will teach you how to create the SFU and MCU connections.
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.
- Downstream connection: Receives video, audio, binary data from the server. Each participant has one downstream connection for every other participant in the video conference.
MCU stands for Multipoint Control Unit. An MCU is an endpoint in a media session that allows for large amounts 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 now responsible for performing all audio and video mixing.
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:
|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, AR/VR devices.
Next, we will 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 will build two apps on top of it.