TA的每日心情 | 慵懒 昨天 21:57 |
---|
签到天数: 270 天 [LV.8]以坛为家I
荣誉会员
- 积分
- 103175
|
本帖最后由 op200 于 2024-11-28 20:10 编辑
初章:初见端倪
今天在压视频的时候,发现一个离奇的现象
如图所示,边缘已经崩坏到无法形容
这张图是我用压制鸡压的,压制鸡内是 ffmpeg 7.0.2-full_build,其内置的 libx265 版本为 3.6+36-2cdd69a6d
而我使用主力鸡的 ffmpeg 7.1-full_build、x265 4.0+6-a069836f3
主力鸡没有出现这种情况,如下图
这是怎么一回事呢?
经过比对 x265 的参数,如下图
我发现仅有这两个参数有区别
- :: Intel Core i5 12500 6c12t
- frame-threads=3
- numa-pools=12
- :: Intel QXJE (12900K ES) 16c24t
- frame-threads=4
- 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,所以现在有两个可能性:
而有一个办法可以一石二鸟,直接测试出这两点的结论:
主力鸡的 12500 的核显就是 UHD 770,只要更改形参 device_id,即可用主力鸡的核显测试
结果令人大跌眼镜——还真是 UHD 770 干的
下集预告:
楼主是否能战胜核显bug?
拯救世界的,是弱不禁风的770核显,还是那张尘封已久的四朝矿神 5600xt?又或是那张从来没掉过驱动的 GTX770?
红绿蓝三家的终极决战就此拉开序幕…
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|