又来折腾这玩意了。其实之前的方案完全正常啦，但是最近组了个新电脑没买显卡，本来以为反正自己也不玩游戏够用了，没想到居然用MadVR随便播个东西就GPU占用100%：

直接卡到12fps！把所有的缩放算法全部改成最低端的Cubic也只能勉强到50多fps（显示器是75的），看来是没得救了。那让我们找个替代品吧。

面临的问题

如果有读过前文和前前文就应该知道，之所以用MadVR并不是我对画质有什么极致的追求，而是在很多基础的东西譬如10bit抖8、格式转换等上PotPlayer是非常的差，MadVR恰好可以简单地修正这些问题罢了。

具体系统性的细节就不再赘述，如果需要可以复习前面两篇文章。这里直接说我们要解决哪些问题。

其实对于最常见的，4:2:0、limited range、8bit的视频，PotPlayer开箱的默认配置也不是完全不能用。但是有以下三个特例需要处理：

1. 10bit视频——显示器是8bit的，所以10需要抖到8，无抖动大量banding。10bit视频现在已经非常常见了，动画民间压制组几乎全都是用HEVC 10bit出片。所以这个dithering是必须要有的，否则白瞎了。
2. full range视频——商业发行的影音产品不算太常见，但是直播等非常常见。
3. 非4:2:0视频（例如4:2:2、4:4:4视频）——更少见，除了某些民间压制组会用，其他基本见不到。

例如，Pot默认的用EVR (Custom Preset) （下面简称EVR）这个渲染器的最大问题就是不能正常显示full range视频。无论用软解硬解还是外置LAV都不行：

所以我们直接pass。

另外，一个thumb rule是所有转换都应该只做必要的转换，比如如果本来是422，那就不要劣化成420再转RGB；本来是8bit也别转10bit，反之亦然。

PotPlayer近年来的改进以及10bit输出

在最早那篇文章提过，PotPlayer当年最大的问题是他内部默认使用YUY2这个4:2:2的格式来处理，所以常见的8bit 4:2:0格式会被Pot拉伸一次，而且默认还是极差的NN算法。现在，Pot修复了这个问题，基本正常情况都会用NV12、YV12之类的格式通到渲染器。单这一点就把其播放一般普通视频的画质提升了一个量级，完全达到了能用的水平。所以如果没有特殊需求（下述），这两个之前提过的选项可以用Auto不用动了：

不过为了以防万一，还是把下面的高质量也给勾上吧。

另外，在输出方面增加了10bit的输出的选项：

开启10bit输出后会尽量在解码器端输出为10bit，然后到renderer会转成A2RBGB10之类的10bit RGB格式。但是因为我显示器只有8bit，最后还是会banding成8bit（且和P010这类10bit YCbCr格式直接转RGBA的banding还不太一样）。这里自然不开启。而且这个10bit输出还有一些bug：

• 用EVR，会发生奇怪的颜色反转。蓝色变成黄色
• 用D3D9 native 解码再输出到D3D9 renderer，会出现一个奇怪的绿条在下面：

最糟糕的问题其实是8bit的视频会被拉成10bit（然后最后在display层面再降回去）——据我观察D3D11 renderer即使这样折腾一次也问题不大，但是D3D9 renderer整个画面会变得超级糊，一定要避免。

处理10bit视频

这里先明确几个前提：我们只追求抖动的有无，质量不关键。另外我是8bit屏幕，所以一定要10转8；如果是用的原生10bit，则自行保证最后renderer是10bit输出即可。

这个转换，可以在编码器阶段进行，也可以在renderer阶段进行。之前用MadVR的时候就是在renderer阶段进行，所以一定要把解码后的视频保持10bit的格式（一般为P010）输送到renderer。

不过现在不用MadVR了，我们应该在哪里进行效果好呢？经过一些基本的测试，结论如下：

首先，如果在硬解native里进行10转8，是没有dithering的，效果很差。

