十亿级视频播放技术优化揭密

导语：QCon是由InfoQ主办的全球顶级技术盛会，每一年在伦敦、北京、东京、纽约、圣保罗、上海、旧金山召开。自 2007年 3月份首次举办以来，已经有超万名高级技术人员参加过QCon大会。QCon内容源于实践并面向社区，演讲嘉宾依据热点话题，面向 5年以上工做经验的技术团队负责人、架构师、工程总监、高级开发人员分享技术创新和最佳实践。

4月18日性能优化面面观专题会议上，腾讯研发总监王辉以“十亿级视频播放技术优化揭秘”为主题，用QQ空间的日均播放量一年内从千万级突破到十亿级所面临的严峻考验为切入点，为你们分享视频团队在视频组件的总体架构、优化效果衡量、带宽优化、秒开优化、缓冲优化、成功率优化等六个方面的技术实践。

王辉：你们早上好！我叫王辉，来自腾讯，从2009年开始从事QQ空间技术研发，近期主要关注手机短视频、视频直播、AI智能硬件。很高兴能在QCon上与你们一块儿分享和交流。我今天的话题是“十亿级视频播放技术优化揭密”。主要介绍咱们团队在去年一年短视频风口上，咱们的视频播放量从5000万到十亿级过程当中的一些技术实践，但愿个人介绍能给你们作一些借鉴和参考。

众所周知，短视频去年是一个风口，原由是来自Facebook 2015年Q3的财报，财报代表在Facebook平台上天天有80亿次短视频播放，给Facebook带来了强劲的广告收入，正是这个数据给国内核心大公司和创业公司带来的一些新的突破口。其实短视频已经不是一个新的概念，从2006年开始国内就有不少公司在作短视频。随着Facebook吹起短视频风，去年在短视频行业有近百款应用出现，中国网民里面每5个里面就有1个是短视频的用户，短视频成为互联网的流量入口。QQ空间也在这个风口中，从2015年11月份的天天5000万视频播放量，通过一年的耕耘细做，徒增到2016年12月份的10亿量级，如今还在不断增加。

个人演讲主要是按照咱们产品迭代的几个关键步骤展开：

首先是快速上线，2015年我也是跟随着你们的体验快速上线了新短视频的体验；

其次面临的是成本问题，在作的过程当中作了一些成本的优化工做；

而后是体验优化。在解决成本问题以后，短视频的观看体验要作到极致。好比说视频的秒开、不产生缓冲、不卡、成功率的提高。

快速上线

在开始以前，我先介绍一下咱们的团队职责，咱们团队负责手机QQ和手机QQ空间两个APP，每一个APP有iOS和Android两个团队，一共四个团队，四个团队负责两个APP。在这个项目中，咱们四个团队要针对两个平台实现四套逻辑，这里的效率是存在必定的问题。

关于短视频体验，在这以前，咱们也只是作到能播放而已，没有作很精细的工做，而且这里的产品观感体验也不是很一致，也不是很好。

技术上，以前也只是作很基础的架构，直接由播放器链接服务器下载数据，达到能播放就能够。以前咱们没有积极去作这个事情，致使播放成功率低、失败缘由未知、不支持边下边播、缓冲时间比较长等问题，流量浪费也比较严重。在产品上要解决的，是在整个APP里面把全部产品的体验作到一致，好比说每一个功能的观看体验，视频浮层的体验，统一观看体验也为咱们项目清除了不少障碍。

而这里的技术上的要点是很是关键的，第一个是边下边播，这是基础的要求，是为了加快视频播放速度。第二个是流量的控制，这么大的平台，以前只是作5000万的播放量，若是没有流量控制的云策略，可能到后面流量是没法把控的。第三，刚才讲到团队的现状，团队要负责两个APP，这里要作代码复用，不可能再像以前同样四个团队维护四套代码，第四，咱们支持第三方的视频源。第五，须要完善监控上报，对业务知根知底。

能够看到，完成核心技术要点最核心的一点是如何控制视频的下载，传统的方式是播放器直接塞播放地址给播放器，它就能够直接播放，这实际上是一个黑盒。咱们在中间加了一个本地代理，播放器与服务器的数据请求，咱们彻底能够把控。在这个过程当中，好比说播放器要数据时，能够给它更多的数据，这样能解决它缓冲的问题。有了这层代理以后，架构也更清晰一点。

