近几年来短视频领域成为互联网的风口，美拍作为最早的短视频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

创作场景

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