Predidit

从 ffmpeg 入手理论上可以无感跳过并且性能优秀 我们不需要维护 ffmpeg fork ，但是需要维护一个 ffmpeg 树外补丁，插入我们的 libmpv 构建流程中，就像我们的 mpv 原生 directX 渲染接口补丁一样 https://github.com/Predidit/libmpv-win32-video-cmake/blob/master/packages/mpv-0001-dxd11-render-api.patch

@0Chencc 我在我的 Github 时间轴上看到了你正在制作的 ffmpeg 补丁，看上去非常不错，不过有一些需要注意的地方 1. 正常 seek 一样会导致 PTS 不连续，需要额外检查 PTS 位置是否在视频最开头，但这又可能破坏我们直接向视频开头进行的跳转 2. #EXT-X-DISCONTINUITY 标志对于精准移除不起作用，这个标志在我们的用例里很重要，大部分广告插入直接将其作用域拓展到整个清单文件，以表示任何片段都可能不连续，以规避相关广告片段被精准移除，我们现在的补丁会将整个清单移除 3. 关于编译，需要现在 Github Actions 中完成 LLVM 工具链编译，才能进行 MPV 编译，不要删除 Github Actions 中和 LLVM...

@0Chencc 我查看了一下你的分支上现在的改动 1. 每次编译之后在 cache 清除掉 mpv 缓存，但不要清除 llvm 缓存，你可以从这些缓存建立的时间来粗略判断哪些来自工具链编译，不然之前编译失败的部分产物可能留在编译环境中，例如已经应用的补丁，导致补丁和当前目录冲突，出现编译失败。 2. 使用AI辅助尽量先在完整的 ffmpeg 代码库中操作，然后手动 git diff 出来，现在的 AI 还没进化到能直接修 patch 的地步。 我仓库的工具链也在编译，明天我也会做一些尝试，有些规则的广告太多了

@0Chencc 我对 ffmpeg 的内部细节不熟悉，你可以考虑问问AI，但我觉得可能是 PTS 需要更精细的校准，每个流(无论是视频还是音频)有自己的PTS。 mpv 上层虽然有一个可以调整脱同步时播放器行为的属性 video-sync ，但是在我们的用例下应该不会正确生效。我们还是要在这个补丁的范围内修复错误。 此外即使编译成功了，也需要移除 LLVM 之外的缓存，否则CI执行过程中 ffmpeg 不会重新编译。

抱歉，由于 libmpv-win32 那个仓库是一个 fork 仓库，我并没有收到 PR 的邮件提醒，我会在明天尽快尝试你的实现。

@0Chencc 很高兴看到我们终于编译出了可用的 mpv 二进制文件，我将立即着手开始测试 我注意到你只编译了完整的 mpv 可执行程序，而没有编译 .dll ，我像知道这是有意为之，方便测试，还是错误运行了 actions 如果要编译 .dll ，在运行 actions 时不要勾选 `Build latest mpv tarball` 复选项 此外我注意到补丁中已经有简单的重同步逻辑，你提到的 `卡顿过后我使用了一次seek做了同步校准` 指的是这里的同步，还是我们需要在 dart 侧手动同步

@0Chencc 我注意到你在试图利用简单的方式上传包含 .dll 的名称中带有 dev 字样的打包 这样是不能成功的，因为相关文件并不存在， `Build latest mpv tarball` 复选项控制了 CI 运行 mpv.cmake 还是 mpv-release.cmake 而 .dll 的打包逻辑只存在于 mpv.cmake 中

我建议你勾选和不勾选 `Build latest mpv tarball` 各运行一次 CI 这样我们可以得到一份完整版本和一份能立即在 kazumi 中测试的 dll

看上去相当不错，我会在明天给出反馈

@0Chencc 这个复杂的实现完美的让我惊讶，令人头痛的误判问题也用 ffmepg 的内部方法成功解决了。 实际使用效果也非常好，虽然只测试了 vip.dytt-hot.com 域名下的资源，但是泛用性应该相当不错，我在找一些其他的流进行测试 在此期间，你可以准备一下全平台其他编译仓库的PR吗，如果有补丁兼容问题，可以直接将 ffmpeg 定位到我们现在的版本。