基于这样的架构，在MODEL一层作一些业务的逻辑，在VideoController这一层作控制视频的播放和下载。有了下载代理以后，就能够经过代理管理下载，在APP里面有不少的视频请求，VideoProxy能够管理这些请求，作流量控制，作预加载，还能够作优先级调度和作监控上报，下载逻辑层则主要关注怎么优化服务器，对接缓存管理层，同时咱们抽象出了一个数据层，个人数据源能够是HTTPDataSource，也能够读本地，也能够是来来自腾讯视频的数据源，也能够是第三方APP的数据源，协议层主要是HTTP、HTTPS、HTTP2的解决。

在VideoController的逻辑里，其实均可以放到C层来实现，这样安卓和iOS彻底能够通用，这一层的逻辑能够在QQ和QQ空间两个APP里面使用，至关因而咱们一套逻辑能够彻底复用，不用再开发四套逻辑，咱们团队的职能也作了相应调整，以前多是按团队划分，四个团队负责四个终端，如今多是按FT的方式划分作视频的团队，iOS作视频的团队可能负责QQ和QQ空间里的业务，安卓也是如此。直播的FT也能够这样划分，iOS的负责iOS的两个APP，安卓的负责安卓的两个APP，这样代码复用更清晰一点，个人团队更专一一点。视频的团队专一视频的研发。

监控上报，确定是不可缺乏的，这是一个成熟的项目必备的要素。

1. 问题定位，老板跟用户反馈说我这个视频播不了，要有一套成熟的问题定位的方式；

2. 耗时统计，用户播放这个视频花多长时间播出来，这也是要了解到的；

3. 成功率统计，外网用户播放视频的成功率是多少？还要经过实时报警，才能及时知道外网发生一些故障。

传统的捞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视频给你播放。从而保证软件解码柔性可用，针对视频源规格按机型适配降级，保证用户视频播放体验。

通过咱们的统计，外网上有94%的手机仍是支持H.265解码的。支持1080P手机的解码占46%.

编码只能在后台作，若是在视频后台进行全面编码的话，是不现实的。由于编码复杂度呈指数级上升，拿后台服务器进行编码也是不可行的。咱们的作法是只用热点视频进行后台转码，不是全部视频都去编码，对观看量在TOP N的视频进行编码，只须要编码少许的视频就能够带来流量优化效果，由于TOP N就占了全网80-90%的流量。

由于热点视频的热点转化很快，可能前几分钟是热点，后几分钟就不是热点，由于社交网络的传播很是快。咱们给后台的要求是转码速度必定要快，在以前没有优化时，转一个10分钟的视频要半个小时左右。后来咱们作了分布式处理以后，转10分钟的视频只用两三分钟。一些短视频最长5分钟左右，只要监测到这个视频很热的话，1分钟以内就能转出来，就是H.265了。

一样，在H.265编码器上作了一些优化，好比说编码速度和码率的都会有提高。

上线H.265优化以后，咱们的带宽进一步降低，节省了31%左右。

秒开优化

带宽问题解决以后，面临的下一个问题是体验优化。用户最想要的是视频能立马播出来。咱们定了一个秒开技术指标，只要这个视频从到个人视野范围，到视频播出来之间的耗时在一秒之内。这也是对标Facebook的体验，Facebook一打开动态，视频是能当即播出来的，不须要等待就能播，这个体验其实很顺畅。核心的流程主要是三个步骤：一、客户端的耗时；二、下载数据；三、等待播放。

这里主要有两个大的耗时点，第一下载视频数据耗时；第二个是客户端的耗时，下载视频数据耗时的话，主要是下载数据量和下载的速度。

这里有一个很直接的问题，播放器须要下载多少数据才能播放？咱们能够看一下MP4，MP4实际上是一个比较灵活的容器格式，每一个东西都是用Box表达的，每一个Box又能够嵌入到另一个Box。MP4主要由MOOV和Mdata组成，MOOV是囊括了全部的视频关键信息，确定是先把MOOV下载完以后才能找视频数据才能播起来。不巧的是，在咱们外网会发现有5%左右用户上传的视频，它的MOOV是在尾部的。后来也发现，有不少安卓手机好比说山寨机，一些摄像头处理的厂商可能比较偷懒，由于他们只有在你采集完信息以后才能知道他全部的信息，他可能把全部的信息放在尾部。对于MP4来讲，一开始把头部下载了，下载头部时可能找不到这个MOOV，就猜想这个MOOV在尾部，我可能就有一次请求去探测这个头部到底在哪？这个探测的话基本作法是去尾部探测。若是MOOV在其余地方的话，此次播放确定是失败的。如今主流的系统都是去尾部进行一次探测。

