核显调用OpenCL导致严重恶性画面bug (未完待续)

初章：初见端倪


今天在压视频的时候，发现一个离奇的现象



如图所示，边缘已经崩坏到无法形容

这张图是我用压制鸡压的，压制鸡内是 ffmpeg 7.0.2-full_build，其内置的 libx265 版本为 3.6+36-2cdd69a6d

而我使用主力鸡的 ffmpeg 7.1-full_build、x265 4.0+6-a069836f3

主力鸡没有出现这种情况，如下图



这是怎么一回事呢？

经过比对 x265 的参数，如下图



我发现仅有这两个参数有区别

1. :: Intel Core i5 12500 6c12t
   
2. frame-threads=3
   
3. numa-pools=12
   
4. 
   
5. :: Intel QXJE (12900K ES) 16c24t
   
6. frame-threads=4
   
7. numa-pools=24

复制代码

因为线程类参数会随着CPU线程数改变，所以我将压制鸡的参数调为 frame-threads=3 numa-pools=12，画面bug消失了，且即使 frame-threads=4 numa-pools=12 依旧不存在画面bug

所以到这里就告一段落了吗？仅仅是因为 numa-pools 导致的吗？事情似乎并没有这么简单

我将压制鸡的 ffmpeg 换成 7.1，也就是说把 x265 换成 4.0+6，继续进行测试

似乎是因为 x265 的根据线程自动调参的算法没变，参数依旧是 frame-threads=4 numa-pools=24，但神奇的是画面bug荡然无存

我又想到这个根据线程自动调参的算法是不是 3.6 版本修改，发现有bug后在新版本修正，于是我又去测试了下更老的版本

ffmpeg 6.1 x265 3.5+111 frame-threads=4 numa-pools=24

看来根据线程自动调参的算法一直是这样，再看画面，没有任何问题



幕间一：大事不妙

隔了半天，我看了下4.0压出来的整个成品，某些画面没有了这个bug，但大部分画面依旧存在这个bug，感觉这又跟源有关系，因为之前压的番没看到这个bug，只有这个番存在这个问题，而且非常明显

目前仅知道调整 numa-pools 能解决这个问题，后面测试出其他结论我会接着修改文章



第二章：最好笑的一集

经过我再再再次繁杂但不严谨的测试，我总算是排除了编码器的bug

这次，我将bug锁定在了一个vapoursynth的滤镜上——knlm.KNLMeansCL

为什么我之前测试了一两个小时都没有怀疑过滤镜呢？
那是因为我的vpy脚本是在主力鸡上编写的，而主力鸡上运行的预览画面完全没问题；
再加上压制鸡使用高 numa-pools 时这个bug会加重（也可能是x265把瑕疵糊掉了导致我误判，现在再测x265没意义了，我就不测这个了）；
更离奇的是，我前天刚刚用这个滤镜压制了另一部番，那部番完全没有出现这个问题（没出问题的原因是我用了强度很高的边缘蒙版，把所有纹理全部盖住了），导致我知道最后才怀疑到滤镜头上；

当我总结了这些规律之后，我直接把bug锁定在显卡驱动上，我满怀希望地装上新驱动，重新启动，结果依旧，希望破灭；
但这并不能证明不是显卡的问题，因为压制鸡的使用的是仅有的核显 UHD 770 调用 OpenCL，而主力鸡使用的是 Arc 750，所以现在有两个可能性：

• UHD 770 干的
• ES 干的
  

而有一个办法可以一石二鸟，直接测试出这两点的结论：
主力鸡的 12500 的核显就是 UHD 770，只要更改形参 device_id，即可用主力鸡的核显测试

结果令人大跌眼镜——还真是 UHD 770 干的



下集预告：
楼主是否能战胜核显bug？
拯救世界的，是弱不禁风的770核显，还是那张尘封已久的四朝矿神 5600xt？又或是那张从来没掉过驱动的 GTX770？
红绿蓝三家的终极决战就此拉开序幕…

没啥稀奇的，知道 3.6+36 什么意思么？

在 x265 发布了 3.6 版本的基础上，又额外提交了 36 个新 commit，但还没有提升版本号到 4.0，所以你在用的不是正式版，而是某个开发分支，随时都会坏，也随时都能修。

另外从签名的得知你的 ffmpeg 中的 x265 包含了非官方的补丁，最后一次提交的 hash 在官方仓库里找不到。
https://bitbucket.org/multicoreware/x265_git/commits/2cdd69a6d
https://bitbucket.org/multicoreware/x265_git/commits/a069836f3

nyanmisaka 发表于 2024-11-28 16:29
没啥稀奇的，知道 3.6+36 什么意思么？

在 x265 发布了 3.6 版本的基础上，又额外提交了 36 个新 commit， ...

我刚才看了下整个成品，发现大概率所有版本都存在这个bug，只是新版中某些画面中没有了这个bug，看来只能调 numa-pools 了

编码器这玩意也没啥大影响的 commit 基本上用新版不会有问题

编码没那么容易出恶性bug，你看果然是输入就炸了

fzz 发表于 2024-11-28 20:19
编码没那么容易出恶性bug，你看果然是输入就炸了

确实，对vs太放心导致的（

喷了。。结果是OpenCL滤镜就错了。

这玩意不如CUDA的一点就是，它在各个厂商的驱动上跑结果能不一样，必须自己调试。

。。。

https://github.com/search?q=repo ... -math&type=code

看来作者开了不少编译器优化选项，比如“-cl-denorms-are-zero -cl-fast-relaxed-math”，这些非常规参数很容易导致问题。

KNLMeansCL在amd显卡上坏了很久了，预测gtx770赢。
建议考虑一下用cpu版本nlm-ispc

KNLMeansCL 在apple soc上也是坏的（

这玩意根本不好使

yuygfgg 发表于 2024-11-29 10:01
KNLMeansCL 在apple soc上也是坏的（

这玩意根本不好使

我感觉效果挺好的，再加上没找到其他好用的滤镜，就一直用的这个（

顺带一提，这玩意的时域降噪（形参 a）开了之后会有残影，而且默认参数就是开的（a=1），过于抽象

我现在基本用的bm3dcuda (其实没有cuda,用的cpu版)；要是噪点太严重就用dpir；nlm速度不快（比bm3d快一倍左右，但是两者都挺快的），效果还差


残影时域降噪都会有点吧 特别是MVTools那一派的会比nlm更明显...不过我也不太懂（