1.为什么网络点播系统使用m3u8更有优势?为何点播要用M3U8来搞？存成一个文件不更好吗？

一个MP4文件可能几百M或几个G，如果读取整个MP4文件的信息并且需要下载一段内容，首次打开播放超慢（加载时间长）。如果把MP4文件切片播放，每个分片100多KB，播放会更快。

2.M3U8+MPEGTS分片播放的优势?

播放速度块：MP4文件播放在开始加载的时，会读取很大的文件信息，可能会导致卡顿很长时间才能播放。而m3u8分片，则会瞬间读取整个视频文件信息，马上开始加载第一片ts视频文件播放，不管是开始播放还是拖拽播放的加载速度都比MP4快N倍。
缓解磁盘IO：高清视频文件一般都是G级别的，对于大文件下载来说，单盘的IO压力较大。如果能在磁盘上将大文件打散分片存储，需要播放的部分才下载，不需要播放的部分则不下载，这样硬盘IO将会大大缓解。
容错简单：下载或存储过程中，1G的文件中任一字节出错将可能会导致整个视频失效，而被切成小碎片后，容错将变得相对简单，只需补全出错的切片即可。
分发简单：大文件分发起来相对小文件比较困难，下载耗时长，特别是在服务初期，源服务器需要承受极高的磁盘IO请求。基本上很少看到超大文件做cdn分发的，而ts分片文件做cdn缓存就很容易了，文件小缓存速度快，基本上没有缓存失败的可能。
缓存下载优秀：MP4在HTTP状态下会一直下载文件，不管用户是否需要播放后面的内容都会一直下载直到完全下载完成。而分片文件则不存在这个问题，通过播放器或服务器端的控制，只下载需要播放的部分内容，不播放则不下载。

受限于播放器与源站之间的交互行为的不确定性，给M3U8做缓存和加速服务时，最好先抓包分析下播放器与源站直接交互时的请求与响应头，这样会加速解决在经过CDN时遇到的故障。

源站明确告诉播放器哪些内容不能缓存，明确cache-control：no-cache的，尽量不要与源站配置一致，如可能影响到播放器的xml控制文件及M3U8文件（分析其内容是否会变化）
长连接：源站与播放器直接的交互是开启长连接，Connection：keep-alive，如果是长连接的话，在拿wireshark 打开包时，点击follow stream时，将可以看到一个stream流中有多次GET请求及响应。一般的播放及拖拽卡顿，很有可能是长连接没有打开，注意开启CDN设备到播放器，及CDN到源站的长连接。这样可以将miss时对用户的体验降到最低。

提前预加载，获取所有m3u8列表，跑个脚本，先全部预加载到CDN设备上。比较土，但不影响后续观看体验。
实时预加载，在CDN设备上首次获取M3U8文件时，在CDN端对M3U8进行解析，自行在CDN内部完成对视频文件的预热。相对更理想，但在CDN端做解析，会让M3U8从源站到客户端加大延迟。相对1来说稍复杂点。

ffmpeg -i HD1080P_FinalOutput.mp4 -hls_time 5 -hls_list_size 0 -c copy -f hls  HD1080P_FinalOutput.m3u8