kazumi视频解析原理

Kazumi 的设计是这样的，在定位到播放器所在 iframe 之后，会拉起一个无头 webview 来访问 iframe ，webview 拥有所有的浏览器功能，所以他可以通过各种加密校验。然后我们使用一些有趣的 javascript 魔术来截取接下来要请求的视频流，成功之后 webview 被销毁，视频流交给内嵌播放器播放。

上图的 Parsing video source 是要解析的 iframe 而不是视频流本身。实际上获取的视频流的地址是绝对正确的，只不过没有打印在日志中。 打印日志是 webview 阶段，当开始转圈后，即进入内嵌播放器阶段。

那为什么播放不了呢，我刚刚检查了一下这条规则，看上去它和次元城的播放器是完全相同的。他们在影片加载完成，可以播放第一帧前，向服务器发送一次回调，标记当前视频流为可用状态，如果没有这个标记，视频流不可用。

为了效率，Kazumi在解析出视频地址后会立即销毁 webview 并拉起内嵌播放器。这时视频还没开始加载，回调也尚未发出，所以视频流无效。

如果一定要等这个回调，解析会大概慢5秒，这在我看来是无法接受的。

JS的执行环境是不安全的，其标准方法是可以被篡改的。

无论解析接口如何加密，最终还是需要XHR来请求直链，我们篡改了XHR相关函数，检查每个请求是否包含 m3u8 视频流中的关键字，符合的话即为直链。

核心实现大概就是这样的，但是因为有CORS的存在，实际上复杂一些。

具体实现在 /lib/pages/webview/webview_controller_impel.dart 下面。

 也有道理，这样确实会降低一些自由度，不过也确实大大降低了门槛。不过我还是好奇它是如何精确定位播放页内嵌的播放器的呢？而且播放直链也不一定会有像.m3u8这种明显的关键字特征，这又是怎么处理的呢？

还有类似Cloudflare反爬，需要携带特定 cookie 过检查的场景

只检查URL的话就不用这样做了，实际上挂钩XHR标准方法是为了检查所有请求的响应内容。

m3u8 视频流必然以 #EXTM3U 开头。