如何提升实时音视频质量

客户端常见指标和应对策略

客户端实时音视频质量提升目前主要有以下几个方面

音视频连通率和连通速度

$常见指标$

1. 连通率：音视频通话双方或者多方同时看到画面或者听到声音的成功率
2. 连通速度：音视频从呼出开始到对端用户出现画面或者声音的时间

$应对策略$

1. 音视频的连通率主要和控制信令有关，减少信令的交互次数以及提高信令的到达率就能达到提高连通率的指标，实时音视频应该尽量减少信令造成的音视频互通问题。比较好的办法为长短连接的方式配合使用，长连接主要解决呼入信令问题，短连接主要解决音视频的功能接入。
2. 连通速度目前主要通过减少信令交互时间、UDP 通道建立时间、编码发送时间来完成，常见方法有信令服务支持 http keepalive 或者 http 2.0、降低起始码率的大小等

音频通话质量

$常见指标$

1. 普通音频通话场景：保证通话声音的清晰度，具体表现为 2000 Hz 以下的声音波形的还原度
2. 高品质音频互动场景：增加对除了人声之外的声音场景支持，提高频率覆盖范围，允许部分啸叫的产生
3. 外围声源的支持：可以在 RTC 中接入非 microphone 之外的声源，提供多种音效的支持

$应对策略$

1. 针对普通通话场景可以引入啸叫抑制和噪音抑制逻辑，抑制分级机制适配不同场景的用户需求，噪音抑制使用 WebRTC 内置引擎，啸叫抑制可以引入陷波器相关算法
2. 高品质音频需要对声音波形有很高的还原度，WebRTC 底层的很多声音处理算法会破坏声音形状，导致在音乐场景下不满足需求，短期内可以通过关闭声音处理功能再配合相关控制信令达到音乐场景使用的目的，长期需要对声音信号做专业化分析，例如引进人工耳和人工嘴，构建近似真实环境的沉浸式噪音场景，通过对端到端延迟指标、回声抑制指标、响度指标等进行测试，对不同场景区分适配不同参数，上层通过参数设置到达不同场景需求的目的。
3. 增加混音 API 的支持，接入层可以通过很简单的方式使用混音功能，增加多种音效互动模式，提升客户体验

视频通话质量

$常见指标$

视频通话质量目前主要为视频画面清晰度，多种分辨率视频支持， simulcast 大小流视频支持，兼容在网络抖动的情况下保障视频画面的流畅性

$应对策略$

目前视频通话的指标主要在画面清晰度和流畅性上，测试标准也比较统一。

1. 清晰度上目前主要在发送增加多种码率视频的发送，接收端根据需求选择不同码率的视频数据。目前主流的 H264 硬编性能都比较强，同时编码两种或多种码率的视频不会造成瓶颈，同时也可以选用 H264-SVC 或者 VP9-SVC 方案，另外数据丢包对清晰度有很大的影响，此时需要权衡流畅性和清晰度，重视清晰度的话流畅性会受影响
2. 流畅性主要从包顺序进行考虑，如果比较重视流畅性的话会允许一部分的包丢失，这个问题可以从使用场景进行区分

SDK 日志埋点

$常见指标$

音视频需要有客观的数据统计平台，能针对每一个音视频频道做到数据可视化，此时需要客户端做日志埋点

$应对策略$

1. 每一个和媒体服务器之间的数据请求都应该做到可视化，分析其中的错误码和错误产生的原因，针对每一种错误都标识出类型（成功也是一种错误码）
2. 针对呼入信令和呼出信令做数据统计，通过大数据分析呼入和呼出的信令成功率
3. 针对音视频统计接通率，将音视频数据是否接收到作为统计标准
4. 定时统计 WebRTC 底层各项参数，例如丢包率、CPU、内存、带宽等各项指标
5. 花屏统计，通过机器学习统计花屏，检测到花屏时上报当前客户端编解码信息以及发送端编解码信息

对外 SDK 的标准化

$常见指标$

1. 定制性较强的 SDK：针对使用比较频繁的场景出具一套定制性的 SDK，包含基本的 UI 组件，方便开发者或者第三方厂商快速集成使用，可以修改部分 UI 逻辑
2. 非定制性的 SDK：包含一些基本的 UI 控件，用户自行搭配使用，可控性比较强
3. 粒度级别较细的 SDK（原子性 SDK）：比较偏向底层的 API 接口，可以满足所有音视频场景需求
4. API 标准化：针对各个端出具一套统一的 API 接口，方便各个不同端的开发者进行对接
5. 音视频特效 API：随着网络的快速发展，基于实时音频和视频上的定制性开发需求特别多，例如音效和视频特效的开发需求
6. 单元测试体系：单元测试目前是软件行业的标准，覆盖全面的单元测试体系能够快速定位问题和提高软件质量

$应对策略$

1. 很多客户需要快速功能接入而不太重视技术细节，可以使用定制性比较强的 SDK，客户微小修改就能直接使用，针对此类需求， API 设计需要尽可能简单易懂、包含详细的开发者文档、快速集成 Demo 以及尽可能少的 API 调用。
2. 非定制性的 SDK 主要提供多种组件，用户根据需求动态调整组件使用逻辑，
3. 粒度级别较细的 SDK 主要提供通讯能力，不对其他业务逻辑有过多涉及，减轻通讯能力层的负担。
4. 针对以上四种 SDK，所有端都需要有一套统一的 API 调用以及详细的开发者文档、快速集成示例 Demo、以及相应的技术支持。
5. 针对音频和视频提供一些特效支持，例如音频混响、变声、均衡器等支持；视频美颜、水印、人像跟踪、物体跟踪、画面特效。人像跟踪和物体跟踪可以通过插件的方式进行支持，使用现成的 M-RCNN 方案
6. 针对客户端和服务端都应该引入单元测试标准，达到覆盖率指标和执行成功率指标，引入 mock 系统等

