最近支持了两个M3U8的高清点播服务，有些心得需要总结如下
问：为何点播要用M3U8来搞？存成一个文件不更好吗？
答：1. 下载速度： 一般下载对于高清视频总会出现观看不太流畅的问题（P2P除外）
2. 磁盘：高清点播长视频一般都是G级别的，对于大文件下载来说，单盘的IO压力较大。如果能在磁盘上将大文件打散分片存储,单盘IO将会大大缓解
3. 容错：下载或存储过程中，1G的文件中任一字节出错将导致 可能会导致改视频的失效，而被切成小碎片后，容错将变得相对简单，只需补全出错的切片即可。
4. 分发：大文件分发起来相对小文件比较困难，下载耗时长，特别是在服务初期，源服务器需要承受极高的磁盘IO请求
5. 简单：simple is beautiful~
问：CDN对m3u8点播需要做哪些支持？
答：受限于播放器与源站之间的交互行为的不确定性，给M3U8做缓存 加速服务时，最好先抓包 分析下 在播放器 与源站直接交互时的请求与响应头，这样会加速解决在经过CDN时遇到的故障。
特别是需要注意：
1.源站明确告诉播放器哪些内容不能缓存，明确cache-control：no-cache的，尽量不要与源站配置一致，如可能影响到播放器的xml控制文件及M3U8文件（分析其内容是否会变化）
2.长连接：源站与播放器直接的交互是开启长连接，Connection：keep-alive，如果是长连接的话，在拿wireshark 打开包时，点击follow stream时，将可以看到一个stream流中有多次GET请求及响应，一般的播放及拖拽卡顿，很有可能是长连接没有打开，注意开启 CDN设备到 播放器，及CDN到源站的长连接。这样可以将miss时对用户的体验降到最低。
问: M3U8支持中遇到的一些问题，及优化措施
答：1.提前预加载，获取所有m3u8列表，跑个脚本，先全部预加载到CDN设备上。比较土，但不影响后续观看体验。
2.实时预加载，在CDN设备上首次获取M3U8文件时，在CDN端对M3U8进行解析，自行在CDN内部完成对视频文件的预热。相对更理想，但在CDN端做解析，会让M3U8从源站到客户端加大延迟。相对1来说稍复杂点。
总结：CDN视频加速夹在播放器与服务端，总是要揣摩播放器的一些行为，如果播放器与服务器之间没有啥隐晦的规则还好，反之将在联调之际灰常蛋疼。
阅读(17936) | 评论(2) | 转发(1) |
