主流解决方案
基础
前端读取 m3u8 文件，获得有哪些 ts 文件，并把 ts 文件组合拼装给 video 标签进行播放。
因此一个 m3u8 文件带有多个 ts 文件的链接。
m3u8文件{
ts的链接 * n
}
优化
但是这些 ts 的链接可以被任意下载并播放，没法保护版权。
这个时候，m3u8 文件引入了 key，通过 key 进行加密。只有 ts 链接的人，是无法播放视频的
m3u8文件{
key * 1
ts的链接 * n
}
主流解决方案的问题
即使有了 key，依旧有可以被各种浏览器插件或者工具下载。但比起之前，需要拿到明确的 m3u8 文件，安全性来说是提升了不少。
github 上的 m3u8-downloader 是个网页版，甚至不需要安装都可以用来下载m3u8
那如何避免被下载呢
稍微研究了 polyv 的解决方案，感觉人家的设计思路很不错。之后开发公司的在线视频播放功能，我也计划着按这个设计思路走。
在视频播放页面，会加载多一个m3u8文件，可以扰乱部分浏览器插件的嗅探。
它做得最好的是，把 m3u8 文件中的 key 再单独处理。
它的 m3u8 文件是：
m3u8文件{
key的链接 * 1
ts的链接 * n
}
key 的链接
而这个 key 的链接，是无法直接访问拿到到 key。
实时上，是需要一个 token，拼凑成 key 链接 + token 的新链接，这个时候就可以下载到 key，但这个key 也只是一个中间产物，姑且叫做 token_key 吧。
用户的 token
上述的 token 是通过用户登录后，访问服务器才拿到了，而这个 token 是会变动的，可能一天到两天，会变化，而且每个人都不一样。
获得 token_key 后
通过上述的新链接获得 token_key后，会通过 vodplayer.min.XXXXXXXX.js 进行解密，获得 decrypted_key。只有这个 decrypted_key 才可以解码 ts 文件。
是如何发现 decrypted_key 的
通过 Chrome 中的开发者工具的 Sources 面板的 overrides 功能，加入自己的代码并执行，我才看到他解密后的 decrypted_key。至于它的算法是如何的，我就不能公布了。而且它是可以动态变化了，保密性就更强了，这是我十分欣赏的地方。
修改了一下 m3u8-downloader 的源码 是可以顺利下载对应的 ts 文件并解码的，证明我是理解是正确的
总结
稍微总结一下它的前端处理流程，方便我日后开发的。
- 通过对 m3u8 文件进行解析，获得 key 链接，另一边同时下载未解密的 ts 文件
- 通过用户登陆后的 token 和 key 链接，获得 token_key
- 通过动态生成的解密JS代码，把 token_key 解出 decrypted_key
- 把 decrypted_key 解码出正确的 ts 文件数据，交给 video 标签播放
虽然全部解密都丢给前端处理，是有点防君子不防小人的感觉，但要理解和破解这些，需要花相当长的时间，而且重要的关键 decrypted_key 是动态的，是需要技术能力才能分析出来的，所以没有下载工具或者浏览器插件可以做到完全兼容。
