替代：另一个进度条预览脚本 mpv-thumbPreview

[GFDGIT]

https://github.com/bun-dev/mpv-thumbPreview

这个脚本可以不生成bgra文件，而是直接显示内存中生成的bgra，可以解决频繁读写和占用硬盘的问题。不过，该脚本已经过时，在新版mpv中无法使用（生成bgra的命令过时了，修正即可），且有许多bug。

希望有能力的人可以修一修这个脚本，或者，将其直接使用内存存储预览图的功能移植到现有的脚本中。希望能实现悬浮鼠标时才在精确时间生成预览，并暂存在内存，关闭视频就释放内存，这样就可以节省CPU和硬盘了。

[hooke007]

之前讨论过，现有的两个脚本瓶颈在于解码太多不必要的帧导致了变态的cpu开销（而且暂存在内存就没法复用生成的缩略图了），存在哪里是次要的。我没看这个脚本，如果只解码目标时轴的帧，那可能有修复的价值

edit: 当前的 thumbfast 几乎全面优于旧有的缩略图方案

[GFDGIT]

对的，就是一次性生成预览消耗太大，但是上面的脚本也没有实现只生成目标时轴预览图的功能。。。不过，我用的6700hq测试了生成一个预览图的时间应该在0.5秒以内的，如果能实现的话，还是挺有实用价值的，生成bgra命令加硬解不知能不能更快。对于我个人而言，保存在内存就不需要定时去清理预览图，毕竟积累下来还是挺占空间的。

[GFDGIT]

如果能实现只解码目标时间点的预览，那不能复用预览图也不是问题了，毕竟寻找进度条的频率还是比较低的。而且，应该可以实现在一次使用中的复用，关闭mpv时再释放内存就好了。

[nyfair]

这脚本不生成bgra的原因只是因为它把bgra文件扔管道了，而ffmpeg/mpv都支持管道IO。由于管道随用随弃的特性，预览图成功显示的时候就已经被消费掉了，不会驻留在内存里，不存在能复用的空间

说实话反复的单帧解码效率太低了，如果真的觉得节省CPU和硬盘是刚需的话，建议向mpv的各种壳提需求，在全局层面实现比现在脚本的方式容易得多，毕竟播放本身已经解码一遍了

当然如果只想充分利用内存不写硬盘的话，其实可以考虑操作系统级别的实现，创建rgba的时候标注下这个文件只驻留内存，windows下塞个attribute T，unix下用tmpfs。或者更傻瓜一点，不用改脚本直接装个ramdisk

[GFDGIT]

实际上通过管道输出bgra后，将其复制到了thumbs = { data {}, addr {} }

所以，预览图实际是保存在lua脚本进程的内存中的，在一次使用中是可以复用的，当然关闭mpv后再开就需要重新生成了。

另外，其他使用libmpv的播放器应该也只能用子进程去生成预览图，因为mpv本身并没有提供这个功能，所以效率上和脚本是一样的。

[nyfair]

直接走ffmpeg的libavcodec啊，甚至可以精确到每个关键帧生成缩略图

[GFDGIT]

这不是问题的关键吧，生成每个关键帧预览没有意义啊，况且用ffmepg生成预览不见得会更快吧

[nyfair]

现在cpu开销大根本原因就是大量命令行调用生成单帧截图，不谈解码，光初始化的开销就一坨了。换到libavcodec的底层context，av_seek_frame/ av_read_frame 俩api单线程绕一圈就完事了

[GFDGIT]

我好几次想重写这个脚本，无奈能力不够，只是改正了输出bgra的命令，基本能够正常使用，其他bug无力解决。

关键的一点是，我没搞懂怎么获取鼠标悬浮位置的时间点，去看OSC的实现，完全看不懂，如果mpv有鼠标seeking的相关函数就好了。