作者｜王辉
编辑｜小智
QQ 空间在 2016 年日均视频播放量由年初的千万级迅速突破到十亿级，过程中也对整个视频播放技术的可靠性、性能、操作体验等方面提出严峻的考验，相关质量急需提升。经过多个迭代持续和各项优化，外网整体质量已经达标：在保证播放成功率提升到 99.92% 的基础上，首次缓冲耗时降到 0.70s，二次缓冲概率降到 0.48%，做到稳中有升。我们将从视频组件的整体架构，优化效果衡量，首次缓冲耗时优化，播放成功率优化，二次缓冲优化，总结六个方面介绍视频点播在整个优化过程中的心路历程。
注：本文整理自腾讯研发总监王辉在 QCon 北京 2017 上的演讲，原题为：《十亿级视频播放技术优化揭秘》。
写在前面
我今天的话题是“十亿级视频播放技术优化揭密”。介绍我们团队在去年短视频风口上，视频播放量从 5000 万到十亿级过程中的一些技术实践，希望我的分享能给大家带来一些借鉴和参考。
自我介绍一下，我叫王辉，来自腾讯，从 2009 年开始从事 QQ 空间技术研发，近期主要关注手机短视频、视频直播、AI 智能硬件。我个人喜欢跑步，觉得跑步是解决程序员亚健康的一个比较好的方式。
众所周知，短视频去年是一个风口，起因是来自 Facebook 2015 年 Q3 的财报，财报表明在 Facebook 平台上每天有 80 亿次短视频播放，给 Facebook 带来了强劲的广告收入，正是这个数据给国内核心大公司和创业公司带来的一些新的突破口。
其实短视频已经不是一个新的概念，从 2006 年开始国内就有很多公司在做短视频。随着 Facebook 吹起短视频风，去年在短视频行业有近百款应用出现，中国网民里面每 5 个里面就有 1 个是短视频的用户，短视频成为互联网的流量入口。
QQ 空间也在这个风口中，从 2015 年 11 月份的每天 5000 万视频播放量，经过一年的耕耘细作，徒增到 2016 年 12 月份的 10 亿量级，现在还在不断增长。
我的分享主要是按照我们产品迭代的几个关键步骤展开：
快速上线
首先看快速上线，在开始之前，我先介绍一下我们的团队职责，我们团队负责手机 QQ 和手机 QQ 空间两个 APP，每个 APP 有 iOS 和 Android 两个团队，一共四个团队，四个团队负责两个 APP。在这个项目中，我们四个团队要针对两个平台实现四套逻辑，这里的效率是存在一定的问题。
关于短视频体验，在这之前，我们也只是做到能播放而已，没有做很精细的工作，并且这里的产品观感体验也不是很一致，也不是很好。
技术上，之前也只是做很基础的架构，直接由播放器连接服务器下载数据，达到能播放就可以。之前我们没有积极去做这个事情，导致播放成功率低、失败原因未知、不支持边下边播、缓冲时间比较长等问题，流量浪费也比较严重。
在产品上要解决的，是在整个 APP 里面把所有产品的体验做到一致，比如说每个功能的观看体验，视频浮层的体验，统一观看体验也为我们项目清除了很多障碍。
而这里的技术上的要点是非常关键的，第一个是边下边播，这是基础的要求，是为了加快视频播放速度。第二个是流量的控制，这么大的平台，之前只是做 5000 万的播放量，如果没有流量控制的云策略，可能到后面流量是无法把控的。第三，刚才讲到团队的现状，团队要负责两个 APP，这里要做代码复用，不可能再像之前一样四个团队维护四套代码，第四，我们支持第三方的视频源。第五，需要完善监控上报，对业务知根知底。
可以看到，完成核心技术要点最核心的一点是如何控制视频的下载，传统的方式是播放器直接塞播放地址给播放器，它就可以直接播放，这其实是一个黑盒。我们在中间加了一个本地代理，播放器与服务器的数据请求，我们完全可以把控。在这个过程中，比如说播放器要数据时，可以给它更多的数据，这样能解决它缓冲的问题。有了这层代理之后，架构也更清晰一点。
基于 MVC 架构，在 MODEL 一层做一些业务的逻辑，在 VideoController 这一层做控制视频的播放和下载。有了下载代理之后，就可以通过代理管理下载，在 APP 里面有很多的视频请求，VideoProxy 可以管理这些请求，做流量控制，做预加载，还可以做优先级调度和做监控上报，下载逻辑层则主要关注怎么优化服务器，对接缓存管理层，同时我们抽象出了一个数据层，我的数据源可以是 HTTPDataSource，也可以读本地，也可以是来来自腾讯视频的数据源，也可以是第三方 APP 的数据源，协议层主要是 HTTP、HTTPS、HTTP2 的解决。
在 VideoController 的逻辑里，其实都可以放到 C 层来实现，这样安卓和 iOS 完全可以通用，这一层的逻辑可以在 QQ 和 QQ 空间两个 APP 里面使用，相当于是我们一套逻辑可以完全复用，不用再开发四套逻辑。
我们团队的职能也做了相应调整，之前可能是按团队划分，四个团队负责四个终端，现在可能是按 FT 的方式划分做视频的团队，iOS 做视频的团队可能负责 QQ 和 QQ 空间里的业务，安卓也是如此。直播的 FT 也可以这样划分，iOS 的负责 iOS 的两个 APP，安卓的负责安卓的两个 APP，这样代码复用更清晰一点，我的团队更专注一点。视频的团队专注视频的研发。
监控上报，肯定是不可缺少的，这是一个成熟的项目必备的要素：
问题定位，老板跟用户反馈说我这个视频播不了，要有一套成熟的问题定位的方式；
耗时统计，用户播放这个视频花多长时间播出来，这也是要了解到的；
成功率统计，外网用户播放视频的成功率是多少？还要通过实时报警，才能及时知道外网发生一些故障。
传统的捞 Log 方式大家都有，但是这种方式效率太低，需要等用户上线之后才能捞到 Log，Log 捞到之后还得花时间去分析。我们做法的是在关键问题上做一些插装，把每一类错误和每一个具体的子错误都能定义出来，这样一看错误码就知道播放错误是由什么原因导致的。
还可以把每次播放视频的链路所有关键流水上报到统计系统里来，每一次播放都是一组流水，每一条流水里面就包含了例如首次缓冲发生的 Seek，或下载的链接是多少，下载的时间是多少，有了这些流水之后，用户反馈播放失败，我首先可以用流水看发生了什么错误？错误在哪一步？每一步信息是什么？几秒钟就可以定位到问题。
有了这个数据上报之后，还可以做一些报表。比如说可以做错误码的报表，有了报表之后就可以跟进哪个错误是在 TOP 的，负责人是谁，原因是什么，都可以看到。
我们也有自己实时的曲线，可以看到各项数据的情况。
在告警方面，基于成功率和失败率的统计播放视频卡顿是什么原因，进行实时告警。一出现错误码，微信立即可以收到提醒，提醒说是什么原因导致这次告警，完全全自动。
成本优化
上线一个月之后，一个坏消息一个好消息。好消息是播放量涨了 4 倍，坏消息是带宽涨了 6 倍，带宽优化是每个做视频的人必须要面临的问题！
我们也分析这个过程中的原因，发现因为改为边下边播之后用户观看视频的意愿比较强，用户有挑选心理，不是每个视频都去看，看了一下之后不喜欢就划走了，之前下载的那部分其实是浪费的。
如果之前不做限速的话，一点开视频就疯狂地下数据，带宽有多大就下多少的数据，这样浪费很严重。我们采取的第一个策略是进行流量控制。在高峰期播放到第 10 秒时，预下载 N 秒数据，下载到 N 秒就停下来。然后，可以做多级限速。一开始不限速，下载到合适时机做 1 倍码率限速。高峰期时预加载的数据会少一些，防止高峰期时带宽占用明显，这是初级的策略。最终我们也有码率切换的策略。这对用户的观看体验影响比较大，这也是之前必备的一个策略。
上线这个策略之后，对带宽的优化还是比较明显的。在高峰期时从 18：00 到凌晨 1 点带宽下降 25.4%，这个是我们不断灰度最终确定的值。这个值会影响播放缓冲，因为数据少的话必定会卡顿，在卡顿之间和流量之间取了一个最优值，最终是 25.4%。
但这样肯定是不够的，因为流量涨的还是很明显的，我们想到 H.265，压缩率相对于 H.264 提升了 30%-50%，但它的复杂度也是呈指数级上升。复杂度导致它的编解码耗时更长，占用资源也更长。如果把 H.265 用在客户端上的话，可能要评估一些点，比如说在编码上面，现在手机上没有做 H.265 硬件支持的，相对于 H.264 的耗时 3-7 倍，之前耗时可能是 10 分钟，而现在可能需要到 70 分钟左右。
解码的硬件支持 H.265 的也很少，耗时差不多是一样的。解码是可行的，你可以采用软解的方式，这个带来的问题是 CPU 占用非常高，可能之前 H.264 占 20% 的 CPU，H.265 占 70%、80% 左右，带来的问题是发热和耗电。
结论，解码是可行的，但是编码不用考虑，在移动客户端不可行的情况下，那编码就要放在后台来做了。
为了解决如何在我们手机上能够解码的问题，对手机的解码能力做一次评估。我在合适的时机做一次大规模的浮点数运算，将数据上传到后台服务器进行云适配。如果当前的指数满足 H.265 条件的话，可以给你下载 H.265 视频给你播放。从而保证软件解码柔性可用，针对视频源规格按机型适配降级，保证用户视频播放体验。
经过评估之后，判断当前机型更适合 360P 还是 480P 等等，保证如果手机不适合 H.265 就不会给你的手机下发 H.265 视频的。
经过我们的统计，外网上有 94% 的手机还是支持 H.265 解码的。支持 1080P 手机的解码占 46%。
编码只能在后台做，如果在视频后台进行全面编码的话，是不现实的。因为编码复杂度呈指数级上升，拿后台服务器进行编码也是不可行的。我们的做法是只用热点视频进行后台转码，不是所有视频都去编码，对观看量在 TOP N 的视频进行编码，只需要编码少量的视频就可以带来流量优化效果，因为 TOP N 就占了全网 80-90% 的流量，只对少量的视频进行解码，让 90% 的视频享受转码的优势。
因为热点转瞬即逝，可能前一分钟是热点，后一分钟就不是热点，社交网络的传播非常快，我们给后台的要求是转码速度一定要快。在之前没有优化时播放视频卡顿是什么原因，转一个 10 分钟的视频要半个小时左右。后来做了分布式处理之后，转 10 分钟的视频只用 2-3 分钟。一些短视频最长 5 分钟左右，只要监测到视频很热的话，1 分钟之内就能转出来，就是 H.265 了。
同样，在 H.265 编码器上做了一些优化，比如编码速度和码率的节省都会有提升。
经过 H.265 尝试之后，带宽进一步下降，节省了 31% 左右。
带宽问题解决之后，面临的下一个问题是体验优化。用户最想要的是视频能立马播出来 。
我们定了一个秒开技术指标，只要这个视频从到我的视野范围，到视频播出来之间的耗时在一秒以内。这也是对标 Facebook 的体验，Facebook 一打开动态，视频是能立即播出来的，不需要等待就能播，这个体验其实很顺畅。
核心的流程主要是三个步骤：
客户端初始化播放器；
下载数据；
等待播放。
这里主要有两个大的耗时点，第一下载视频数据耗时；第二个是客户端的耗时，下载视频数据耗时的话，主要是下载数据量和下载的速度。
这里有一个很直接的问题，播放器需要下载多少数据才能播放？
我们可以看一下 MP4 格式，MP4 其实是一个比较灵活的容器格式，每个东西都是用 Box 表达的，每个 Box 又可以嵌入到另外一个 Box。MP4 主要由 MOOV 和 Mdata 组成，MOOV 是囊括了所有的视频关键信息，肯定是先把 MOOV 下载完之后才能找视频数据才能播起来。不巧的是，在我们外网会发现有 5% 左右用户上传的视频，它的 MOOV 是在尾部的。后来也发现，有很多安卓手机比如说山寨机，一些摄像头处理的厂商可能比较偷懒，因为他们只有在你采集完信息之后才能知道他所有的信息，他可能把所有的信息放在尾部。
对于 iOS 来说，一开始把头部下载了，找不到 MOOV，就猜测 MOOV 在尾部，多一次 Range 请求去探测 MOOV 到底在哪？基本做法是去尾部探测, 如果 MOOV 在其他地方的话，这次播放肯定是失败的。安卓某些手机如果没有经过处理，MOOV 在尾部的情况下需要下载整个视频才能开始播放。
我们的处理方式，用户在后台统一做一次转码修复，客户端采集后做一次转码修复。
看一下 Mdata，视频的原数据。目前大部分是 H.264 编码，H.264 通过帧预测的方式进行视频编码。这里有一个 GOP 概念，也是在直播里面经常谈的。一般的播放器需要下载完整的 GOP 数据才可以播。
需要下载多少数据才能播呢？每个播放器的行为也不一样。iOS 要下载一个完整的 GOP 才可以播。像 FFmpeg Based Player 的话只需要关键帧就可以播出来。安卓是比较尴尬的一个系统，在 6.0 及以下，需要下载 5 秒视频数据才可以播起来。
如果需要下载 5 秒数据才可以播的话，肯定是非常慢的。我们这里的策略会采用 FFmpeg Based Player 自己来做解码，要关注兼容性和耗电的问题。解决了 Mdata 之后，如果 MOOV 数据在头部，拿关键信息进行播放的话，其实需要的开始播放数据量是非常小的。
对于下载优化，会有一个防盗链的请求，通过 HTTP 拿到真实的播放 URL 才可以下载数据。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： muyang-0410
