聊聊直播移动端播放体验优化

“直播”

2020年的一场疫情将直播行业及音视频技术带到了大家的视野中，原本只在娱乐行业被人熟知的直播，在数月中就充斥了人们的整个日常生活。直播卖货、远程会议系统、直播教育原本小众的场景被强行拉上舞台，接受本不该承受的QPS。

部分数据可参考下图：

如果你是一名开发者，你有没有想过，从主播开始推流到用户看到画面，这里面都发生了些什么？一次次的卡顿缓冲时怎么引起的？观众看到的画面和主播实时画面差了几秒，最短能缩减到多少？不同观众看到的画面是否一致？

为了大家可以直观理解本文剩余部分，这里笔者先把直播整体的流程图放出来。

上图只是将主要的流程列出来，真正的流程比这个当然要更复杂。

本文的主题是直播移动端播放体验优化，结合上图，笔者会从推流端、cdn和拉流端给大家介绍如何在这三个环节进行播放体验优化。

本文会尽量写的通俗易懂，不会涉及到具体代码实现，即使你不是直播行业的开发者，读完这篇文章，也能对直播优化有个比较全面的了解。

“推流端”

推流端是离我们观众最远的节点，也是整个直播内容的生产源头。我们熟知的推流工具有 OBS、B 站直播姬和各个直播平台的手机推流 app。另外针对一些复杂场景的话，有更专业的导播台硬件。虽然工具众多，但推流端的整个工作流程还是比较固定的：

1. 摄像头采集
2. 麦克风采集
3. 视频编码
4. 音频编码
5. 音视频封装合流
6. 推流

那么回到文章主题，在推流端我们可以做哪些针对用户播放体验的优化呢？用户体验的话无非三块画面首帧、卡顿率和延迟。

那么想想推流端的哪些行为会导致上面的这些问题？

想象下，如果主播拿了一部四年前的低端手机一边玩和平精英一边直播会怎样？是不是手机本身就已经卡得不得了了？那这里就得出了第一个优化点硬件

硬件的规格参数是会直接影响推流质量，把推流比作一个武林高手的话，硬件就是这位武林高手强健的体魄，没有强健的体魄很难练出绝世的武功。

除了硬件，网络也是一个很关键的因素，如果主播上行网络带宽低、不稳定那么用户端看到的画面质量肯定是非常糟糕的。

其中带宽低我们可以采用低分辨率、低码率或高性能的编码如h265、AAC等手段降低流的码率。

网络不稳定是一个比较头疼因素，因为你不知道什么时候网络会突然抖一下，或者用户是户外直播，那么移动网络的稳定性肯定是得不到保证的。大家知道推流的常用协议 RTMP 是基于 TCP 的，TCP 提供了面向连接的可靠的字节流服务。同时 TCP 又是一个老好人，不仅会帮你校验数据有没有无差错、不重复和不丢失的传输到对方，还会帮你做流量控制和拥塞控制（可参考https://blog.csdn.net/dangzhangjing97/article/details/81008836）。这就导致在一条数据链路上 TCP 的传输可能会抢不过基于 UDP 服务的传输协议。
所以面对不稳定的网络，我们可以采用基于 UDP 且相对比较极端自私的协议，如SRT、QUIC等。这里不展开讲，感兴趣的可以去了解和学习下这两种协议。

总结下推流端的优化手段：

1. 提高推流硬件设备规格参数。
2. 保证推流码率小于网络上行带宽。
3. 针对不稳定网络，可以采用 SRT、QUIC 等协议进行优化。

“CDN”

作为中间商的 CDN，在整个直播链路中也是扮演者非常重要的角色，往往直播的成本大头都在 CDN 带宽上。市面上一个比较靠前的直播平台，在 CDN 成本上每年的花费是超过 1 亿的。扯远了，扯远了。言归正传，CDN 与推流端连接，用于接收主播推上来的流数据，上一节讲了，推流协议可以采用 RTMP，也可以采用 SRT 或 QUIC，那么 CDN 就必须提供同样协议的推流地址，否则推流端一厢情愿使用 SRT 也是不可行的。

CDN 除了要提供多样的推流协议外，另一个比较重要的因素就是边缘节点的覆盖，一般 CDN 在中国的各大城市都有分布，分布的越多，其节点对应推流端的数据链路就越通畅。很多 CDN 厂商都会配置多级边缘节点，其目的就是保证数据能更顺畅的到达流程图中的源站。

在 CDN 保证数据链路通畅的情况下，还有哪些事可以做呢？

可以看下直播流程图中的源站，他的职责中有一项是转码。那为什么要转码呢？主播推上来的流就不能直接给下游去用吗？当然可以不转码，直接给下游消费。但想象下，如果一个主播硬件配置极高，上行网络极好，他推了一个 20M 的流上来，源站不处理直接给观众看的话会发生什么？20M 的流用户需要稳定播放的话，需要其网速可以稳定满足 2.5M/s，这个对于目前很多用户来说是不太现实的。

