mediasoup性能瓶颈分析

mediasoup room在达到一定并发观众量时，就会发生画面不清晰，卡顿严重的情况。

故障发生时，观察到推流器obs的码率发生了严重下降，由正常的1.5Mbps下降到约400kbps，显然，这个encoding码率就会导致严重的画质问题。画面不清晰是由于过压(bitrate不足)导致的，而lag严重是由于FPS过低导致。

可能的原因：

1. Obs与服务端origin-node协商，降低了bitrate和fps。服务端是mediasoup-worker，应该是它检测到网络质量差的情况下，和encoding端协商降低quality level。
2. Obs推流过程发生严重的udp丢包行为。丢包有三种可能：Origin-node太忙，质量控制算法原因主动丢包，网络差。

几个room在同样的推流端网络条件下，应该不是网络差的原因。而origin-node cpu load不高，也就不是太忙的原因。唯一的可能性就是主动调降了quality level，进行了主动的丢包操作。为什么会主动调整quality level呢？可能的原因如下：

1. 一个worker承担的room超过了合理值。根据实测，一个cpu core能够支持400个并发，超过这个值后bitrate会快速下降，由此导致画质下降。

Action: 统计出ms-worker的数量，每个ms-worker上承载的room数量。

1. Ms-worker不是最新的code，一些bug解决了没有merge进来。

Action: 编译生成mediasoup-worker，更新到wrs-node项目。

1. Origin-node和edge-node没有切分开，由此导致wrs-obs被降级。

Action: 在edge-node做re-encoder，把两种类型节点完全切分开。

1. 不管什么机制触发了质量调节，不丢包。

Action: 推流侧改为RTCP/TCP传输，不用UDP。

由于我们并没有采用simulcast/svc分层质量等级机制，质量的下降应该是被动行为。换句话说，就是udp丢包比较严重，这首先应该发生在viewer side。在发生了viewer侧的严重丢包事件后，viewer-node会请求origin-node重传。这个重传机制带来的严重后果就是影响到推流端的传输功能，有效传输的bitrate下降，画质严重下降。

viewer侧的严重丢包，通过”重传请求”传递到了origin-node side，进而影响到推流端视频流传输，encoding stream quality发生严重下降。经过调查发现，async createPipeTransport({ listenIp, port, enableSctp = false, numSctpStreams = { OS: 1024, MIS: 1024 }, maxSctpMessageSize = 268435456, sctpSendBufferSize = 268435456, enableRtx = false, enableSrtp = false, appData = {} })

enableRtx = false，此重传功能就没有打开。

需要继续定位问题：Router的工作量分配不均等导致？

首先，升级mediasoup 至3.10.8. 为保证效果，mediasoup-worker需要合理分配，分离出一个单独的ms-worker作为pipe-worker来使用，而其它的ms-worker组成pool给user使用。多cpu框架下，一个cpu上启动一个ms-worker进程，这是由OS自动管理的。

重新编译最新的mediasoup-worker过程记录

$ Git clone GitHub - versatica/mediasoup: Cutting Edge WebRTC Video Conferencing

$ npm run typescript:build  //得到node/lib

$ cd worker&&make                 //得到out/Release/mediasoup-worker

把编译输出的结果手工copy到nodejs工程的node_moduels/mediasoup/下面即可，这是手工更新。