怎么做vip网站,展馆展示设计公司排名,wordpress e,wordpress主题文章页面不显示原文地址#x1f447;
https://blog.livekit.io/an-introduction-to-webrtc-simulcast-6c5f1f6402eb/
你想知道的关于Simulcast的一切
Simulcast是WebRTC中最酷的功能之一,它允许WebRTC会议在参与者网络连接不可预测的情况下进行扩展。在这篇文章中,我们将深入探讨Simulcas…原文地址
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层。
空间与时间可伸缩性
我们介绍了空间层,那么时间可伸缩性又是什么呢?本质上,时间可伸缩性是通过动态降低流的帧速率来降低流比特率的能力。 非可伸缩视频流中的帧每个帧引用前一帧 这个想法很简单但复杂性在于视频的编码方式 - 流包含主要是delta帧,这些帧依赖于之前的帧。如果解码器需要对被跳过的帧应用delta它无法渲染后续帧。 为了使时间可伸缩性能够工作,编码器需要提前规划帧依赖性。 具有两个时间层的可伸缩流中的帧 VP8支持时间可伸缩性当使用Simulcast时,浏览器会自动启用它。在上面的图中我们看到一个具有两个时间层的启用了时间可伸缩性的流。我们使用TID来表示时间层基本层具有TID 0增强层具有TID 1。基本层上的帧仅引用其他基本层帧。 对于带宽有限的订阅者我们可以跳过发送所有TID 1的帧仅转发TID 0的帧。 这有效地将带宽需求降低了约50%,同时保持原始流的质量。 时间可伸缩性更适合内容如屏幕共享其中清晰度大于FPS。 SFU中发生了什么?
为了支持SimulcastSFU需要执行一些额外的步骤来完成这种神奇的操作。让我们继续看下面的内容。
重写序列号和时间戳
每个RTP数据包都包含一个序列号指示流中其顺序以及时间戳指示何时应播放帧。 WebRTC客户端依靠序列号来检测丢包情况以及是否应该重新请求(NACK)该数据包。 当客户端收到序列号存在间隙的情况时它会假设数据包在传输中丢失了。
对于Simulcast的轨道每个层都作为一个独立的轨道发送并带有自己的序列号集。 当SFU在层之间切换时序列号中会有间隙。 对于时间层也是如此当跳过某些帧时传出序列号中会有跳跃。
为了补偿这一点SFU需要跟踪每个订阅者的序列号并重写每个数据包的序列号。 即使在重传丢失数据包时也需要维护此映射。译者也就是说对于订阅客户端来说接收到的rtp seq序号必须是连续的而不会随着切换不通质量的流seq发生不连续的情况。
带宽估计/拥塞检测
那么我们如何知道要为每个订阅者发送哪个空间和时间层呢理想情况下它应该是其连接可以处理的最高质量流。 但如何确定呢?
事实证明WebRTC通过RTCP数据包内置了一些简洁的反馈机制:
接收者报告RR接收者定期发送报告以指示丢包率和抖动等信息传输范围拥塞控制(TWCC)允许发送方检测接收端的拥塞接收端估计最大比特率(REMB)接收端定期发送报告,指示估计的可用带宽。 (注意如今TWCC优于REMB)
SFU接收反馈并使用拥塞检测算法来估计可用带宽量。我们必须将码率维持在信道的可用带宽内以避免拥塞。当拥塞发生时我们将看到数据包丢失量增加这将导致视频和音频冻结和失真。
跟踪订阅者层Keep track of subscriber layers
对于每个订阅者和轨道组合track combinationSFU需要跟踪:
订阅者希望哪个空间层例如如果客户端只需要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中的网络链接条件仿真器模拟低带宽链接。 framesEncoded/s和framesSent/s都呈现波动
通过测试我们已经发现一旦浏览器开始波动即使带宽恢复后它也会保持在这种状态。 这一点很出乎意外我们推测可能是由于SFU或Google的WebRTC实现中的带宽估计逻辑错误造成的。 需要进一步的研究来查明根本原因。
客户端层管理
为了确保网络条件改善后视频质量可以恢复我们在客户端引入了对simulcast编码的自定义管理。 这利用了WebRTC暴露的一些接口:
通过RTCRtpSendParameters.encodings获取特定轨道的编码列表通过设置RTCRtpEncodingParameters.active控制层是否活动。 将其设置为false时,浏览器将停止发送该层。
有了这些接口客户端可以监控当前带宽。 在检测到限制时客户端可以完全暂停较高码率的视频层(layer)并在更长的回退后尝试重新启用和发送译者推测是根据服务器端的反馈决定是否恢复被禁的视频层。我认为这种恢复操作是很谨慎的应该是从算法角度看可以恢复之后再等待很长时间后才可以恢复也就是调用RTCRtpEncodingParameters.activetrue。 我们发现这种方法可以解决波动行为允许一致的质量恢复。
如果您仍在阅读希望您发现这篇文章很有用。 虽然Simulcast增加了WebRTC实现的复杂性但它对于提供高质量的多用户会议来说是必要的。
如果您正在寻找支持Simulcast的WebRTC会议平台请试试LiveKit!
感谢Raja、Orlando和Russ审阅了本文的草稿。
