m3u8转mp4什么意思_m3u8转mp4 ffmpeg（m3u8转mp4是什么情况?）

摘要： 　　编者按：本文来自微信公众号“InfoQ（ID：infoqchina）”；36氪经授权发布。 　　注：本文整理自腾讯研发总监王辉在 QCon 北京 2017 上的演讲，原题为：《...

　　编者按：本文来自微信公众号“InfoQ（ID：infoqchina）”；36氪经授权发布。

　　注：本文整理自腾讯研发总监王辉在 QCon 北京 2017 上的演讲，原题为：《十亿级视频播放技能 优化揭秘》。

　　QQ 空间在 2016 年日均视频播放量由年初的千万 级敏捷 突破到十亿级，过程中也对整个视频播放技能 的可靠性、性能、操纵 体验等方面提出严厉 的检验 ，相干 质量急需提拔 。颠末 多个迭代连续 和各项优化，外网团体 质量已经达标：在包管 播放乐成 率提拔 到 99.92% 的底子 上，初次 缓冲耗时降到 0.70s，二次缓冲概率降到 0.48%，做到稳中有升。我们将从视频组件的团体 架构，优化结果 衡量 ，初次 缓冲耗时优化，播放乐成 率优化，二次缓冲优化，总结六个方面先容 视频点播在整个优化过程中的心路进程 。

　　写在前面

　　我本日 的话题是“十亿级视频播放技能 优化揭密”。先容 我们团队在客岁 短视频风口上，视频播放量从 5000 万到十亿级过程中的一些技能 实践，盼望 我的分享能给各人 带来一些鉴戒 和参考。

　　自我先容 一下，我叫王辉，来自腾讯，从 2009 年开始从事 QQ 空间技能 研发，近期重要 关注手机短视频、视频直播、AI 智能硬件。我个人喜好 跑步，以为 跑步是办理 程序员亚康健 的一个比力 好的方式。

　　众所周知，短视频客岁 是一个风口，因由 是来自 Facebook 2015 年 Q3 的财报，财报表明在 Facebook 平台上每天 有 80 亿次短视频播放，给 Facebook 带来了强劲的广告收入，正是这个数据给国内核心 大公司和创业公司带来的一些新的突破口。

　　着实 短视频已经不是一个新的概念，从 2006 年开始国内就有很多 公司在做短视频。随着 Facebook 吹起短视频风，客岁 在短视频行业有近百款应用出现，中国网民内里 每 5 个内里 就有 1 个是短视频的用户，短视频成为互联网的流量入口。

　　QQ 空间也在这个风口中，从 2015 年 11 月份的每天 5000 万视频播放量，颠末 一年的耕耘细作，徒增到 2016 年 12 月份的 10 亿量级，如今 还在不绝 增长。

　　我的分享重要 是按照我们产物 迭代的几个关键步调 睁开 ：

　　1、起首 是快速上线，2015 年我也是跟随着各人 的体验快速上线了新短视频的体验；

　　2、其次面对 的是本钱 题目 ，在做的过程中做了一些本钱 的优化工作；

　　3、然后是体验优化。在办理 本钱 题目 之后，短视频的观看体验要做到极致。比如 说视频的秒开、不产生缓冲、不卡、乐成 率的提拔 。

　　快速上线

　　起首 看快速上线，在开始之前，我先先容 一下我们的团队职责，我们团队负责手机 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，如许 代码复用更清楚 一点，我的团队更专注一点。视频的团队专凝视 频的研发。

　　监控上报，肯定是不可缺少的，这是一个成熟的项目必备的要素：

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

　　颠末 评估之后，判定 当前机型更得当 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 一打开动态，视频是能立即 播出来的，不必要 等待 就能播，这个体验着实 很顺畅。

　　核心 的流程重要 是三个步调 ：

　　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 秒视频数据才可以播起来。

　　假如 必要 下载 5 秒数据才可以播的话，肯定黑白 常慢的。我们这里的战略 会采取 FFmpeg Based Player 本身 来做解码，要关注兼容性和耗电的题目 。办理 了 Mdata 之后，假如 MOOV 数据在头部，拿关键信息举行 播放的话，着实 必要 的开始播放数据量黑白 常小的。

　　对于下载优化，会有一个防盗链的哀求 ，通过 HTTP 拿到真实的播放 URL 才可以下载数据。

　　但是在手机上实行 HTTP 哀求 非常耗时，这里私运 有长毗连 通道做这个事变 。

　　关于优化下载链路，这里也是谈的比力 多的，一样平常 也是直接输出 IP 地点 ，利用 IP 地点 做赛马 的战略 ，分身 性能的服从 ，这个是用的比力 多的方式。

　　进一步思考 ，按照广泛 600K 码率的话，我们统计到如今 APP 上面下载的均匀 速率 是 400K 左右，如许 盘算 的话，大概 在安卓上面播放一个视频的话，必要 将近 0.9 秒左右才可以下载到你必要 的数据。

　　假如 码率再进一步提拔 的话，大概 会更大，这着实 我们也做了一些场景分析，会发现我们是交际 网站，它有好友 动态，视频在好友 动态里播放，大概 是在视频浮层里播放，我们的选择是预加载的战略 ，这也是常见的战略 。

　　我们会在当前看这条动态时，预加载背面 视频的关键信息，比如 会加载头部信息和必要 播放的数据。在播放当前视频时，加载肯定 命 据之后会加载下一个视频的数据，这些都可以做到的。预加载有一个题目 ，我们之前踩了一个坑，大概 预加载视频时还是 要优先图片的。视频固然 紧张 ，但是交际 网络的图片更紧张 ，大概 在预加载视频时会思量 到更高优先级的一些任务 。

