原文地址👇

https://blog.livekit.io/an-introduction-to-webrtc-simulcast-6c5f1f6402eb/

你想知道的关于Simulcast的一切

Simulcast是WebRTC中最酷的功能之一,它允许WebRTC会议在参与者网络连接不可预测的情况下进行扩展。在这篇文章中,我们将深入探讨Simulcast的工作原理,以及它如何与像LiveKit这样的SFU协作,以支持更大规模的WebRTC会议。

“慢速”用户(网速慢)的挑战

Selective Forwarding Units(SFU)已经成为基于WebRTC的会议的主流架构。它们的作用是将一个用户的数据转发给房间中的其他用户,从而显著减少每个用户必须发送的数据量。近年来由于SFU扩展相对简单,获得了相当大的普及。由于它们不需要对媒体进行编码/解码,因此转发数据通常只需要很少的CPU开销。

虽然直接转发接收到的流使得架构和程序变得简单,但真实的网络条件提出了一些挑战。具体来说,并非每个人都拥有足够快的互联网连接来接收其他人发布的流。从“慢速”用户加入会议的那一刻起,这个问题就变得非常明显。

用户C将收到断断续续的流

由于慢速用户的下行带宽不足以获取其他用户正在发送的高质量流,所以他们在接收端会遭受高数据包丢失,导致画面质量不连贯或出现黑屏/空白帧。随着下游带宽达到饱和,拥塞也会影响用户上传自己视频的能力。

更糟糕的是,慢速用户的WebRTC客户端将不断向其他发布参与者发送PLI(画面丢失指示)消息(通过SFU),因为它无法接收足够的数据包来渲染帧。当其他WebRTC客户端看到PLI数据包时,它们会通过生成新的关键帧来响应,这些关键帧需要发送给每个人,增加整个会话的带宽需求。增加的带宽需求可能触发级联效应,当它超过其他参与者的带宽限制时。

在一个大量人员的会议中,房间中有人连接欠佳的可能性会增加。每个会议最终都会遇到这个慢速用户的问题。所以,为了确保平滑和高质量的传输,我们有三个选择:

  • 使用可缩放编解码器,如VP9或AV1
  • 降低每个人的数据流比特率,以免超载慢速用户(即最低公共比特率)
  • 向参与者发送独立的数据流,以适应每个用户的可用带宽

可伸缩视频编解码器

值得一提的是一些较新的视频编解码器及其权衡。VP9和AV1都内置了可伸缩性:它们以一种可以适应多个目标比特率的方式进行编码。但是,它们确实存在一些缺点(截至2021年8月):

  • VP9不支持Safari,且CPU密集型更高
  • AV1仅支持Chrome

虽然未来前景光明,但如今,这两种编解码器在动态比特率方面都不是实际的解决方案。

Simulcast登场

Simulcast允许WebRTC客户端发布同一源轨道的多个版本,具有不同的编码(即空间层)。在LiveKit中,参与者发布高分辨率、中分辨率和低分辨率版本的同一视频,这些视频以不同的比特率进行编码。

Simulcast旨在与SFU一起使用,其中SFU接收跟踪的所有三层,并对每个订阅者选择转发哪一层。

SFU选择向User C发送低分辨率流

从订阅者的角度来看,Simulcast是不可见的。WebRTC轨道设计时就支持动态调整分辨率。对于订阅者来说,这使得SFU可以在其带宽改变时切换到不同的层,同时保持连续的视频流无中断。

这是否意味着发布者需要发送更多数据?是的。但是,较低分辨率的层消耗的带宽远少于高质量版本。例如:

  • 原始/高分辨率:1280 x 720 @ 2.5Mbps
  • 中分辨率:640 x 360 @ 400Kbps
  • 低分辨率:320 x 180 @ 125Kbps

使用Simulcast,发布者只需要大约17%的额外带宽就可以发布所有三层。

通过更高级的反馈机制,带宽使用量还可以大大降低。如果某人的视频在接收端严格只呈现为缩略图,为什么还要发送720p层呢?每个订阅者都可以通知SFU它实际需要的层。

看一下Zoom的网络统计数据,你会发现他们管理这一点做得非常好。当参与者不是主讲人,并以缩略图的形式显示给其他人时,Zoom客户端只发送320x180层。

空间与时间可伸缩性

我们介绍了空间层,那么时间可伸缩性又是什么呢?本质上,时间可伸缩性是通过动态降低流的帧速率来降低流比特率的能力。

非可伸缩视频流中的帧,每个帧引用前一帧 

Untitled

这个想法很简单,但复杂性在于视频的编码方式 - 流包含主要是delta帧,这些帧依赖于之前的帧。如果解码器需要对被跳过的帧应用delta,它无法渲染后续帧。 为了使时间可伸缩性能够工作,编码器需要提前规划帧依赖性。

具有两个时间层的可伸缩流中的帧 

Untitled

VP8支持时间可伸缩性,当使用Simulcast时,浏览器会自动启用它。在上面的图中,我们看到一个具有两个时间层的启用了时间可伸缩性的流。我们使用TID来表示时间层:基本层具有TID 0,增强层具有TID 1。基本层上的帧仅引用其他基本层帧。 对于带宽有限的订阅者,我们可以跳过发送所有TID 1的帧,仅转发TID 0的帧。 这有效地将带宽需求降低了约50%,同时保持原始流的质量。 时间可伸缩性更适合内容如屏幕共享,其中清晰度大于FPS。


SFU中发生了什么?

为了支持Simulcast,SFU需要执行一些额外的步骤来完成这种神奇的操作。让我们继续看下面的内容。

重写序列号和时间戳

