在优化视频播放过程中，我们在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：如果想针对解码做评估的话，我建议整数运算。你可以确认一下，首先视频编解码的标准规定是没有浮点运算，不同的编解码时限可能会插入少量的浮点运算，大部分是整数运算。

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

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