美拍短视频成本减半及毫秒起播优化实践

近几年来短视频领域成为互联网的风口，美拍作为最早的短视频 APP，从 2014 年开始就对短视频技术有持续地投入和研究。

本文将从成本优化，成功率优化，播放体验优化等几个方面，整体介绍下美拍短视频成本减半以及毫秒起播优化实践之路。

内容概要

近几年来短视频领域成为互联网的风口，美拍作为最早的短视频 APP，从 2014 年开始就对短视频技术有持续地投入和研究。4 年多来，随着 4G 网络的发展以及普通家庭宽带有跨越式地发展，人们对互联网信息的获取从简单的文本过渡到内容生动丰富的流媒体内容，极大的促进了流媒体视频技术的发展，同时也给用户体验提出更高的要求。

本文将从成本优化，成功率优化，播放体验优化等几个方面，整体介绍下美拍短视频成本减半以及毫秒起播优化实践之路。除了这些基础的用户体验改造方面的落地，我们还在持续推进更加极致的用户体验优化。

技术背景

从痛点出发

在早期，快速落地阶段，我们的关注点更加侧重产品的需求和用户增长，以快速满足用户需求为主作为我们的产品主要发展目标，这也是互联网产品基本的发展规律。在早前快速落地阶段，短视频播放的情况是：

• 观看体验不佳，每个视频在加载前都会有一个比较烦人的 1-3 秒的转菊花的过程，即使视频很快起播，菊花也是一闪而过。部分视频还会出现必须要全部下载完之后才能开始播放的情况；

• 起播速度慢，短视频的长度一般在十几秒到几分钟之内，起播速度的快慢直接影响了用户持续观看的意愿。如上所提到的，在没有做特殊优化的情况下，正常起播时间需要 1-3 秒以上；

• 下载成本高，CDN 带宽成本是所有视频类服务最大的一笔费用支出，同时也是用户比较关注的敏感问题。如何最大限度的降低带宽成本，对企业和用户体验而言都是双赢的。

数据驱动

基于上述情况，我们在成本和体验等方面做了相应的改造，我们的核心评估标准是数据，必须坚持以数据驱动来推动整体优化工作。优化类的工作，我们的挑战在于必须做的比原来更好，并且不能因为优化工作给业务带来可用性方面的风险。因此，构建一套客观公正的数据体系是我们最重要的工作前提，数据决定方向，用数据来做调度调整决策。

我们的数据体系不是以产品化为目标，总体的建设目标包括：

• 准确性，数据必须要准确，数据不准确，一切都没有意义；

• 快速落地，在人力有限的情况下，必须要保证足够快速的落地性；

• 可复制体系，我们不追求完美的产品体验，标准化的处理流程可以保证让我们可构建不同维度类型的数据。

有了客观公正的数据，我们可以利用它来做：

• 优化效果评估，用数据来评估优化效果是最为直接的，特别是几十到几百毫秒的差别依赖人工的判断通常是比较无感的；

• 实时故障报警，出现故障时，第一时间报警，第一时间处理干预；

• 质量反馈决策，通过质量我们可以对各种服务提供商的质量有更好评估，作出及时调整；

• 用户问题排查，用户反馈的问题如果没有日志等信息，我们无法分析判断问题。利用一些关键的信息，可以让我们更好的排查和处理用户问题。

融合调度系统

基于我们对线上问题的核心痛点的分析，结合我们所要做的一些调度策略，我们构建了一套点播融合调度系统。我们希望通过这套系统的建设，可以更好的与业务松耦合的结合，通过调度服务，提供更加灵活的策略支持，利用质量系统给整体的调度提供可靠的数据支撑。融合调度系统的主要模块和功能包括：

• 调度服务，提供多 CDN 容灾和多码率等调度分发机制，同时以后还可以加入更多的策略支持；

• 质量系统，利用客户端上报的数据，实时处理分析，给调度服务提供自动调度切换决策；

• 云处理系统，利用热门文件分析，对热门视频做多码率文件处理，提供分发 H265，不同分辨率文件等支持。