所以源站这里需要对源流进行转码，将高码率的流转为更低码率的流，如蓝光（8M）、高清（4M）、清晰（1.5M）等。这样用户可以针对自己的网络有更多的选择。

另外源站在转码的时候还能根据流内容做合理的编码控制：CBR 和 VBR。

总结下 CDN 在优化播放体验上可以做哪些事：

1. 提供完善的推流协议 RTMP、SRT 和 QUIC 等。
2. 提高 CDN 节点覆盖量。
3. 通过转码提供多码率的流供用户选择。
4. 采用合理的编码控制：CBR 和 VBR。

“拉流端”

拉流端作为整个直播链路的末端消费侧，对流质量的好坏是最直观的。从流程图上可以看到拉流端做的事情是推流端的逆向，那么对推流端适用的优化手段对拉流端也是适用的。

1. 提高拉流硬件设备规格参数。
2. 保证拉流码率小于网络上行带宽。
3. 保证拉流网络的稳定性。

其中 1 提高硬件规格参数是为了提高软硬解性能效率。2 可以适用较低适用于自己网络的清晰度观看直播。3 则是保证自己网络的稳定性。
满足以上三点大概率用户侧的流畅观看就能得到保证了。

“进阶”

延迟

作为直播，其实时性也是非常重要的，不能说用户观看很流畅，但用户与主播端有几十秒的延迟，那是完全无法接受的。那如何才能做到用户和主播间的延迟尽量缩小呢？引起延迟主要的原因在哪里？下面列举下产生网络延迟的几个原因：

1. 数据链路延迟
   数据从主播端传递到观看端，中间是会经过很多个网络节点的。假设我们所在位置的地球的另一侧有一位主播开始推流，一路都是光纤传输，那么不考虑 CDN 节点内部转发或转码好时的话，我们 2s（TCP 的三次握手导致） 后就能看到画面。但实际情况下，主播离我们及时很近，在数据链路传播上我们可优化空间很少。

2. 网络抖动
   这里的抖动是指 ip 数据包到达的顺序、间隔和出发时不一样，这就导致了接收端需要等待完整数据重组，就不可避免造成了延迟。

3. 网络丢包
   和网络抖动类似，基于 TCP 的推流协议，虽然可靠性得到了保证，到这可靠性是靠牺牲时间保证的，TCP 的三次握手，相当于 1.5 个 RTT。另外 TCP 的自动重传机制在丢包的情况下回不断重发，这种高容错的机制也导致了一定的网络耗时。

4. CDN 缓冲策略
   播放器在向 CDN 拉取数据时，CDN 并不会把最新的数据吐给播放器，而是会选择将缓冲区中的数据给到播放器（这么做是为了减少网络抖动引起客户端的卡顿），此时，缓冲区中有多少数据，那么就有多少的延迟增加了。

5. 播放器缓冲
   播放器在拉到 CDN 数据时，也不是会立马就播放（为了减少网络抖动带来的卡顿），那么此时播放器的缓冲也增加了延迟。

综合上诉，
直播延迟 = RTT * 1.5 + CDN 缓冲 + 播放器起播缓冲

各家直播平台都有自己针对延迟的优化措施，这里不一一列举。

首帧

首帧即用户点击直播间，到看到直播首帧画面的耗时，这个时间也是用于衡量用户体验的一个重要指标。目前市面上优秀的直播平台，首帧时间已经优化到一秒内，做到了真正的秒开。

首帧耗时长也是有许多原因在里面：主线程阻塞，其他业务抢占播放器资源，频流码率高，播放器起播缓存，流格式探测等。

首帧优化当然就是针对上面这些问题的优化，具体不细说，各家有各家自己的策略，一切还是要放到实际业务场景考虑。

卡顿

卡顿即缓冲，这是最最影响用户体验的点。造成卡顿的原因也是多种多样，整个直播链路中任何一个点出现问题都有可能造成卡顿，卡顿也是比较难优化的一个直播指标。
这里笔者主要给出几个优化卡顿的建议：

1. 推流端合理选择推流码率
2. 推流端合理选择推流协议
3. CDN 提供多路清晰度供用户选择
4. 拉流端应选择码率合适的流去播

音画不同步

音画不同步即听到的声音与画面不一致，导致音画不同步的原因也有很多：

1. 音频源于采集设备距离较远
2. 音视频 pts 非单调递增
3. 播放器性能问题（音频帧解码快于视频帧解码）

总结

差不多就是这么多了，过多的实现细节不赘述，感兴趣的同学可以自行学习或找我交流。