好比安卓某些手机是没法自定义Range，那就须要下载完整个文件才能播放。咱们的处理方式，用户在后台作一次转码修复，客户端采集后作一次转码修复。

再看一下Mdata，这是视频的原数据。目前大部分是H.264编码，H.264经过真预测的方式来进行视频编码，这里有一个GOP概念，也是在直播里面常常谈的。通常的视频须要下载歌完整的GOP数据才能够播，能够看到在这个里面须要下载多少数据才能播呢？每一个播放器的行为也不同。你们能够看到iOS要下载一个完整的GOP才能够播。像FFmpegBasedPlayer的话我可能只须要关键帧就能够播出来。安卓是比较尴尬的一个系统，在6.0级如下，可能须要5秒视频数据才能够播起来。若是说是须要下载5秒数据才能够播起来的话，那确定是很是慢的。咱们这里的一个策略会采用FFmpegBasedPlayer本身来作解码，这里要关注功能性和耗电的问题。

解决了Mdata以后，你会发现若是个人数据在头部，拿关键信息进行播放的话，其实我播放的数据量很是小的。

对于下载优化的话，会有一个防盗链的请求，经过HTTP拿到真实的才能够下载数据。在手机上执行HTTP请求是很是耗时的，这里咱们走私有长链接通道作这个事情。

关于优化下载链路，这里也是谈的比较多的，通常也是直接输出IP地址，利用IP地址作跑马的策略，兼顾性能的效率，这个是用的比较多的方式。

进一步思考，按照广泛600K码率的话，咱们统计到如今APP上面下载的平均速度是400K左右，这样计算的话，可能在安卓上面播放一个视频的话，须要将近0.9秒左右才能够下载到你须要的数据。若是码率再进一步提高的话，可能会更大，这其实咱们也作了一些场景分析，会发现咱们是社交网站，它有好友动态，视频在好友动态里播放，或者是在视频浮层里播放，咱们的选择是预加载的策略，这也是常见的策略。咱们会在当前看的这条动态时会预加载后面视频的关键信息，好比说会加载头部信息和须要播放的数据，来进行预加载。好比说在播放当前视频时，个人视频在加载必定数据以后会加载下一秒预加载数据，这些均可以作到的。

预加载有一个问题，咱们以前踩了一个坑，可能预加载视频时仍是要优先图片的。视频固然重要，可是社交网络上的图片也更重要，可能在预加载视频时会考虑到图片的一些任务，还有视频封面之类。

优化效果也是比较明显，通过刚才几个策略，一个是咱们对头和播放器的处理，咱们对防盗链的处理，还有对下载链路的处理和预加载，这样咱们的耗时大幅度减小了，以前是1.8秒降到0.6秒左右。客户端的性能也是让人容易忽视的问题，发现有些用户虽然有视频的缓存，可是播起来仍是很慢，这实际上是客户端性能的影响。由于视频涉及到的BU和流程比较多，在这个过程当中还要更关注到客户端的影响，要分析下客户端是哪些在抢占你的视频播放资源，咱们以前犯过一些错误，md5会卡住一些流程，或者是HttpParser会阻止你的任务，会致使视频播放更慢。

在优化视频播放过程当中，咱们在4月份也作直播。直播这里面插入个事情，咱们要播放直播的视频流，是HLS的视频，在好友动态里面能够观看直播的内容。HLS在安卓上面体验很是差，由于安卓3.0以后对HLS基本没有作的优化工做，这里每次安卓上播放HLS须要等待6-9秒。分析发现它的处理也不是很得当，由于安卓系统请求链路较长，串行下载，须要下载3-4片TS才能启动播放，下载3个分片的话，耗时就会好久。以前提到咱们这里有代理，有了代理以后作事情方便不少了，经过里获取M3U8，解析M3U8里面有哪些文件，能够作并行下载，只让他下载一次M3U8，这样下载速度大幅度提高。回到刚才架构上，有了下载代理层的话，你能够作HLS的加速和管理，能够加入HLS的视频源。

HLS缓冲耗时也是很明显的，以前须要6秒左右，如今1.6秒左右就能够播起来。总体从以前的2秒左右如今优化到700m秒，80%用户均可以在1秒内播视频。

