比心直播的音视频质量建设

比心是面向 Z 世代的电竞社区，有超过 800 万的电竞大神，6000 万的资深玩家，累计与 20 多家顶级战队达成战略合作。最近几年开始快速发展直播业务，目前直播间内容已相当丰富，有舞台模式、多人连麦、互动游戏等趣味玩法，可以明显提升用户粘性。

在这些功能的背后，会用到音视频相关能力，比如舞台模式的炫酷效果需要用到播放器、多人连麦需要 RTC、互动游戏需要把游戏画面合到视频流中。随着这些业务的迭代，比心直播在音视频方面也有了一定的建设，从开始的全部依赖第三方服务快速搭建基础框架，到不断优化体验的同时降低云商成本，再到逐渐切换到自研并开始精细化运营音视频指标。

本文主要围绕体验升级和指标运营两个方面分享比心直播的音视频质量建设。

一、音视频体验升级

体验升级是需要持续打磨且相对长期的过程，我们解决过各种各样的问题，其中三个是比较有挑战的：

1. 1. 游戏录屏的内存限制导致直播中断

2. 2. 连麦卡顿、黑屏的优化

3. 3. 提升音视频服务的稳定性

1.1 游戏录屏的内存限制导致直播中断

iOS 11 中新增了 ReplayKit2，可以对整个手机进行屏幕录制。系统录制是用 Extension 的方式实现，有单独的进程。iOS 系统为了保证系统整体流畅，限制 Extension 只能使用 50M 的内存，超过会被系统杀掉，推流也会因此中断，如下图所示：

超过内存限制的原因是 Extension 中集成了完整的第三方推流 SDK，包含采集、前处理、编码、流控、推流等模块，日常占用在 30~40M，遇到视频帧裁剪、缓存较多等复杂场景内存就容易超限制。

iOS App 主体部分我们称为宿主，Extension 和宿主之间可以进行通信。可以把 Extension 的一部分逻辑移到宿主中处理，只包含必要的模块，大体结构如下：

但实际会更复杂一些，还有一些问题需要解决：

iOS 上的录屏声音有两路：系统声音（其他 App 产生的声音）+ 麦克风，如何合理的采集、混音？

1. 1. 系统声音的来源只有 Extension，PCM 格式是 44100、单声道

2. 2. 麦克风来源可以是 Extension 或者宿主，如果期望是 Extension，需要在唤起录制弹框（系统页面）时主动勾选麦克风选项，否则会导致没录到声音，用户也会因此频繁反馈。另外一种就是在宿主中进行采集，更加可控一些

3. 3. 还有一个需要留意的是麦克风和系统声音的格式可能不一样，比如我们麦克风采集的 PCM 是 48000、双声道，需要将系统声音进行重采样后再混音

Extension 和宿主通信（Unix Domain Socket），原始的视频流数据量太大，如果进行传输？

1. 1. 直接传输原始视频流的话，会直接引起 Extension Crash，只能将其进行编码后传输。音频的数据量相抵较小，另外还需要在宿主中混音，故不需要编码后传输

2. 2. 传输编码后视频引起了一个更加复杂的情况，第三方的推流 SDK 基本都只接受编码前视频帧。有两种思路可以解决：宿主再解码视频帧传给推流 SDK、自研推流器。

3. 3. 我们后续是自研推流器，才最终把内存限制的问题彻底解决。Extension 的内存占用降到了 10M 左右，另外我们通过这套方案把游戏录屏开播的成本降低了 75%，也证明这是非常值得做的事情。

1.2 连麦卡顿、黑屏的优化

观众视角的连麦体验不太好，存在两个问题：

1. 1. 连麦开始、结束时画面出现卡顿

2. 2. 连麦开始后对方主播画面首先是黑屏，然后画面才出现

当时有两种方案可以选择：

方案 A 中：

1. 1. 主播未连麦时，直接 RTMP 推流到流媒体中心，然后观众拉流

2. 2. 主播连麦时，RTMP 推流会中断，使用 RTC SDK 推流到实时音视频，再把两个主播的画面云端合流转推到流媒体中心，然后观众拉流

此方案有些弊端：

1. 1. 连麦前后有 SDK 的切换，RTMP 切换到 RTC，会产生推流中断

2. 2. 我们是通过调用 SDK 的 API 来进行云端混流，不能精准的控制开始合流时机，导致对方画面可能会黑屏

3. 3. 连麦前后的流画面尺寸发生了变化，9:16 变成了 4:3，拉流端会有解码器重置的额外消耗，产生的录制文件也可能有兼容问题

当前为了快速上线连麦业务需求，选择了方案 A。我们再看方案 B：

1. 1. 主播未连麦时，和方案 A 一致

2. 2. 主播连麦时，主播仍然会用 RTC 推流到实时音视频，相对于方案 A，多了合流模块，主播 A 会接收到主播 B 的音频、视频，进行本地混流后再 RTMP 推流到流媒体中心，然后观众拉流

3. 3. 我们再看方案 A 中的弊端，方案 B 中 RTMP 始终没有中断，本地混流可以精准控制开始合流时机，且我们可以让视频尺寸保持不变，4:3 的合流画面居于 9:16 的画布中心，观众端拉流时播放器进行适配，只把合流区域展示出来。

另外还有一些额外收益，我们把云端混流切换到了本地混流，节省了云端混流转码的费用。当然方案 B 中也存在一些弊端，主播连麦时存在两路上行，对网络要求相对较高。还有主播本地合流时性能消耗上会增长。经过我们的测评，这些还在接受范围内，所以逐渐切到了方案 B。