如果用LAV调用硬解，我测试中是发现用DXVA2 native或者 D3D11都会banding，DXVA2 copy-back和软解则无问题：

测试时强制了LAV用RGB输出，这样保证不会在接下来的任何步骤再修改。LAV自己的10转8是有dithering的。我的理解是，用了DXVA2和D3D11 native的话，LAV就完全放手了让他们来输出为NV12之类的的格式，自己仅负责转换为RGB的样子。

240105更新：上面的DXVA的测试结果仅限于 Intel CPU 带的 iGPU；我使用N卡测试时，即使使用native也是自带dithering的！

如果用Pot内置解码测试，默认是用D3D9，只有用D3D11的renderer的时候才会用D3D11的解码，不过可以手动修改。也可以用D3D9 copy-back和D3D11 copy-back。搭配MadVR的时候，这里无论选哪个都是可以直出P010的，也是我之前一直用的。顺便一提，我在这台电脑上用D3D9 native + madVR播放full range视频，会出一个很奇妙的问题：

可以看到色域虽然没有错误伸张、压缩，但是16/235外的被clip掉了。然而我用我的笔记本无法复现。不过无伤大雅，改成copy-back或者D3D11即可。

回到正题。既然我们不能用MadVR，我们可以用默认的EVR、D3D9 renderer或者D3D11的renderer。使用硬解的时候，基本都会直出10bit的P010给renderer。但是凡是在上述三个renderer里发生P010转RGBA（即10转8），也都会banding。开启10bit输出虽然可以正常转成RGB10，但是最后在display层也会转到8bit所以也是同理。一言以蔽之，不要在非MadVR之外的renderer这一层来进行10转8，因为没有dithering。

所以，如果要用LAV内置解码器，就一定要用软解或者硬解copy-back（copy-back的硬解基本在实践上和软解区别不大，应该也是用了ffmpeg来处理）来输出NV12，然后renderer直接转RGB就完事儿了。Pot默认设置不开硬解其实就是这样的。注意一点就是如果你开启了direct conversion (change default output color space) 这个选项的话，可能又变回P010输出坏事儿。

另外一个小细节：不能选D3D11 native解码+D3D9渲染。会强制给你改成D3D9。反之则可以。

总结一下：

• 硬解直接10转8输出：banding
• 无论软解硬解如果输出10bit，渲染器里10转8：banding
• 所以要用：软件解码器或者硬解copy-back来完成10转8的过程。

软解的选择可以用Pot内置（即FFmpeg）、LAV（可以手选dithering的方式）。记住，Pot默认强制HEVC用硬解，即使不勾“Use DXVA”也是。可以通过修改这里为FFmpeg.dll来强行取消：

FFmpeg根据我的观察应该是用的ordered dithering。

这里来比较一下。先来一张banding的（所有的截图都是1080p片源1440p播放，然后截图后调整曲线来增加对比度，最后再NN放大到3x）：

再比较一下dithering：

可以很明显看到两种dithering的区别。观感上来说其实都差不多，不过还是用random吧。中间的则是对比用的MadVR——MadVR dithering最好的地方在于他工作在全分辨率（也就是1440p），所以pattern极其小，可以说100%时肉眼完全看不出任何颗粒感。别的都是先生成dithering、然后再被放大，那自然效果远不如。不过，看片的时候还是OK的。

至于渲染器的选择在这里不影响，我们都是8bit输出了反正。

视频resize的表现

确定了10bit没问题，我们再回来看看经典8bit视频resize的效果。这里有点出乎我的意料：无论是用D3D默认的DXVA Video Processor，还是D3D11带的D3D11 Video Processor（Pot里选成Auto就好），效果都出奇的好，可以和说我MadVR拉满不相上下！

