这个公众号会路线图 式的遍历分享音视频技术：音视频基础 → 音视频工具 → 音视频工程示例 → 音视频工业实战。关注一下成本不高，错过干货损失不小

当我们去定义卡顿这个负面的体验时，我们可以先从理想情况出发往较差的方向递推：

然后，我们再从最差的情况回溯，看最不能忍受的体验是什么。怎么认知卡顿对用户的影响，便决定了你该怎么选择指标。

一种推理是：对于视频消费场景，卡顿是一种常见的现象，用户对视频播放会卡是有心理预期的，所以有卡顿发生还能接受；但是用户等待卡顿的耐心不足，所以卡顿时长稍微增加用户就会流失。那么相对于卡顿次数，卡顿时长更是我们需要最重点关注的点。但这里还有一个不可忽略的背景因素，那就是观看时长。用户对卡顿时长的忍耐程度是相对于正常观看时长而言的。

所以相对于卡顿率、平均卡顿时长和百秒卡顿次数，百秒卡顿时长可能是更能反映出用户对卡顿感受的一个指标。因为一次播放中卡顿过 1 次或多次都算是卡顿过了，所以卡顿率不能很好的反应出用户卡顿的次数多不多，卡顿的时间有多久。百秒卡顿次数能反映用户卡顿的次数，但是不太能反映出用户的卡顿时长。

当然，卡顿率、平均卡顿时长和百秒卡顿次数仍然可以作为辅助的指标来关注。

优化播放卡顿大致上可以分为几个大方向：

我们就从这几个方向上来讲解优化措施。

下面是一些码率调控的措施：

虽然有了上面这些码率调控的措施，但是通常我们也不能对用户一刀切，对所有的用户都用同样的码率调控方式。比如，从拉流端来看，对于使用 WIFI 网速稳定且高速的用户，我们可以播放高码率高分辨率的流；对于使用 4G 网速容易抖动的用户，我们可以播放低码率低分辨率的流。从推流端来看，我们可以计算直播间的 ACU（直播间用户总观看时长/直播间总推流时长）来评估直播间的热度及影响力，对于大主播我们可以推码率高一点的流来提升画质体验，对于数据较多而观众分散的小主播我们则可以适当降低推流码率。

参考：

H.265 相对于 H.264 压缩效率更高，在保持一定画质的情况下使用 H.265 替换 H.264 可以降低码率。

软编相对于硬编有更好的灵活性，在有些设备上通过配置合适的编码参数，可以在保持一定画质的前提下比硬编使用更少的码率。

在直播流中，我们会发现有一些视频 AVPacket 的 duration 字段是空值的，但是它实际上是有时长的，如果在缓冲数据时，我们用视频水位线来驱动起播，那就要卡顿等待更长的时间才能起播。比如：我们设置的是应该等待 100ms 的视频数据才开始起播，由于有的视频 AVPacket 的时长是空值，那么累积到 100ms 时长的视频数据时，对应的实际视频时长其实是大于 100ms 的，这就意味着卡顿了比预期更久的时间才起播，这样就会造成百秒卡顿时长被拉高。

对于这种情况，我们发现音频 AVPacket 的 duration 字段值是正常的，所以可以使用音频缓冲区水位线来驱动起播，可以保证起播前的缓冲造成的卡顿时长是更符合预期的。

此外，还需要从直播流链路定位视频 AVPacket 的 duration 字段是空值的原因，解决这个问题后，使用视频缓冲区水位线来驱动起播也是可以的。

当播放器发生卡顿后，先暂停播放流程，停止数据消耗，同时去等待下载线程加载更多的数据到缓冲区后再启动播放，从而降低后续发生卡顿的概率。这里的暂停时长应该是多久，可以通过设计更细致的策略来决定，这里的策略跟我们的目标有关：是减少卡顿次数更重要，还是减少卡顿时长更重要。

这里介绍一种策略：三级缓冲水位策略。

这里的水位对应的是视频缓冲时长或者音频缓冲时长。

比如，三级缓冲水位可以设置为：500ms、1000ms、5000ms。