每个RTP数据包都包含一个序列号,指示流中其顺序,以及时间戳指示何时应播放帧。 WebRTC客户端依靠序列号来检测丢包情况,以及是否应该重新请求(NACK)该数据包。 当客户端收到序列号存在间隙的情况时,它会假设数据包在传输中丢失了。

对于Simulcast的轨道,每个层都作为一个独立的轨道发送,并带有自己的序列号集。 当SFU在层之间切换时,序列号中会有间隙。 对于时间层也是如此,当跳过某些帧时,传出序列号中会有跳跃。

为了补偿这一点,SFU需要跟踪每个订阅者的序列号,并重写每个数据包的序列号。 即使在重传丢失数据包时也需要维护此映射。(译者:也就是说对于订阅客户端来说接收到的rtp seq序号必须是连续的,而不会随着切换不通质量的流seq发生不连续的情况。)

带宽估计/拥塞检测

那么,我们如何知道要为每个订阅者发送哪个空间和时间层呢?理想情况下,它应该是其连接可以处理的最高质量流。 但如何确定呢?

事实证明WebRTC通过RTCP数据包内置了一些简洁的反馈机制:​​​​​

  • 接收者报告(RR):接收者定期发送报告以指示丢包率和抖动等信息
  • 传输范围拥塞控制(TWCC):允许发送方检测接收端的拥塞
  • 接收端估计最大比特率(REMB):接收端定期发送报告,指示估计的可用带宽。 (注意:如今TWCC优于REMB)

SFU接收反馈,并使用拥塞检测算法来估计可用带宽量。我们必须将码率维持在信道的可用带宽内,以避免拥塞。当拥塞发生时,我们将看到数据包丢失量增加,这将导致视频和音频冻结和失真。

跟踪订阅者层(Keep track of subscriber layers)

对于每个订阅者和轨道组合(track combination),SFU需要跟踪:

  • 订阅者希望哪个空间层?例如,如果客户端只需要320x180的流,那么我们就不应该发送任何更码率更高的流。
  • 订阅者的带宽允许哪个空间和时间层?

然后根据以下规则为每个订阅者做出决定:min(desired, allowed)(译者:也就是说sfu应该先得到观众期望的码率,然后再和允许发送的最大码率的值进行比较,取二者的最小值。)


处理发布者约束(Handling publisher constraints

到目前为止,我们已经介绍了如何处理订阅者的带宽限制。如果发布者存在上行带宽限制怎么办?如果发布者具有有限的上行带宽,则无法成功发布所有三个空间层。

浏览器处理这种情况的行为相当不错。 当带宽有限且启用了Simulcast时,WebRTC将禁用高分辨率层,直到它可以在不明显丢包的情况下发送流。您可以通过WebRTC统计信息观察到这一点,其中qualityLimitationReason设置为bandwidth。 类似地,如果发布者的处理器无法足够快地编码三个独立的层,则qualityLimitationReason设置为cpu。

chrome://webrtc-internals

但是,当浏览器决定停止发送层时不会提前通知SFU。 任何订阅终止层的订阅者都将停止接收新数据包,这会导致观众看到静止的画面。(译者:换句话说,如果浏览器在没有任何征兆的情况下停止上传某一个清晰度的流,那么正在订阅这个清晰度的观众则会看到画面卡死。)

这种情况这是不可取的, 将订阅者置于可用的较低分辨率层上会提供更好的体验。您可能已经猜到,这又是一个SFU需要解决的问题。 SFU需要监视每个层上传入数据包的中断情况, 如果检测到某个层上的数据中断,则会将该层标记为不可用,并将订阅者移动到替代层。您可以在StreamTracker中看到LiveKit如何处理此问题。

浏览器行为

我们需要特别注意当浏览器遇到带宽瓶颈的情况。当浏览器将某个清晰度的层禁用后,浏览器将在几秒后尝试重新启用它,只是为了在发现带宽没有改善时再次禁用它。 此波动在webrtc-internals图表中非常明显。 您可以使用MacOS中的网络链接条件仿真器模拟低带宽链接。

Untitled

framesEncoded/s和framesSent/s都呈现波动

通过测试我们已经发现一旦浏览器开始波动,即使带宽恢复后,它也会保持在这种状态。 这一点很出乎意外,我们推测可能是由于SFU或Google的WebRTC实现中的带宽估计逻辑错误造成的。 需要进一步的研究来查明根本原因。

客户端层管理

为了确保网络条件改善后视频质量可以恢复,我们在客户端引入了对simulcast编码的自定义管理。 这利用了WebRTC暴露的一些接口:

  • 通过RTCRtpSendParameters.encodings获取特定轨道的编码列表
  • 通过设置RTCRtpEncodingParameters.active控制层是否活动。 将其设置为false时,浏览器将停止发送该层。

有了这些接口,客户端可以监控当前带宽。 在检测到限制时,客户端可以完全暂停较高码率的视频层(layer),并在更长的回退后尝试重新启用和发送(译者:推测是根据服务器端的反馈决定是否恢复被禁的视频层。我认为这种恢复操作是很谨慎的,应该是从算法角度看可以恢复之后再等待很长时间后才可以恢复,也就是调用RTCRtpEncodingParameters.active=true)。 我们发现这种方法可以解决波动行为,允许一致的质量恢复。

如果您仍在阅读,希望您发现这篇文章很有用。 虽然Simulcast增加了WebRTC实现的复杂性,但它对于提供高质量的多用户会议来说是必要的。

如果您正在寻找支持Simulcast的WebRTC会议平台,请试试LiveKit!

感谢Raja、Orlando和Russ审阅了本文的草稿。

Logo

音视频技术社区,一个全球开发者共同探讨、分享、学习音视频技术的平台,加入我们,与全球开发者一起创造更加优秀的音视频产品!

更多推荐