我的理论是，他这个不知道用了什么Intel的劳什子视频后处理科技，估计是在全屏分辨率级别搞了点锐化之类的？无论如何，至少看高锐度的东西效果很好，清晰，也没有太明显的ringing，远强于Cubic之类的了。我们尽量选用能调用Video Processor来resize的方案。顺便一提，EVR默认也是调用DXVA Video Processor来当resizer。

Full range、422/444视频

Full range视频不出意外地都没有问题，甚至EVR (Vista/.NET3)那个都没问题——只要别用EVR custom preset那个。

422/444视频则比较tricky。理想情况，当然是422就全程用YUY2，444就全程AYUV，不要出现被转化为420格式再喂给渲染器的现象，自降分辨率是大忌。

但是现实很骨感，这里面有好几个局限性：

• Renderer只能接受部分格式输入
• 某些格式用LAV+开启Pot转换滤镜时，Pot不收（虽然用内置的可以）
• Pot的自动格式选择非常的弱

让我们先来个一览表：

这里面绿色是我们想要的，黄色的是非最佳的，红色的是无法接受的。这里面第三列就是前面提过那个开关：所谓的“direct conversion (auto change color space)”是开还是关。

简单概括下：如上面说的第三点，Pot如果把输出设为Auto，其实基本就是只会用NV12/YV12这种8bit/420的格式。唯一的例外是用硬解native的时候，会直通P010（10bit 420）到renderer（但是我们已经说过我们不想这样，因为非MadVR的renderer没有dithering）。所以，这样下来面对422/444的视频，都会被Pot给降低到420，bad。

这个问题可以通过这个开关来改善——开了之后，对于EVR，解码器会自动改用422和444的输出，对于D3D9，至少能修复422（但是444会crash）。D3D11则比较怪，即使开了开关，还是只能被喂420（或者RGB）；我稍微查了下应该是支持至少422才对，可能是Pot的implementation有问题吧。

但是这个开关也有个副作用，就是用内置解码器的时候，会把10bit本来我们想要的8bit输出（抖动后）也给变成了10bit直通。

如果是用LAV，就很容易解决这个问题，LAV里把10bit的格式全部去掉，自然就只可能输出抖动后的8bit。

（这里有个疑似BUG：Pot的转换滤镜开启时，它并不收来自LAV的P010，如果你强制在LAV那边只勾选P010，Pot会直接强制自行关闭转换滤镜……嘛，纯粹是好奇罢了，毕竟我们的目的恰恰是LAV不要用10bit输出。）

另外，使用“LAV+EVR (Custom Present)+开启auto coloir space开关”这个组合时，除了会有前面多次提过的full range色域错误的问题（未伸张，即0变成16），另外播放444视频时，会出现色域过度伸张的错误（即16变成0）。

但是如果把渲染器换成EVR (Vista/.net3)，看表格里似乎完美？

很可惜，EVR (Vista/.NET3)有个更阴间的BUG……字母某些特效会变成这鸟样（请无视我没安装字体。下面是对比用的EVR (CP)）：

结语

既然没有一个完美方案，我们只能两害取其轻了。我最后采用的是内置软件解码器+D3D11渲染器+不开auto色域转换开关的方案（换成D3D9渲染器也行）。这样只有422、444不能完美播放（但是也不至于不能播放），而我除了我自己造的测试视频其实根本没下过这种视频w。我还检查了下BT601的视频，也是没问题的。

哦，其实还有个方案就是上面提过的LAV+强制RGB输出的方案。可以一揽子规避所有转换的坑。但是，这样就没法享受到高质量的DXVA/D3D11 Video Processor做resizer，所以还是算了。

20230520补记

最近碰到一个视频是 SMPTE 240M 的matrix，发现用D3D9的 renderer 有问题，D3D11的OK（和MPV的效果一致），所以虽然都行还是推荐用D3D11。

另外，我发现我上面明明还有一个全绿的组合：使用LAV+D3D9渲染器+开启auto coloir space开关，但是我为啥没使用？我自己也忘了，大概还是为了尽量不用外部滤镜来让截图不偏差吧。