共计 3972 个字符，预计需要花费 10 分钟才能阅读完成。
受疫情影响，许多公司曾经造成线上办公习惯，尤其是在线音视频会议，曾经成为一种常态。对于一些大型企业和组织机构来说，分支机构遍布全国各地，员工异地参会人数泛滥，大规模音视频会议成为刚需。而以后音视频会议主流产品中，单个会议最多反对 500 人入会进行互动。
然而 500 人同时线上散会，对于资源耗费比拟高。而传统的 WebRTC 架构并不善于超过 200 人以上的会议场景。在面对超大规模会议室、聊天室、直播等各种简单场景时，对流进行按需合流，能够升高带宽占用和设施压力；对流进行有抉择的订阅散发，有助于扩大各种组合场景。针对 App 具体的利用场景，能够配合订阅散发模式，组合应用 SFU 和 MCU 架构。下来咱们将详细分析一下大规模会议的资源优化策略。
1. 超大规模会议架构比照
WebRTC 多对多网络架构有 P2P、MCU、SFU 三种。各种网络拓扑的优缺点如下:
SFU 形式灵便，只有升高带宽就能够实现大规模会议的要求。
2. 超大规模会议中存在的挑战
在超过 20 人会议场景下，SFU 及 WebRTC 兼容场景依然无奈很好的解决。如果间接抉择参会人之间进行音视频互动，音视频数据齐全转发对服务器资源的要求是微小的，如果会议中有大量人员同时接入，服务端上行流量和上行流量陡增，会对服务器造成微小压力。
这里咱们来比照一下 20 人与 200 人同时加入音视频会议时，对服务端造成压力的差距：
20 人
各端流量：
20*(1Mbps+32Kbps)=20.64Mbps
服务端上行流量：
20*(1Mbps+32Kbps)=20.64Mbps
服务端上行流量：
20(20-1)(1Mbps+32Kbps)=392.16Mbps
200 人
各端流量：
200*(1Mbps+32Kbps)=206.4Mbps
服务端上行流量：
200*(1Mbps+32Kbps)=206.4Mbps
服务端上行流量：
200(200-1)(1Mbps+32Kbps)=41.07Gbps
从比照后果中能够看出，服务端上行流量间接回升了一个量级。如果采纳视频按需订阅，音频抉择出音量最大的几路能够大大降低上行流量。比方每个客户端订阅 4 路视频，服务器只需下发 4 路音量最大的音频，服务端上行流量只须要 2004(1Mbps+32Kbps)=800+25.6=825.6Mbps，能够极大缓解服务器压力。
若要解决下面的问题，倡议通过按需订阅与转发、音频流量两个方面来制订策略，在保障成果的前提下，升高服务端的压力。
3. 按需订阅与转发以及音频流量优化策略
3.1 按需订阅与转发
按需订阅与转发的形式有:
➀反对独自订阅某个人的某路视频或某路音频。
➁接收端仅订阅正在谈话的人的视频，音频全副订阅。
➂融云 SDK 反对发送端视频编码反对大小流。接收端按需订阅大流或小流。大流的清晰度高，码率高；小流的清晰度低，码率低。这样当接收端想观看清晰视频的时候订阅大流；对清晰度要求不高的时候订阅小流。另外，弱网下主动切换大小流，能够保障视频的流畅性。
3.2 音频流量优化策略
针对音频全副订阅有以下几种优化音频流量的办法。
3.2.1 发送端静音时不发送数据
WebRTC 的音频 codec 如果采纳 Opus，能够开启 Opus 的 DTX(Discontinuous Transmission)。SDP 对应的设置为 usedtx=1。但测试中发现流量降落不如预期，因为用户的应用环境多少有点背景音。背景音量很容易超出静音阈值。像 Android/iOS 这种定制开发端能够手动调整静音阈值，而 PC 的 Web 端因为是浏览器，则无奈调整静音阈值。
3.2.2 调整音频码率
通过设置客户端上音频码率，升高客户端上行的音频码率。当音频路数跟多的时候，限定每一路的音频码率后，总的音频码率会缩小很多。SDP 设置形式 b=AS: 码率。上面是摘自 RFC3556 的原文:
3.2.3 服务器下发音量 Top N 路
客户端收到音频流，在音频解码后，默认个别仅混流播放音量最大的 3（WebRTC 中的 kMaximumAmountOfMixedAudioSources 值）路声音。所以防止不必要的音频包的转发能够缩小服务流量的。步骤如下:
➀发送端通过 Audio Level 标识音频能量。
➁音频包进入 SFU 转发队列，先进入计算队列，定期弹出 Top N 的音频包。
➂只有无效音频包，会进入到上行散发队列。
上面介绍音频如何转发音量最大几路的办法实际。
4. 音频 Top N 抉择
4.1 客户端解决
客户端会计算出音量大小，并把值记录在 RTP 包中。所以客户端须要开启 audio-level 的 RTP 扩大, 如下: a=extmap:1urn:ietf:params:rtp-hdrext:ssrc-audio-level 开启这个 RTP 扩大后，WebRTC 客户端机会计算 audio 包的音量大小。这个音量大小计算方法 RFC6464 有明确定义。WebRTC 中的计算方法为 modules/audio_processing/rms_level.cc 的 ComputeRms 办法:
客户端通知服务器音频包的音量大小。服务器收到音频包后不必做解码，就能晓得从客户端上来的音频包的音量值，为前面的服务器音频包下发策略奠定了根底。
4.2 服务器解决
上面用 Publisher 示意发布者的音频流，Subscriber 示意订阅者的音频流。RtpAudioPacket 示意一个音频包。RtpAudioPacket 里有个 mute 属性，标记这个音频包时是否静音。
在没有音频依据音量大小转发的逻辑前，Publisher 和 Subscriber 的解决关系如下。
Subscriber1、Subscriber2、Subscriber3 订阅 Publisher1、Publisher2、Publisher3。Publisher 发上来的音频包都会转发给各自的订阅者。
音频依据音量大小转发的逻辑如下：
➀AudioLevelHandler 示意每个 Publisher 的音频处理单元。AudioLevelHandler 里有两个音频包缓冲队列，计算队列 calculate_queue 和发送队列 send_queue。Publisher 的音频包先进入计算队列 calculate_queue 中。有个定时计算工作 AudioLevelCalculator。AudioLevelCalculator 会每隔一个音频打包工夫 ptime 进行一次对所有 Publisher 的计算队列里音频包的 audio_level 均值（因为均值示意这个 Publisher 收到的若干个音频包的音量）做排序计算，选出音量值最大的几路。这几路的音频包 RtpAudioPacket 的 mute 被标记为 false，而其余音频包标记为 true。
➁排序后，这些音频包会从计算队列里移入到发送队列 send_queue 中。
➂之后音频包从 send_queue 出队，转发给 Subscriber。Subscriber 中的 MuteHandler 有以下两个作用:
a. 依据 RtpAudioPacket 的 mute 属性，mute 为 true 时，这个音频包间接被吞掉，false 示意转发给订阅者。
b. 因为下发给订阅者的音频包 RTP 序号 SeqNum 不是间断的，须要做间断化解决。
上面图中 Subscriber1、Subscriber2、Subscriber3 订阅 Publisher1、Publisher2、Publisher3。假如 Publisher1 收到的以后音量最大，最终只有它的音频包会转发给 Subscriber1、Subscriber2、Subscriber3。
4.3 级联的思考
比方上面的图中，Subscriber4 通过级联服务器连贯到以后 MediaServer 上。Publisher1、Publisher2、Publisher3 的音频包都会间接转发级联服务器。由级联服务器负责计算 Top N 音频包的计算下发给 Subscriber4。
上面是这部逻辑的伪代码:
4.4 音频下发策略优化
事实中人的谈话是有进展的。比方进展前后人声比拟大，如果简略的排序下发音频包，客户端会收到间断的非静音包。经测试，这样的体验并不现实，因而须要退出平滑解决。这里 history 为过来若干次的音频是否进入 Top N。音频包是最大的几路中的，退出 history 队列尾部退出 true，转发示意此次声音大而发。否则，退出 history 队列尾部退出 false。因为本次静音，还需判断过来的静音状况，若 history 中有 true 值，转发可示意过来一小段说过话，所以须要转发。若 history 中全为 false, 不转发则示意本次声音不大，过来一小段声音也不大，所以不转。
4.5 其余相干策略
➀当会议中的人数绝对比拟的少的时候，音频包为下面所述的失常转发。而当多个 Publisher 的订阅人数超过某个阈值（比方 50），此时 MediaServer 发的音频码率很大，对应客户端也要收相应的音频流量。这时能够走超大会议音频最大几路转发逻辑。而当会议中多个 Publisher 的订阅人数降落到阈值之下，再回归失常的转发逻辑。
➁通过选取最大几路流的下发形式，音频流量曾经大大降低了。而在此基础上理论设置的选取路数做少许冗余，能够多发一些有音量的音频包，进步接管方体验。
➂当参会者减少时，相应的 MediaServer 也须要动静调度。通过把参会者音视频流打到多个 MediaServer 上，通过级联的形式解决问题，保障每台 MediaServer 服务器上的 CPU、内存、带宽的失常。
5. 总结
以上是基于超大规模会议技术优化进行的策略方面的摸索。其次要思维是视频按需订阅，音频升高不必要的流量。其中波及客户端音量值的上传、服务器端音量抉择、级联、优化体验、缩小音频流量等多个方面。研发过程中，超大会议须要多测试，能力裸露其中的问题，从而进步最终的会议体验。