若弱网环境下，云视频会议声音流畅性如何保证

保障声音的清晰流畅是每一场线上会议能够顺利进行的基础，为了给用户最优质的开会体验，全时的技术团队全力配合，对声音性能方面进行了改造升级，即使在丢包率高达70%的网络环境下，使用全时产品仍然能够正常沟通。

探讨流控，传输协议的选择是个绕不开的话题

网络会议音视频体验主要由两方面的能力决定：1）音视频核心编码及前/后处理能力；2）传输系统的弱网对抗能力，即根据网络状况实时调整传输策略和业务优先级的能力——简称流控。

如何选择，需要从以下三个方面考虑：1）协议特点；2）服务特点；3）开发难度和周期。基本的传输协议是TCP和UDP，先对比两个协议：

音视频数据量大，实时性要求高，根据上表分析UDP更合适。选择UDP可以保证传输效率，如何确保数据的时序性、完整性呢？是基于UDP自主开发RUDP（Reliable UDP）协议，还是采用开源项目？ 自主开发需实现带宽评估、丢包、延时、自动重传、发包控制等算法，每一项做好都不容易，同时互联网复杂多变，协议稳定需要做大量的测试，反复打磨；采用开源代码，需要考虑如何融合到已有框架，是否适应你的开发场景，比如时下最热的GCC有一套完整的流控方法， 但从webRTC中抽离出并非易事，而且GCC的流控是针对P2P系统开发的， 对于CS结构的服务如会议、群聊根本不适用。当然还有第三种方案，自己开发流控引擎，整合开源算法。 全时采用的是第三种方案，从webRTC中抽离出bitrate_controller、congestion_controller、pacing以及remote_bitrate_estimator等模块， 讲这些模块插入到全时流控框架。

做好流控，业务可分级、质量可动态调整是前提

好的音视频体验需要基本的网络保障，比如1080P、18PFS视频需要1.5mbps带宽，带宽不够怎么办？视频会按由高到低的优先级选择降码率——降帧率——降分辨率，如果网络状况还是太差，无法支持视频通话，则视频服务就会转换为音频服务。 全时会议对网络通信业务进行了严格的分级，音频优先级最高，然后桌面和白板，最后是视频业务。

这种降级处理的做法看起来简单，但做到平滑切换，需要优化编码器，普通编码在调整编码参数需要重新初始化，造成视频黑屏。而流控引擎也要能够识别不同业务包，根据优先级针对性处理，当网络带宽不够时，优先发送高优先级的数据包，而清包时则优先删除低优先级的数据包。

想要持续优化，必须有灵活、稳定的流控引擎

流控引擎本着可扩展，可插拔的原则，每当需要支持新的业务，不修改现有框架，能很方便的加入新的传输协议、丢包、延时、带宽评估算法。

全时流控引擎从模块隔离了传输、业务流、以及网监模块，见下图：

优秀的流控性能，需要在正确时间使用正确的方法

调整传输策略的另一个前提是监测到网络的状况。 全时网络监测模块整合了GCC算法（关于GCC算法网上有很多文章，这里不做描述），了解了网络情况，根据不同的网络情况使用不同的应对方案，提高抗丢包能力的方法有三种：FEC（Forward Error Correction）、ARQ(Automatic Repeat-reQuest)和PLC（Packet Loss Concealment），提升抗抖动能力使用Jitter Buff。

上图是音频流控策略，当丢包率小于10%， PLC+带内使用FEC法可以解决，而且对音质的变化，人耳基本无法区分；在延时小于50ms时采用ARQ， 可以把延时控制在300ms（50*2 + 80*3）以内：网络传输时间加终端处理和混音时间）， 而不会影响用户体验，其他区域采用带外FEC， 这需要理论结合实测，具体在什么丢包延时采用什么策略，这里不做详述。 以上是全时打造流控引擎的过程，通过制定业务优先级、动态调整FEC/ARQ、缩减音频包长度、提高数据传输时效、提高抗丢包能力等优化方案，我们就成功解决了弱网环境中音视频、桌面共享卡顿不流畅的问题。