服务端常见指标和应对策略

由于 Media Server 是音视频的核心，所以音视频很大一部分问题都会集中体现在 Media Server 中

媒体服务器

1. 是否了解项目源码
   作为服务端的音视频技术开发，必须全部了解 WebRTC 协议栈，例如 ICE (STUN/TURN)、RTP、RTCP 以及详细的 GCC、REMP、PLI、FIR 逻辑层。保障客户端的数据传输，将主要精力放在数据传输问题排查上，因为客户端主要接触的首先是业务层的开发，其次才是协议层的开发，所以数据收发问题定位服务端开发人员需要有很深入的了解。

2. 项目文档
   无论是开源媒体服务器还是自行开发的媒体服务器都应该有详细的 API 文档，既方便定位和排查问题，也方便后续维护和开发人员持续开发，文档上可以参考使用用户比较多的开源媒体器的 API 文档

3. 它是否是可调试的
   一款媒体服务器的成功与排查问题和定位问题的速度有很大关系，只有方便排查问题的媒体服务器才能快速成长起来，可以从几个维度来考虑，第一：ICE 连通率相关日志埋点统计，ICE 连接候选以及发包策略统计；第二：音视频 RTP RTCP 数据统计，包含丢包、带宽预估、GOP 缓存计算等数据统计；第三：提供数据查询 API，支持客户端动态获取其上行和下行码率以及丢包等相关信息；第四：和客户端信令交互数据统计，包含统计出成功和失败的数据，通过请求 ID 的方式实时汇报每一次信令交互的结果；第五：媒体服务器之间每次发布和订阅也需要进行标识

4. 是否易于服务横向扩展
   受限于单台服务器的性能瓶颈，所以媒体器需要支持横向扩展

5. 核心业务层开发语言确定
   很多专业的实时音视频类库均使用 C 或者 C++ 语言开发，使用文档也比较多（例如：WebRTC、libnice、libsrtp），所以媒体服务器的核心逻辑层建议使用 C 或者 C++ 进行开发，方便核心能力层快速迭代，以及问题排查

6. 简化信令交互
   客户端和媒体服务器信令交互的次数越多，越容易导致问题的出现，网络请求失败、网络断开、网络切换等都会造成音视频接入的失败。交互信令越少越容易提高音视频的质量

7. 媒体服务器的角色
   媒体服务器的主要角色是保障数据传输、定制性业务逻辑层的功能可以放到客户端来实现，双边互补才能提高音视频的体验

数据可视化

客户端的埋点日志输出、服务端的埋点日志可以汇总到大数据管理平台，目前以下指标需要精确定位出来

1. 信令交互成功率
   由于客户端和服务端都统计请求 ID 对应的结果，所以可以通过请求 ID 标识出每一次音视频信令的结果，在方便定位问题的同时也可以实时统计信令成功率，通过对应 ID 调出对应的日志信息方便客户端排查问题

2. 音视频接通率
   统计客户端每一次的音视频接通率，例如音频接通率和视频接通率

3. 音视频断开统计及数据分析
   针对客户端音视频断开连接时的原因统计，主要分为网络断开、弱网导致的 ICE 断开

4. WebRTC 各项参数统计
   例如丢包率、RTT 延迟、视频编码器、当前发送和接收码率等

5. 客户端崩溃统计
   针对客户端，统计所有异常问题，引入 bugly 或者通过第三方开源项目进行统计。使客户端符号化分析之后排查和定位问题。

6. 开发者技术反馈
   引入开发者技术评价体系，定时分析开发者需求转化为产品需求，优化产品质量和使用便捷性

QA 测试标准化

常规测试

主观测试目前本文涉及不多，对项目本身而言主要还是一些基本流程准确性的测试、问题修复验证测试和服务端业务逻辑测试等，另外对于音频和视频的测试需要引入主观测试流程，提供测试评价标准

客观测试

目前影响音视频质量的因素主要有以下几个

1. 网络方面：丢包、延时、抖动
2. 设备因素：声学设计、设备的计算能力
3. 物理环境因素：密闭环境、噪声、啸叫等

针对上述问题我们需要和竞争对手做数据上的对比，列出对比指标，例如不同使用场景下声学曲线相似性指标、网损相同时丢包率指标、延迟指标、接通率指标等，另外还需要执行符合3GPP，ETSI等通信标准的客观测试

1. 专业设计的消声室：我们需要足够安静且反射路径最小化的声学环境来避免周围的环境音来影响测试。
2. 人工耳和人工嘴：我们需要可重复又高保真的发声和收音装置来覆盖人的正常说话和听力动态范围。
3. 网损设备：为了覆盖更多的真实场景，我们需要网损设备来模拟和控制丢包。
4. 近似真实环境的沉浸式噪音场景：我们需要在人工头的四周布置高保真的音箱来制造噪声声场。

自动化测试

自动化测试目前主要为：

1. 客户端接通率测试
   分为双人接通率测试标准和多人接通率测试标准
2. 服务端压力测试
   服务端压力测试要测试服务端支持的量级，以及容量超过限制时自动扩容或者横向扩容相关的逻辑验证
3. AI 测试
   客户端引入深度学习测试，给出标准的音频和视频信息，通过深度学习的方式验证音视频通话过程中的声音质量度量和视频质量度量