1、加密目的：
1、为了防止视频盗链，导致服务器流量剧增，增加运营成本；同时也是资源保护的一种措施。
2、m3u8与mp4对比
1、m3u8两个 TS 片段可以无缝拼接或者嵌套，播放器能连续播放，视频拼接或者剪辑比较方便。eg:视频加广告,免费试看的5分钟不做加密，后面的视频加密，播放需要鉴权解密。
2、m3u8根据列表文件中的时间轴找出对应的 TS 片段下载即可，不需要 range request，对代理服务器的要求小很多。所有代理服务器都支持小文件的高效缓存。
3、m3u8可以实现多码率视频的适配，可以根据用户的网络带宽情况，自动为客户端匹配一个合适的码率文件进行播放，从而保证视频的流畅度
4、mp4 结构相对复杂，长视频的加载速度相对较低。
3、熟悉m3u8格式及hls协议（m3u8嵌套，直播与点播）
4、加解密方案：1、整体加密 2、逐条ts加密
首先要分清楚2种情况
1、本来就是加密链接(包含#EXT-X-KEY字段)
2、人为加密后的加密链接(包含#EXT-X-KEY字段，但是后端又进行了加密)
第一种情况，如果你将一个包含加密字段#EXT-X-KEY的正常m3u8链接放进AVPlayerItem里面初始化，AVPlayer也能播放出来，这说明什么？说明AVPlayer是会对包含#EXT-X-KEY字段的m3u8进行一次解密操作，这些操作是系统底层做的，抓包可以看到。
AVPlayer播放m3u8的流程大致如下：
1、请求m3u8-->请求ts-->包含#EXT-X-KEY字段?-->包含或不包含
2、包含-->不真实ts-->请求URI-->获取key-->AES128解密ts-->请求真实ts
3、不包含-->真实ts-->请求真实ts
流程很简单，那么我们来看看第二种情况，按上面的底层逻辑处理流程大致如下:
2、包含-->不真实ts(加密ts)-->请求URI(加密URI)-->获取key(加密key)-->AES128解密ts-->请求真实ts
对应代码实现：在AVPlayer的代理方法中实现
IJKPlayer播放加密的m3u8流程：
应用层没有API回调，需要在底层实现解密逻辑。
1、通过本地缓存m3u8方式进行播放：
大致流程：
请求m3u8数据 --> 对m3u8进行解析 --> 逐条解析ts，并解密 --> 解密后的ts组合成为新的m3u8文件，保存本地 --> 开启本地服务代理 --> 通过本地代理进行播放
2、底层进行解密播放
需要修改FFMpeg的hls协议文件，在hls.c文件实现解密逻辑，解密后需要重新编译成Framwork。
文件路径：
3、本地缓存播放与底层解密对比
通过本地缓存播放：缺点：下载m3u8后，需要批量解密ts形成新的m3u8列表，视频较长的话会有上万个ts，解密消耗时间比较长（尤其智能电视机顶盒等硬件模块性能较弱的产品），导致视频起播时间长，体验不好
底层解密：播放时逐条解密，不存在消耗时间过长的问题，一般在毫秒级别，体验较好。缺点：时间成本较高。
5、延伸播放器对比：AVPlayer VS IJKPlayer
后期会针对AVPlayer 和 IJKPlayer做下对比分析，敬请期待。。。
