我们采取的第一个策略是进行流量控制。在高峰期播放到第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一打开动态，视频是能立即播出来的，不需要等待就能播，这个体验其实很顺畅。核心的流程主要是三个步骤：1、客户端的耗时；2、下载数据；3、等待播放。

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

这里有一个很直接的问题，播放器需要下载多少数据才能播放？我们可以看一下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秒左右才可以下载到你需要的数据。如果码率再进一步提升的话，可能会更大，这其实我们也做了一些场景分析，会发现我们是社交网站，它有好友动态，视频在好友动态里播放，或者是在视频浮层里播放，我们的选择是预加载的策略，这也是常见的策略。我们会在当前看的这条动态时会预加载后面视频的关键信息，比如说会加载头部信息和需要播放的数据，来进行预加载。比如说在播放当前视频时，我的视频在加载一定数据之后会加载下一秒预加载数据，这些都可以做到的。

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