之前的工作中负责了视频广告业务，也顺带学习了下音视频相关的基本知识。这篇文章是在支持了音视频基本功能后，进行视频广告启播优化时学习和调研的一次总结。
版权声明：本文为博主原创文章，未经博主允许不得转载。
1.优化的目的
本次优化基于提前mp4文件moov box的位置，可以大幅提升在线视频广告/未缓存视频的启播效率。
目前常见缩短视频起播时长优化点：https://zhuanlan.zhihu.com/p/112773041
还有一篇微信团队的视频播放优化浅析也很不错：https://cloud.tencent.com/developer/article/1831098
2.Moov耗时原因
首先mp4是由很多box组成的，在moov box中存储了描述音视频格式如视频宽高、分辨率、码率等相关的格式信息，先要拿到这些信息才能播放。如果将moov box放在文件的前面，那么只需要通过一次http请求就可以直接读取到，进而执行解封装。而如果在moov box放在文件的后边，但关键是播放器不知道它放在后面，这就需要先发起一次http请求读开头部分数据，发现是mdat，进而会seek到文件后边位置，读取moov box，然后再seek到文件前边的mdat，从新读取mdat。每发生一次seek就会重新发起一次http connetion请求。因此moov box放在后边比放在前边多了2次http connection。
如果在起播过程中发生了http re-connection耗时肯定会增加，而且http connection的耗时基本是不可优化的，所以要避免http re-connection的发生。因此将mp4中moov box提前会有比较好的优化效果。
这里关于 “如果一开始就读取到mdat后是否会seek到末尾”问题，我在不同的文章中发现了不同的结论。有文章说如果一开始就读取到mdat后会一直把mdat请求完毕，也就是内容全部下载完后读取moov-解封装-播放。播放等待时间为内容下载耗时。我看的这篇文章写的是读到mdat后会seek到末尾，再seek回mdat，耗时为http connection耗时。我查阅其他文章后目前的结论是：是否可以seek到数据末尾请求数据需要服务端支持。如果只是把视频文件简单存放在服务端，请求的时候是没法seek也就是不能先请求最后的数据的。如果服务端支持seek，那么则可以实现先请求最后的box数据，再请求前面的数据，最后合包时组合成原始数据。
3.解决方案
线上方案：在mp4文件上传到服务器之后，重新封装，把moov_box放到mdat前面。此方案实施在广告投放平台，由后端和视频团队执行。
本次调研方案：本次调研为纯客户端调研。首先找了一段测试视频广告1，用mp4info确认视频1的moov_box在最末端。然后从网上找了一段能将mp4中的moov box提前的python脚本，在本地执行将视频1的moov_box提前生成视频2。将视频1和视频2上传广告测试平台。在app中用同一广告位分别拉取两个视频广告，测试启播时间。
4.调研结果
- 设备：三星J600G
- app：ShareKaro(v1.1.69)
- 播放器：mediaplayer
- 广告：4146(转码后)/4364(转码前)。强拉。时长27s，大小1392KB
- mp4info解析moov位置：
转码前：
转码后：
- 可以看到转码后moov位置提到mdat之前
- 参考耗时：startPreparing(自己的tag，在对应mediaplayer的prepareAsync前)和onPrepared(对应mediaplayer的onPrepared状态)之间为mediaplayer起播内部耗时(解协议、解封装)。
转码前：
转码后：
从调研结果看，调整后的启播时间能缩短1个数量级左右。视觉上对于视频启播时间缩短有明显的效果。