什么是 WebRTC Simulcast？WebRTC Simulcast的优缺点及使用方式

拥有 SFU 媒体服务器的 WebRTC 应用程序通常会使用 WebRTC Simulcast。如果您的媒体服务器不使用Simulcast，请务必询问原因并了解答案。如果使用了，那么你就应该知道它的确切含义。

本文将解释什么是 WebRTC Simulcast、何时使用、如何使用以及 Simulcast 的一些新进展。

作者：Tsahi Levent-Levi
译自(节选)：https://bloggeek.me/webrtc-simulcast/

关于视频质量和比特率

在开始之前，我们需要了解比特率的概念。在 WebRTC 视频会话中，首先要查看和了解使用的比特率。视频编码需要在网络上发送大量数据，WebRTC 会根据网络的可用带宽来匹配发送的比特率。

对我来说，发送数据才是我们要做的。比特率是我们所追求的实际（或目标）数据量，而带宽则是我们在网络上的可用带宽（假设带宽应始终与比特率相同或甚至更高）。

说到音频，我们主要使用的是静态的、事先已知的比特率。与视频比特率相比，音频比特率也较低，因此我们并不太在意。剩下的就是视频流了。

对于视频流：

比特率越高，质量越高（大多数情况下）
比特率越高，编码和解码数据所需的 CPU 和内存就越大

这意味着我们要做的是使用尽可能少的比特率来获得尽可能高的质量。我们首先要确定所需的比特率，然后再根据实际情况降低比特率。原因如下：

CPU 负担过重，因此需要降低编码或解码的比特率
最终显示的视频分辨率会相当小，因此没有必要在比特率上投入太多。同样的逻辑也适用于摄像机
无法通过网络推送我们想要的比特率，因此需要降低比特率以适应网络带宽

SFU 媒体服务器和群组视频会话

对于 WebRTC 中的视频群组会话，我们使用 SFU 媒体服务器。并非总是如此，但大多数时候都是如此。为什么呢？因为 SFU 可以路由媒体——与 MCU 相比，SFU 的成本更低，而且在很多方面，SFU 还能让我们在观众端更加灵活。

不过，SFU 所面临的挑战是，与其他设备相比，SFU 需要更复杂的逻辑和更多的智能，而且它们还将很多工作委托给客户自己。好的 SFU 应与使用它的客户端紧密集成并采用优化方法。请记住，浏览器（Chrome 浏览器）的实现是针对 Google Meet 的需求进行优化的。

Simulcast就是为SFU “发明 “的。举一个简单的例子来说明我们的意思。

有 4 个人在通话。他们都连接到一个 SFU。每个与会者将自己的视频发送到 SFU，SFU 再将视频转发给通话中的其他 3 个与会者：

什么是 WebRTC Simulcast？WebRTC Simulcast的优缺点及使用方式

如果每个人都有一个良好的网络，那么我们都会很高兴。但如果 D 的下行链路网络状况不佳呢？以下是一些假设：

所有参与者都能向 SFU 发送 2Mbps 的视频数据
A、B 和 C 在下行链路上总共可接收 20Mbps 的数据
D 在下行链路上总共只能接收到 1Mbps 的数据

如果要在 D 的屏幕上以相同质量显示每个人，需要给每个人提供 ~330Kbps 的传输速率。而不是 2Mbps。那么……我们是否要将每个人的发送比特率降低到 330Kbps，以满足用户 D 的需求？还是让他完全退出通话？

如何仍能从 D 向其他参与者发送 2Mbps 的数据了吗？这就是本例中网络的性质和动态以及我们所具备的能力。

这就是 Simulcast 的作用所在…

我们将设计一个解决方案，让每个参与者都能为自己的视频数据创建 3 个独立的比特流： 1150kbps、600kbps 和 250kbps，总计 2Mbps。具体数字并不重要，重要的是概念本身，因此请顺其自然。

* 由于懒惰，我将Simulcast 线表示为虚线，而不是使用 1150/600/250 这样更好的符号。

现在我们这样做，A、B 和 C 从其他人那里获得 1150Kbps 的视频，而 D 则接收较低的 250Kbps 比特流（它无法处理 1150kbps 或 600kbps 的视频，即使只有其中一个用户，它也不会放弃接收其他视频流）。现在，每个用户都能获得他所能处理的最大比特流（或者至少比降低每个人的比特流更接近于最大比特流）。

介质质量：LCD 或 BAB

我将使用不一定存在的名称。我在这里使用它们是为了更好地解释 Simulcast 的本质。

在上面的示例中，我们看到了如何从 LCD（最小公有带宽）到 BAB（最佳可用带宽）。

我们从一种天真的实现方式开始，即向每个人发送相同的视频比特率。因此，如果会话中的某个地方出现故障，每个人都会受到影响。当 D 出现网络问题时，每个人都不得不将比特率从 2Mbps 降到 330Kbps……这对他们的媒体质量造成了相当大的影响。

这就是我们的 LCD – 我们需要将比特率调整到会议参与者可用带宽的最小公分母。这很糟糕。糟透了

但后来我们选择了 BAB – 要尽量使用每个用户都能接收到的最佳可用带宽。

我们是怎么做到的？我们要求参与者生成一个以上的比特流。每个比特流都有不同的比特率，这就为 SFU 提供了决定向哪个用户发送哪个比特率所需的灵活性。