[图一：点播融合调度总体架构图]

成本优化

成本优化，最直接体现在降低 CDN 成本，同时也可以降低用户观看视频时的数据流量，对平台和用户而言是双赢的。

降低带宽的手段，最简单粗暴的手段是通过压缩降低热门视频的码率。通过码率的压缩，在降低带宽的同时，也会降低视频的画质，对用户体验以及平台的声誉均会带来较大的负面影响。

我们希望在画质不变的情况下，降低 CDN 成本。为此我们做了一个前提假设：用户有很大的概率是没有完全播放视频就退出播放，同时如果在出现二次播放的时候，我们希望能够让用户直接通过本地缓存可以直接播放，避免多次下载所带来的带宽浪费。

要实现限制带宽目标，也有多种不同的手段包括：

• 利用码率信息，通过限制用户的下载速度，尽量保持让用户以视频匹配的码率下载文件。这种特性一般的 CDN 都会提供支持，好处是改造简单。可能带来的问题就是在部分场景下可能会带来卡顿，忍受网速波动方面会比较有限。需要保持长 HTTP 连接，对服务端，请求错误率监控，客户端耗电等方面都会带来一些影响。

• 通过控制播放器的缓冲区长度，降低用户无谓的内容下载。比如一个视频长度是 60 秒，正常情况下播放到 10 秒的时候，如果没有限制，可能整个视频都会已经下载完成，如果用户此时退出，就浪费了后面 50 秒的下载带宽。通过缓冲区长度控制，我们可以降低中断播放所带来的带宽浪费，平衡每次下载的时间开销，合理评估缓冲的长度。

[图二：基于分片下载和播放器缓冲区控制的下载方案]

通过这个改造，我们取得了超出预期的效果，基本上能够做到在画质不变的情况下，整体的带宽成本下降 50%以上。

在此基础上，还可以通过分发编码效率更高的多码率文件，比如 H265(未来包括 AV1)，来降低视频码率。多码率文件，依靠我们视频调度服务来做策略分发。依赖于客户端请求调度的决策信息，包括：客户端设备信息，分辨率，网络速度，是否支持 H265 等判断调整来整体上做调度决策。

[图三：融合调度多码率策略总体流程]

成功率提升

对成功率提升，我们需要把握一些主要的关键点：

• 重试是关键，公网请求一定会受到各种情况下的波动影响。对于公网的用户请求，短超时，有重试是提高成功率的基础；

• 规避单点服务问题，CDN 业务每天都会有一些区域性的波动，在业务上，尽量需要有容灾服务备用方案，降低因为单点问题带来的区域性和波动性影响；

• 各种技术手段，降低客户端网络请求的错误率。

在提高成功率方面，我们做了一些事情：

• 通过融合调度，下发多 CDN，在每个地区至少同时提供两家以上的 CDN 服务，在其中一家出现问题后，可以快速切换到另外一家 CDN。确保客户端在非本地网络问题的情况下可以播放成功；

• 通过减少网络请求，降低网络错误概率；

• 接入 FastDNS，提高解析成功率，降低解析延迟。总体上可以降低 60-100ms 的网络请求延迟，降低了 40%的网络请求失败率。

通过这些技术改造，提高服务的整体抗波动性，区域性故障甚至是全局性的 CDN 故障能力，将总体的播放错误率从 1%，降低到 0.1%。同时也降低了网络的请求延迟，主动提高了请求成功率。

[图四：融合调度多 CDN 请求流程]

播放体验优化

播放体验优化的核心目标是加快起播速度，降低卡顿发生。为此，我们做了一些针对性的技术改造，总体上也取得了比较不错的效果。

faststart

目前主流的流媒体格式基本上都是 MP4 格式，MP4 文件的格式封装是以 box 为基础，整个文件的封装格式是有不同类型的 box 一级一级嵌套组成。其中，每个 MP4 文件必须要有的区段有：

• FTYP，mp4 文件的基础元数据，包括版本号，兼容特性等信息；

• MOOV，包含了流媒体信息的关键基础信息，包括编码信息，时长等等；

