Flutter工程笔记 | 拿到了腾讯云VOD的隐藏文档以后……

接着昨天的文章讨论。

昨晚的文章发了以后，腾讯云云开发的总经理宁总帮我联系了VOD的负责人（十分感谢！），今天VOD的产品经理和我对接以后，我拿到了梦寐以求的关键文档之一——VOD播放器的前端接口文档。他们说这是个给大客户自制播放器提供的文档。不知道出于什么考虑，这个文档是隐藏的，这次是接触到专门的负责人才搞到这个文档，之前提交了几次工单都没有拿到；没想到体会了一次大客户的待遇，非常爽。

在和腾讯系团队的沟通中，我经常和他们反馈说，你们把文档开放出来，我们开发者自己搞。如我所料，很多隐藏文档或者内部文档就是我开发中的关键点。腾讯系的文档一直缺乏系统性的建设，从我的观察来看，有一些是出于各种考虑没有放出来，也有更多是缺少成熟的文档。

我需要的这个feature被隐藏，可能是因为需求比较小，也可能是出于安全考虑。不过从开发者的角度来看，这个文档依然不应该被隐藏。即使是小众需求，也是非常重要的帮助理解播放器SDK工作原理的文档，也许真正需要的人不多，但完善的文档可以帮助开发者理解更多细节，也是很好的学习资料。至于安全考虑，理论上安全的算法是可公开方案的，安全算法的关键不在算法细节而在于保护密钥。

昨天研究了一整天视频加解密的技术原理，今天一看文档就明白了原理。简单地概括，在HLS标准方案上加了一层加密AES Key的非对称加密机制。在很多关于视频加解密的技术文章都提到用这种用非对称加密传对称加密密钥的机制（事实上，这是一种非常标准且基础的网络安全机制）。从文档里显示的细节来看，一个有经验的开发者理论上可以通过抓包来摸清这个机制，所以文档公开对于破解不一定很有帮助，但对于开发则特别有帮助。

follow文档中的流程图，我设计了一个Flutter类来控制这个流程。这个类的输入是官方播放器SDK暴露的appId、fileId、pSign三个参数，在实例化的时候传入；输出值是HLS标准输出，包括解析以后的m3u8文件里的信息、加密视频的播放地址URL、明文Key。这样，再把相关参数传入支持HLS的播放器就可以了，应当有很多现成解决方案可以用或者二次开发。

不过这个类应当是一个怎样的类、怎么命名、怎么设计结构，我还没有很清楚的界限。我写算法习惯写过程式，比较符合算法流程思路。这个打包数据传input和ouput的类，我其实是把它当成结构体用的。这应当是一个Client类还是Data类我不是很确定，暂且当成了一个做网络请求和解析的Client类。

这个类依赖的函数/方法比较典型和简单，但我不是很熟Dart，所以只是先把框架写了出来，打算慢慢写unit test调。主要包括：

- 网络请求：从开发者服务器请求pSign、向云点播服务器请求video信息、向云点播服务器请求加密以后的Key三个函数；

- 加解密算法：生成客户端的随机密钥对、用云点播提供的公钥加密、接收加密Key以后用自己的随机密钥对解密；

- 拼接URL：拼接视频信息请求的URL、拼接DRM Token到播放URL（暂时还搞不懂到底是干啥的，不过看起来只需要follow就可以用）

完整实现以后，还可以加上缓存等功能，应当是一个很大的类。

接下来就是HLS播放器的问题了。我没写过播放器，不是特别熟悉HLS播放器在前端怎么实现，猜测是一系列略微有点繁琐的计算和控制，这种繁琐的问题非常适合找现成的代码实现模仿。由于后续需要接入PC客户端的播放器，所以怎么进行跨端会是非常麻烦的技术问题，不可避免地需要理解所有平台的播放器机制并且进行接口统一，因此把加解密算法和视频播放器解耦是非常重要的工程架构设计，这样后续播放器才能根据约定的接口进行迭代而不影响加解密算法的正常工作。

当然，如果有官方播放器的实现文档用以follow，我想开发难度会降低很多。正在和云点播团队沟通相关问题，看能否要到源码或者文档。

最关键的加解密算法问题解决了，用回了原来的架构，但问题还刚刚开始，后续的工程环节一个比一个麻烦，接下来慢慢去研究。