thumbfast在5月6日的mpv中出错了

[redomCL]

error:can't create mpv subprocess

[dyphire]

今天不才 5.5？你穿越了？
顺便应该是 mpv 上游添加的触控支持引入的错误，关注上游 issue：po5/thumbfast#122

[redomCL]

打错了 是5月4号的

[dyphire]

由 mpv-player/mpv@c4b6d0d 提交修复，今天的构建就会正常工作（尚未构建发布

[zhongfly]

不是mpv的问题，由FFmpeg/FFmpeg@bb80445 引起，然后被 FFmpeg/FFmpeg@6a5b021 修复。
具体见mpv-player/mpv#14047
https://github.com/zhongfly/mpv-winbuild/releases/tag/2024-05-04-637bc69 包含了ffmpeg修复补丁，不包含你说的 mpv-player/mpv@c4b6d0d ，已经解决了这个问题，足以说明。

[dyphire]

确实如此

[zhongfly]

因为不想单开一个讨论，所以就直接在这里说了：
mpv现在添加了媒体控件的支持，并且默认启用，这会导致使用thumfast脚本后，会同时新建2个播放的显示，其中一个不能←→切换的就是脚本进程创建的。更奇怪的是，在另一个播放显示里← →切换的话，mpv窗口会冻结卡死。

所以必需在thumfast脚本里设置--media-controls=no禁用。至少我测试禁用了脚本的控件后，切换不会卡死了

包含媒体控件支持的mpv: https://github.com/zhongfly/mpv-winbuild/actions/runs/10153830186

[dyphire]

为什么会出现这种问题？是 thumfast 在子进程调用了 mpv 创建缩略图的工作方式导致的？

如果是这样，我感觉这是一个 mpv 问题，因为所有不使用 ffmpeg 而通过子进程调用 mpv 来剪切视频创建截图之类的第三方脚本应该都会触发这个问题

像kikoplay 这种调用多个 libmpv 的呢？它的进度条预览也是通过调用一个独立的 libmpv 实现的

[zhongfly]

为什么会出现这种问题？是 thumfast 在子进程调用了 mpv 创建缩略图的工作方式导致的？

如果是这样，我感觉这是一个 mpv 问题，因为所有不使用 ffmpeg 而通过子进程调用 mpv 来剪切视频创建截图之类的第三方脚本应该都会触发这个问题

像kikoplay 这种调用多个 libmpv 的呢？它的进度条预览也是通过调用一个独立的 libmpv 实现的

只要用mpv.exe播放就会有，我觉得这也是正常的。他们调用mpv的方法，和直接在cmd里运行mpv没区别。

libmpv不会的，选项的默认设置是只有mpv播放器才会启用控件，libmpv默认是不启用的。

另外，我前面说的控件会导致卡死反而复现不出来了，应该只是意外。