因为热点转瞬即逝，可能前一分钟是热点，后一分钟就不是热点，社交网络的传播非常快，我们给后台的要求是转码速度一定要快。在之前没有优化时，转一个 10 分钟的视频要半个小时左右。后来做了分布式处理之后，转 10 分钟的视频只用 2-3 分钟。一些短视频最长 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 是在尾部的。后来也发现，有很多安卓手机比如说山寨机，一些摄像头处理的厂商可能比较偷懒，因为他们只有在你采集完信息之后才能知道他所有的信息，他可能把所有的信息放在尾部。

　　对于 iOS 来说，一开始把头部下载了，找不到 MOOV，就猜测 MOOV 在尾部，多一次 Range 请求去探测 MOOV 到底在哪？基本做法是去尾部探测, 如果 MOOV 在其他地方的话，这次播放肯定是失败的。安卓某些手机如果没有经过处理，MOOV 在尾部的情况下需要下载整个视频才能开始播放。

　　我们的处理方式，用户在后台统一做一次转码修复，客户端采集后做一次转码修复。

　　看一下 Mdata，视频的原数据。目前大部分是 H.264 编码，H.264 通过帧预测的方式进行视频编码。这里有一个 GOP 概念，也是在直播里面经常谈的。一般的播放器需要下载完整的 GOP 数据才可以播。

　　需要下载多少数据才能播呢？每个播放器的行为也不一样。iOS 要下载一个完整的 GOP 才可以播。像 FFmpeg Based Player 的话只需要关键帧就可以播出来。安卓是比较尴尬的一个系统，在 6.0 及以下，需要下载 5 秒视频数据才可以播起来。