Comments on: WebRTC Multiparty Video Alternatives, and Why SFU is the Winning Model

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Thu, 24 Sep 2020 17:34:47 +0000

In reply to Eduardo.

MCUs lost their shine.

Almost all modern solutions today use an SFU model for their video delivery. The challenges you speak of exist, but for most make no difference. The cost of an MCU is restrictive, especially considering that it is 10-100 times more expensive to deploy than an SFU.

This doesn’t mean that MCU topologies aren’t good for anything. Just that the number of use cases they are now useful for (for a price/performance perspective) has greatly diminished.

By: Eduardo

Eduardo — Thu, 24 Sep 2020 17:28:52 +0000

A decent MCU will do a central heavy transcoding and prosessing tasks to give each participant a personal layout adapted to its preference/bandwidth, wilst form user side, the CPU load and Bandwidth usage will be the same for a three party conference than for one of 50 participants or more.
As you Tsahi already know, coming form the corporate videoconferencing industry, MCU is the best approach when you hace to take care of end users CPU/Bandwidth.
That was a main issue in the past, and it’s still a problme in several countries where internet connectons are slow and/or there’s not possible to get a powerfull CPU for everyone.
In my opinion, that’s why non corporative platforms have raised popularity home use and when little number of meetings with not many participants. But they showed the other face of that advantage when all the company needed to use it intensively during cuarantine social distancing time, when homeoffice use raised like a rocket.
I see several medium to large meetings (Education is a typical use case) with several problems related to that, were the speakers need to reduce or cancel gallery view of participants to maintain a stable and manageable meetring environment.
Adding the lack of hardware acceleration availability os fome codecs (not H.26X precisely), then the CPU starts to have a heavy duty when encoding camera and shared screen, whilst decoding 25 incoming videos to build the local layout.

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Thu, 25 Jun 2020 21:25:04 +0000

In reply to Krishna.

On a 3-way or bigger group call, do the following:

* Open chrome://webrtc-internals
* Check how many incoming and outgoing voice/video channels you see
* 1 incoming and 1 outgoing voice/video channels that is an MCU
* 1 outgoing and many incoming voice/video channels that is an SFU
* many incoming and many outgoing voice/video channels that is Mesh

Not always, but close enough.

By: Krishna

Krishna — Thu, 25 Jun 2020 21:22:40 +0000

How to find a particular site is using Muc or SFU or Mesh?

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Tue, 29 Jan 2019 21:09:08 +0000

In reply to mekya. Mekya, Thanks for sharing. I didn't know this about the AntMedia server.

By: mekya

mekya — Tue, 29 Jan 2019 19:54:02 +0000

Another approach is Adaptive SFU

We use this approach at Ant Media Server https://antmedia.io
In addition it supports traditional SFU as well.

By: Zohar Babin

Zohar Babin — Fri, 23 Jun 2017 12:46:21 +0000

Philipp is correct, it’s never just one or the other – outside of peer 2 peer one on one call, most use-cases will require a mix of both architecture.

A typical “MCU” focused vendor will decode all incoming streams and merge all decoded streams into one in one encoding pass (one per template times ABR flavors). Then clients will be able to chose between templates (usually there are no more than 3: active speaker, grid, and active + screenshare). It will then also include routing in that it will decide which client should receive which flavor and template. It will be far more efficient on bandwidth consumption (each client only upload once, and download once), and indeed little more taxing on CPU.. here’s why it’s not “by far” more encoding:

A typical “SFU” doesn’t just re-route streams, because if it did, you’ll always end up with poor user experience with many interruptions due to network load. If your conference includes more than 2 participants, in a pure SFU architecture each participant will have to upload once (or more in case there’s ABR) and download several streams (one per participant). Such a scenario will be very taxing on bandwidth and since in most cases upload connections are slow, it’s also impractical to achieve proper ABR with pure SFU. Hence, a more common SFU implementation will also include decoding and encoding, in-order to create the ABR flavors of each participant (which means transcoding pipe per client per flavor), and then it will route the proper flavor to each client. It will still be heavier on bandwidth due to each client receiving multiple streams instead of one. Additionally, the SFU architecture is taxing on the client side rendering side too, and thus requires further specialized applications to be installed on the client side.. as most mobile browsers will crash in the face of having to play multiple video streams concurrently.
In addition, another downside of an SFU is that connecting to devices and applications such as room systems and/or broadcasting to sites like YouTube and Facebook will always require further encoding (usually called “Gateways”) in order to mix all streams into one rtmp/rtsp/webrtc upload.

The exception to above described SFU challenges is ; SVC based SFU. Bringing an important advantage over pure SFU/MCU: It requires less encoding on the server (MCU) for ABR or less upload BW is needed (SFU). In an SVC based SFU each client uploads an “onion of video quality layers” (Read more; http://info.vidyo.com/rs/vidyo/images/WP-Vidyo-SVC-Video-Communications.pdf), the server is then able to decide which layers to send to each client depending on the client, screen size, network connection, etc. This makes the server significantly more efficient, since it’s able to deliver ABR video without having to perform transcoding on the server. Lastly, even with SVC, supporting other devices/sites will require a Gateway for mixing all streams into one (including all browsers that don’t support SVC), and it often requires the use of specialized applications due to SVC being more complex to implement and rather new in browsers.

By: Philipp Hancke

Philipp Hancke — Mon, 07 Mar 2016 22:10:49 +0000

There is no such thing as an “MCU architecture” or an “SFU architecture”. Your system architecture will include one or both building blocks. If you only need a SFU: lucky you!

By: Robert Welbourn

Robert Welbourn — Mon, 07 Mar 2016 18:52:14 +0000

One other thing to bear in mind is that, with an SFU, it’s a relatively easy thing to alter the layout of the web page or mobile app to suit the service provider’s needs. With an MCU, you’re pretty much stuck with whatever screen layout the MCU vendor offers, such as 1 large video + 5 small.