1.3 提升音视频服务稳定性

音视频服务无法避免要使用到第三方云商服务，但是云商服务无法保障 100%的稳定性，当出现问题时，可能会导致我们的核心业务不可用。比如我们遇到过云商在后台调整配置，导致我们主播出现批量闪退，属于非常严重的线上事故。

从音视频整体服务稳定性方面考虑，可以在关键环节做云商互备，并且最好有热切的能力。我们从推流器、RTC 服务、CDN、播放器四个环节横向对比主流云商功能，并衡量性能指标（CPU、内存、RTC 进房耗时等），另外我们对于自定义能力的支持比较看重，比如用到 A 的推流、B 的曲库、C 的美颜，需要自定义音频、视频采集、前处理的能力。经过全面的测评，我们选择了两家云商作为主备。

二、音视频质量指标运营

我们优化了用户的音视频体验，接下来就是如何精益求精，不断提升音视频质量。我们主要关注一下指标：

1. 1. 核心环节的异常率（推流、连麦、拉流）

2. 2. 核心环节的卡顿率

3. 3. 直播间首帧耗时

4. 4. 直播间拉流延迟

2.1 核心指标–失败率

首先我们明确下指标的定义：

1. 1. 推流失败率 = 单位时间内推流失败人数 / 推流人数

2. 2. 连麦失败率 = 单位时间内连麦失败人数 / 连麦人数

3. 3. 拉流失败率 = 单位时间内拉流失败人数 / 拉流人数

关于各环节失败的定义是：

1. 1. 推流失败：数据上行中断，比如连接中断、采集异常

2. 2. 连麦失败：连麦未成功开始或者中途断开

3. 3. 拉流失败：反复拉不到流或者播放中断

需要注意的是核心指标要配置告警，第一时间响应。另外可以把错误码进行分组，判断大概是哪里出问题了。

2.2 核心指标–卡顿率

卡顿率指标的定义和失败率基本一致：

1. 1. 推流卡顿率 = 单位时间内推流卡顿人数 / 推流人数

2. 2. 连麦卡顿率 = 单位时间内连麦卡顿人数 / 连麦人数

3. 3. 拉流卡顿率 = 单位时间内拉流卡顿人数 / 拉流人数

卡顿的详细定义是：

1. 1. 推流卡顿：推流帧率、码率小于一定值，且当前采集无异常

2. 2. 连麦卡顿：连麦上行卡顿+下行卡顿，目前是依赖SDK回调的卡顿事件

3. 3. 拉流卡顿：音频、视频的渲染间隔超过一定阈值

卡顿率是一个整体的指标，还需要一些细化的指标，比如：卡顿耗时均线、卡顿地域分布等。

在排查卡顿原因时，以下指标可以帮助判断哪里出现了问题：

1. 1. 主播侧：推流过程中的帧率、码率走势、CPU、内存等

2. 2. 观众侧：RTT、播放器下载速度、CPU、内存等

目前针对卡顿的优化策略主要是：

1. 1. 减少推流异常，比如采集、编码异常、推流中断等

2. 2. 减少推流网络波动带来的卡顿，比如我们升级推流协议到 SRT，低帧率占比下降了一个数量级

3. 3. 拉流端根据网络情况尽量匹配对应的清晰度

4. 4. 优化 CDN 节点质量

2.3 直播间首帧耗时

关于首帧耗时定义是点击直播间到看到视频画面的时间。目前指标表现还可以， 25.90% 在 400ms 内， 78.06% 在 1000ms 内。

对于首帧耗时的优化策略如下：

1. 1. FLV 拉流首帧耗时正常情况在 400ms，减少 CDN 缓存 GOP 值可以进一步降低，但可能会加剧卡顿，需要进行平衡

2. 2. 升级拉流协议，比如 WebRTC 拉流，成本会增加，而且在使用多家 CDN 时存在兼容问题，我们和友商合作过播放器 Proxy 的模式进行兼容

3. 3. 播放器池+预加载，同时存在 N 个播放器，在直播推荐页面和直播间上下滑的场景预加载，指标提升有限但体验比较好，基本不会看到 loading 过程

4. 4. 其他方面：减少进房并发请求，分批次加载直播间内容，延后高性能消耗操作

2.4 直播间拉流延迟

常见的延迟测试是主播画面显示时间，和拉流端进行对比，但无法测量群体均值 。我们在主播端发送的 SEI 中添加时间戳，观众端解析后对比计算差值上报（更精准的可以进行 NTP 校准，消除设备时间误差）。

针对延迟优化方式主要是使用自建推流器，支持使用 SRT 协议推流，和 RTMP 对比下降了 26.5%。其中主要是减少推流端的耗时，比如下图是主播开始推流到建联成功的耗时对比，SRT 在 400ms 内的占比 83.96%，而 RTMP 建联耗时在 400ms 内的只有 51.17%

三、未来的方向

经过我们的不断建设，比心直播在音视频领域已经补齐了短板，优化了各种体验问题。同时我们在一些关键环节自研，在成本控制和性能指标优化方面取得了一定的成果，比如节省了大部分的云端混流成本和降低推流建联耗时等。

在未来，我们会持续优化卡顿率、首帧耗时、拉流延迟等音视频质量指标，比如连麦卡顿问题，会从主播上行入手，减少非必要的音视频上行，降低自己带宽压力的同时减少其他人的下行卡顿。并且要在高并发的直播间场景经受住考验，为用户提供更好的体验。

同时，我们将积极积累音视频领域技术，不断探索新技术，并尝试在业务中落地，以满足用户对音视频内容日益增长的需求。