第一级缓冲水位指的是播放器第一次加载多少视频数据后开始播放。这个值通常设置的比较低，这样可以加快首次播放启动的速度。比如上面设置的是 500ms。

第二级缓冲水位指的是播放器发生一次卡顿后，要加载多少视频数据后开始播放。比如上面设置的是 1000ms。

第三级缓冲水位指的是播放器在发生卡顿后，最多要加载多少视频数据后开始播放。比如上面设置的是 5000ms。

在第二级和第三级缓冲水位之间，可以有一个逐步升级策略。比如：第一次卡顿后，缓冲 1000ms 的视频数据后开始播放；第二次卡顿后，缓冲 2 * 1000ms = 2000ms 的视频数据后开始播放；第三次卡顿后，缓冲 2 * 2000ms = 4000ms 的视频数据后开始播放；第四次卡顿后，缓冲 MIN(2 * 4000ms = 8000ms, 5000ms) = 5000ms 的视频数据后开始播放；以后的卡顿都缓冲 5000ms 的视频数据后再开始播放。

当播放器缓冲区的数据累积的较多时，对应的播放延时会比较大，这时候可以加速播放来加快对缓冲区数据的消耗从而降低延时；反之，当播放器缓冲区剩余的数据较少时，很有可能由于网络原因造成数据下载的速度跟不上数据消耗的速度而发生卡顿，这时候可以低速播放来减慢对缓冲区数据的消耗从而防止卡顿。

下图示例了一种倍速播放策略：

倍速播放策略

短视频的卡顿大部分是由于网络原因导致的，加载本地数据比加载网络数据要更可靠，所以可以从缓存的角度来优化短视频的卡顿。

对于短视频的卡顿，初次播放的视频可以对视频进行预加载来优化视频播放卡顿。

重复播放的视频可以通过实现视频边下边播的缓存能力，并提升缓存命中率来优化。

在实际的数据分析时，我们会发现有时候用户开始卡顿，并且持续了很长时间也未恢复。这种情况可能是由于网络状况较差，虽然数据传输速度很慢，但是连接一直也没有断开，所以不会触发播放器的报错，播放器由于累积不到足够数据，也无法启动播放，所以导致卡顿时长很久。

这种情况，我们可以设置卡顿超时时长，当发现卡顿持续超过一定时长后，就上报事件到业务层，业务可以重新连接，防止卡顿过久。

在主播中，观看端的有一些卡顿是由于主播的行为引起的，比如主播使用手机推流的时候有退后台的操作，这时候推流断流，相当于生产侧的数据断掉了，拉流端没有数据自然会卡顿。对于这种情况，可以支持退后台继续推流，不过有几点需要注意：

现在的运营商纷纷推出无限流量但超过特定值会限速的套餐。这样会造成使用流量套餐的观看视频或直播的用户从月初到月末卡顿概率越来越高，跟卡顿相关的数据指标也就越来越差。

在 CDN 服务端来控制下发视频数据的带宽和速度。比如，在拉取直播流时，服务端将以数倍于平时带宽的速度下发前面缓存的若干时长的数据给客户端，这样播放器在开播时能较快的拉取比较充足的数据，防止开播卡顿。

有的 CDN 厂商在会在拉流的节点缓存直播流的最后一个或多个 GOP，同时会配置这个缓存的有效时长（即在一定时长内没有请求来拉取这段数据，则超时清空这个缓存）。

这样一来，即使推流已经断开，拉流端也会拉到 CDN 缓存的数据开始播放，但是由于这段数据有限，当消费完后，CDN 的返回的 HTTP 状态码就有比较大的影响了。

如果 CDN 返回 404 等报错状态，播放器就会报错，此次播放终止。当然，如果客户端对拉流报错做了重试策略，这样就会不停的重试再去拉同一份缓存数据。这种情况，通常不会影响卡顿，但是会造成播放成功率降低。

如果 CDN 返回 200，那么播放器就不会报错，但是播放器的读数据线程会因为读不到数据进入加载状态而计入卡顿，这种情况就会造成百秒卡顿时长上升了。

[1]

带宽估计: docs.google.com/document/d/…

视频发布优化

视频录制优化

采集预览优化