我们之所以使用同步直播（或 SVC，但本文不使用），是因为数字通信中不存在平等。与会者使用不同的设备，连接不同的网络，甚至在同一次会议中看到和关注的内容也不尽相同。同步直播使我们能够根据每位与会者在任何特定时刻的能力，以及每位与会者的偏好/愿望，为不同与会者提供不同质量的会议视图。

我们能达到多大的灵活性和多高的媒体质量，取决于我们在实施过程中最终采用的工具和优化方法。没有两个同步直播 SFU 的实施方案是完全相同的。

客户端 = Simulcast；服务器端 = 自适应比特率

Simulcast 作为一种概念和解决方案，是指客户端生成多个数据流，这样媒体服务器就可以使用其中的任意一个数据流发送给其他参与者。

视频流有一个类似的（？）解决方案，称为 ABR（自适应比特率）。

在这种情况下，客户端向服务器发送单一媒体流，而服务器则根据需要以不同的比特率生成任意数量的媒体流。当有许多观众（成千上万或更多）时，这样做是有意义的，而且在特定情况下投资服务器资源（提供服务的供应商需要花钱）也是有用的。

有些人使用 ABR 这个术语，只是说比特率是可变的，并能适应网络。我用它来指服务器端自适应，即（提前或实时）生成多个视频流，服务器只需为每个观众选择最佳视频流即可。

对于大规模直播流媒体广播，你可以开始看到一些解决方案将 ABR 作为一种技术，用于对服务器上的广播流进行转码并生成多种比特率。有时，在使用客户端 Simulcast 的同时，也可以这样做。

我是如何区分和记住这一点的？Simulcast 是由客户端生成多个比特率。ABR 是服务器生成的多个比特率。

在 WebRTC 中使用 Simulcast 的优缺点

Simulcast 非常好，但它不是万能的解决方案。

Simulcast 的概念是卸载媒体服务器的部分工作。这里的卸载意味着客户端需要增加 CPU 的使用和所需的外向带宽。

WebRTC Simulcast 的优势

以下是 Simulcast 带来的一些好处：

1. 大幅降低媒体服务器的成本

由于无需对媒体流进行解码和编码，媒体服务器所需的 CPU 功耗大大降低
这意味着扩展大型部署变得更容易，在更多用例中更可行

2. 为每个参与者提供不同的布局

由于每个用户最终都会接收到多个视频流（比特率不同），因此应用程序可以自由地为每个参与者显示不同的布局
其他混合媒体的媒体服务器需要投入更多的 CPU 来支持类似 “每个参与者编码器 “的功能，才能实现这一目标

3. 在同一空间显示与会者的视频和其他数据

同样，由于每个参与者的视频都与其他视频分开，因此在同一区域放置其他可视项目会更简单
将所有视频混合到一个数据流中会增加难度和笨重程度

WebRTC Simulcast 的弱点

但这并不全是好事。使用 WebRTC Simulcast 也有弱点：

1. 用户上行链路使用的带宽较高

网络带宽有时不对称（想想 ADSL），上行链路通常比下行链路带宽低
与不使用 Simulcast 相比，Simulcast 对上行链路的要求更高（准确地说是 1.3125 倍），这意味着在某些情况下，如果操作不当，使用 Simulcast 实际上会降低质量

2. 用户设备的 CPU 占用率更高

使用 Simulcast 时，客户端会生成 2-3 个不同比特率的媒体流
因此，在使用 CPU 时，他们对编码的 “投资 “更大

3. 系统复杂度更高

要真正在 WebRTC 中使用 Simulcast，客户端和服务器代码之间应该有更多的同步
这意味着整个系统的复杂性更高

4. 对客户端代码的依赖

使用其他解决方案，尤其是媒体混合解决方案，客户端甚至可能不知道他们处于群组通话中
但是，当涉及 Simulcast 和群组通话时，客户在确保通话质量方面发挥着巨大作用（由于上述复杂性）

Simulcast 中的关键帧和切换成本

有了这些优点，还有一个致命弱点。这不仅源于谷歌在 Chrome 浏览器中实现同步直播的方式，也是这种解决方案的现实问题。

问题是：每当观众从一个 Simulcast 层切换到另一个 Simulcast 层时，解码的视频流都会发生变化。这种变化只有在切换到的层上出现新的关键帧时才能发生，这样视频解码器才能正确解码视频流。

当需要在 Simulcast 中生成关键帧时，Chrome 浏览器会自动在所有联播层生成关键帧。这并不是件好事，但事实就是如此。

这也意味着，SFU 媒体服务器需要注意这一点，不要让观众一直在不同层之间切换，将切换次数限制在保持高视频质量所需的最低限度。

Temporal scalability 改进了 WebRTC 同步广播

在 WebRTC 中同时使用时间可适性(temporal scalability)和Simulcast 时，我们可以获得更高的灵活性。

在 Temporal scalability 中，视频流帧的编码方式使我们能够解码某些帧而不是其他帧，这在视频压缩中通常是不可能的。WebRTC 的实现在 Chrome 浏览器的 VP8 中具有时间可扩展性，有 2 个这样的 “层”，因此如果您每秒发送 30 帧，SFU 媒体服务器可以决定向参与者发送 30 或 15 FPS（每秒 15 帧的比特率大约是每秒 30 帧的 60%）。

这就好比在不增加成本的情况下成倍增加您的Simulcast 流：