还有一个是用户比较关注的问题，观看视频时卡，观看一会卡了一下，loading数据，loading完之后又卡，这个体验很是差，咱们但愿全部的视频都不卡。其实这有两个播放场景，一个是正常场景，边下边看，数据在下载。对于正常场景下载时会作一些带宽调整，在低速时会作切换IP的处理，好比说当前连通IP的耗时比较久的话，会作一些处理，也会对网络进行速度限制。

针对Seek场景的话，若是用户拖动的话，文件缓存系统是连续存储系统的话，必然会形成拖到这里时，后面的缓存数据是没有办法下载到系统里面来的。

咱们就对存储作了一次重构，支持文件空洞。会按照一兆的方式对文件进行碎片划分，好处是我能够分段存储，我能够容许逻辑空洞的，拖动的话也能够在后面存储，也不须要数据库，我能够知道这是从哪一个位置到哪一个位置的存储。这样淘汰缓存也高效一点，并能够制定更灵活的缓存策略。这里能够淘汰更低密度的文件，还能够作的事情是对文件加密。这里产生卡顿的用户里面，90%是由于进行拖动，拖动以后又没有缓存数据，因此这里有可能致使发生缓冲。统计效果也是比较明显的，上了分片缓存以后，以前的缓存几率是4.6%左右，最后降低到0.48%，基本上看不到发生缓冲的场景。

成功率优化，也是咱们比较关键的指标。成功率优化没有捷径，多是Case by Case各个击破。以前咱们进行编码，有几百个错误码，错误码缘由进行上报，每次进行循环，一个个错误码进行解决。下载常见的错误码，DNS劫持是比较多的，一些网络运营商会劫持你的请求。

这个在国内是比较常见的劫持，有的小运营商按月会劫持你的视频内容，可能直接污染你的DNS让你查找不到CDN，这是比较多的，还有一些网络不稳定的影响致使。更隐藏的会直接污染你的视频内容，让你视频内容是错误的。播放比较多的多是一些编码的缘由，刚才提到一些手机采集出来的视频在低端手机上播不出来，咱们会对这些视频进行修复。

逻辑上的问题，由于播放器有状态的，可能开发人员比较多，每一个人过来加一个逻辑的话，会致使播放状态出现问题。

咱们作的播放器错误解决方法：

HOOK播放器接口与回调，实现播放器状态机，监控插放器API的调用是否合法，不合法直接告警或Crash。帮助开发快速定位问题，同时减轻测试同事的负担，封装成UI组件，使其它开发没必要理解播放器。

最终优化的成果是这样的，下载成功率优化前是97.1%，优化后是99.9%。播放成功率优化前是97.0%，优化后是99.9%。首次缓冲耗时优化前是1.95s，优化后是0.7s。二次缓冲几率优化前是4.63%，优化后是0.48%。数据仍是很可观的。

个人演讲基本是这些，欢迎你们关注咱们团队的公众帐号，也会分享一些技术文章。

Q&A

问题1：刚才您提到已经开始尝试用265了，能透露一下265大家播放的在总体中占多大的比例？

王辉：如今热视频里面80%都是H.265。10亿里面会有70%、80%左右。

问题2：推动的仍是挺靠前的。刚才你提到要判断手机的H.265能力，用大规模的浮点运算，首先我先了解一下大家用的什么浮点运算的Mark？其次，为何要用浮点运算？其实视频编解码里面几乎所有都是整数运算。

王辉：浮点运算能表明你这个手机性能，其实咱们是评估性能的，不是评估H.265转码，若是性能达到的话，解码也是能够达到的。

问题3：若是想针对解码作评估的话，我建议整数运算。你能够确认一下，首先视频编解码的标准规定是没有浮点运算，不一样的编解码时限可能会插入少许的浮点运算，大部分是整数运算。

王辉：咱们初步作的时候是判断手机有没有运算能力来作的浮点运算判断。

主持人：感谢各位嘉宾的提问，感谢王辉老师给你们带来的讲解。

相关阅读

周杰伦读心术背后的技术实现

点播文件防盗链二三事

HLS 视频点播初探

此文已由做者受权腾讯云技术社区发布，转载请注明原文出处

原文连接：https://cloud.tencent.com/community/article/446586?fromSource=gwzcw.632156.632156.632156

海量技术实践经验，尽在腾讯云社区