iOS 视频加解密方案（AVPlayer、IJKPlayer）

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做下对比分析，敬请期待。。。