• MDAT，真正的音视频流媒体数据。

如果没有特殊的调整，MOOV 一般会放在视频文件的最后部分，在播放视频时可能会需要完整下载视频后才能开始播放，这样就会很大程度上影响到起播时间。将 MOOV 调整到文件的前部分，可以让播放器最快拿到起播的元数据信息。

[图五：moov 调整]

播放器调整

因为我们所使用的 ijkplayer 机制关系，在检测是否可以开始起播，是有一个定时的检测机制去做数据是否满足播放标准检查。这个时间阈值之前是每 500ms 检测一次，这样极大可能就会浪费 500ms 的时间重新检测数据是否满足播放要求。

在 ijkplayer 0.8.1 引入 FAST_BUFFERING_CHECK_PER_MILLISECONDS 配置，将首次的检查间隔缩短到 50ms，从数据表现上可以降低 300ms 的起播时间。

预批量调度

引入融合调度，提高策略的灵活性，提高服务的整体容灾能力的同时引入了另外一个问题就是下载视频前需要做一次额外的调度请求，会增加大概 300ms 左右的时间，这个是非常敏感的一个体验下降。

预批量调度是利用业务刷新 feed 列表到开始播放视频的时间差，最大限度的做视频批量调度，将批量调度结果缓存到本地，使用户在播放视频的时候直接就可以开始播放。由此就可以解决实时调度所带来的额外请求问题，同时也可以通过批量调度，合并调度请求，降低调度请求数量。

预批量调度适用于任何的业务场景，不受业务场景限制。在引入预批量调度后，几乎可以抹平因为融合调度所带来的 300ms 的起播时间增加，当然因为部分场景下可能还来不及做预批量调度还是会有一点点影响，不过影响面基本可以接受。

预加载

对于提高起播时间来说，预加载是最后的杀手锏。前面的优化都是在利用一切可能的技术手段，降低请求延迟。受限于网络请求本身就会有优化的天花板，能够达到最快起播速度的做法就是播放时不要去做网络请求。在此思路下，我们也逐步引入了预加载策略，也是整个优化手段中的最后一环。

预加载，首先需要分析适用场景，预加载实际，成本开销评估等方面。从场景分析来看，单列 feed 的直接播放场景是最为合适的预加载场景，双列 feed 也是可以做，只是加载缓存的使用命中率上可能会偏低，浪费部分带宽成本。

[图六：预加载场景]

对于预加载需要加载字节数，上图公司已经给出。 600 bytes 是怎么评估的？因为 MOOV 的长度是每个视频都不固定的，而且会跟视频的内容长度有直接关系。我们做了一个简单的调研评估，MOOV 大体的每秒字节数如下：

[图七：MOOV 每秒字节数]

由此大概推测一个相对比较折中的数字 600 bytes。

总体来看，预加载策略的引入，是我们做到极致用户体验非常关键一环。通过这个环节的优化，我们将 50% 左右的播放起播时间降低到 0-250ms 的分布区间之内，数据改善极为明显。

总结

为了控制篇幅，每个优化点都不可能介绍的太细，而且细节点有点多，非常适合做一个总体的小结，每个优化环节的数据都能够体现它的重要性：

通过下载优化，CDN 带宽成本在视频画质没有明显变化的前提下下降 50%；

减少一次 range 0-1 的请求，减少 100-200ms 左右；

FastDNS 接入，减少 60-100ms 左右；

融合调度请求，增加 300ms 左右。播放错误率从 1% 左右下降到 0.1% 左右；

播放器参数调整，减少 300ms 左右；

批量预调度，减少 200-300ms 左右；

预加载，45%视频在 250ms 之内，85%视频在 750ms 之内开始播放。

当前我们也根据我们业务的发展情况，持续在做一些更深层次的优化。也希望能够在画质优化、窄带高清等新兴技术方面有更多的尝试和发展。

本文转载自美图技术公众号。

原文链接：https://mp.weixin.qq.com/s/w7oA-R9FV4WkS7aAla07VA