　　优化结果 也是比力 显着 ，颠末 刚才几个战略 ，一个是我们对头和播放器的处理 惩罚 ，我们对防盗链的处理 惩罚 ，尚有 对下载链路的处理 惩罚 和预加载，如许 我们的耗时大幅度镌汰 了，之前是 1.8 秒降到 0.6 秒左右。

　　客户端的性能也是让人轻易 忽视的题目 ，发现有些用户固然 有视频的缓存，但是播起来还是 很慢，这着实 是客户端性能的影响。

　　由于 视频涉及到的流程比力 多，在这个过程中还要更关注客户端的影响，要分析下客户端哪些在抢占视频播放资源，我们之前犯过一些错误，md5 会卡住一些流程，大概 是 HttpParser 会制止 你的任务 ，会导致视频播放更慢。

　　在优化视频播放过程中，我们在 4 月份也做直播。直播这内里 插入个事变 ，我们要播放直播的视频流，是 HLS 的视频，在好友 动态内里 可以观看直播的内容。HLS 在安卓上面体验非常差，由于 安卓 3.0 之后对 HLS 根本 没有做的优化工作，这里每次安卓上播放 HLS 必要 等待 6-9 秒。

　　分析发现它的处理 惩罚 也不是很得当 ，由于 安卓体系 哀求 链路较长，串行下载，必要 下载 3-4 片 TS 才华 启动播放，下载 3 个分片的话，耗时就会好久 。之条件 到我们这里有署理 ，有了署理 之后办事 变 方便很多 了，通过里获取 M3U8，分析 M3U8 内里 有哪些文件，可以做并行下载，只让他下载一次 M3U8，如许 下载速率 大幅度提拔 。回到刚才架构上，有了下载署理 层的话，你可以做 HLS 的加快 和管理，可以参加 HLS 的视频源。

　　回到刚才架构上，有了下载署理 层的话，可以做 HLS 的加快 和下载管理，可以参加 HLS 的视频源。

　　HLS 优化结果 也是很显着 的，之前必要 6 秒左右，如今 1 秒左右就可以播起来。团体 从之前的 2 秒左右，如今 优化到 700m 秒，0-1 秒的占比如今 在 80% 左右，80% 用户都可以在 1 秒内播视频。

　　体验优化

　　尚有 一个是用户比力 关注的题目 ，观看视频时卡，观看一会卡了一下，loading 数据，loading 完以后又卡，这个体验非常差，我们盼望 全部 的视频都不卡。

　　着实 这有两个播放场景，一个是正常场景，边下边看，数据在下载。对于正常场景下载时会做一些带宽调解 ，在低速时会做切换 IP 的处理 惩罚 ，比如 说当前连通 IP 的耗时比力 久的话，会做一些处理 惩罚 ，也会对网络举行 速率 限定 。

　　针对 Seek 场景，用户拖动，假如 文件缓存体系 是次序 存储体系 的话，肯定 会造成拖到这里时，背面 的缓存数据没有办法下载到体系 内里 来。只要用户每次拖动，拖动后的下载数据没法存到硬盘上来。

　　我们就对存储做了一次重构，支持文件空洞。会按照一兆的方式举行 文件碎片分别 ，这就是视频的数据，每一兆就是个文件分片，通过它的 Key 和文件举行 存储，如许 长处 是可以分段存储，可以答应 逻辑空洞，拖动的话也可以在背面 存储，也不依靠 数据库，通过文件名可以知道是从哪个位置到哪个位置的存储。如许 镌汰 缓存高效一点，可以订定 更机动 的缓存战略 。可以镌汰 更低粒度的文件，比如 seek 之后的文件可以保存 ，还可以对文件加密。

　　产生卡顿的用户内里 ，90% 是由于 举行 拖动，拖动之后又没有缓存数据，以是 这里有大概 导致缓存。统计结果 也是比力 显着 的，上了分片缓存之后，之前的缓存概率是 4.6% 左右，末了 降落 到 0.48%，根本 上看不到发生缓冲的场景。

　　乐成 率优化，也是比力 关键的指标。乐成 率优化没有捷径，大概 是 Case by Case 各个击破。针对错误举行 编码，有几百个错误码，每一个错误码捞 log 去看，错误码缘故起因 举行 上报，每次举行 循环一个个错误码举行 办理 。

　　DNS 挟制 是比力 多的，会挟制 你的哀求 。这个是在国内比力 常见的挟制 ，有的小运营商按 URL 挟制 视频内容，大概 直接污染 DNS 让你查找不到 CDN，这是比力 多的，尚有 一些网络不稳固 的影响导致。更高级的直接污染视频内容，让视频内容是错误的。

　　播放比力 多的大概 是一些编码的缘故起因 ，手机收罗 出来的视频在低端手机上播不出来，我们会对这些视频举行 修复。

　　逻辑上的题目 ，由于 播放器是有状态机的，开辟 职员 比力 多，每个人过来加一个逻辑的话，会导致播放状态出现题目 。

　　我们办理 播放器错误的方法：HOOK 播放器接口与回调，实现播放器状态机，监控插放器 API 的调用是否合法 ，不合法 直接告警或 Crash。资助 开辟 快速定位题目 ，同时减轻测试同事的负担，封装成 UI 组件，使别的 开辟 不必明白 播放器。

　　终极 优化的结果 是如许 的，下载乐成 率优化前是 97.1%，优化后是 99.9%。播放乐成 率优化前是 97.0%，优化后是 99.9%。初次 缓冲耗时优化前是 1.95s，优化后是 0.7s。二次缓冲概率优化前是 4.63%，优化后是 0.48%。数据还是 很可观的。