自从前一段发现PotPlayer播放10bit视频惨到不行的banding问题之后（目测是直接把10bit砍到8bit，没有使用正确的抖动，甚至连设置的地方都没有！），就换用了LAVfilters来作为主力滤镜。既然都换了LAV，顺便也把EVR换成了MVR——因为我发现我之前一直无法忍受MVR的一点，全屏和窗口化切换会卡一下的问题现在没有了（即使是非exclusive模式）——不过这是后话。
但是，PotPlayer调用外部滤镜的兼容性实在是惨不忍睹，其实这也是我之前为啥一直坚持使用内置滤镜的原因。短短用了这半个月，遇到过的问题就包括但不限于某些视频直接无法播放freeze、拖动进度条卡顿、PotPlayer.dll报错崩掉等等。无奈之下，我尝试了下升级到最新dev版，结果发现更可怕了，比如之前我发现banding的那个[LoliHouse] A.I.C.O.用LAV直接无法播放（稳定版没问题，已经报错到论坛 了）。
PotPlayer的转换滤镜
我后来发现，在依然使用LAV的前提下，如果开启PotPlayer的所谓“转换”（transform）滤镜，则可以大幅度缓解不兼容的各种问题。上述的那个视频可以正常播放了没问题，崩溃的次数也大幅减少。另外，这个滤镜是PotPlayer用来实现PotPlayer内置的一些功能的，所以只有开启之后一些功能（比如视频调色，虽然我从来不用就是了）才能正常工作，而且不开启的情况下还会有截图错帧的问题。
当然，这个功能之所以之前我选择不开启，是因为它是有不少副作用的。其最大的问题就是在不同Pixel format之间转换会有很大的精度和算法问题。Pixel format就是形如NV12、YUY2、RGB24等等各类色彩的数据存储格式——包括但不限于colorspace、位深、通道数、通道混合方式等。对于YUV色彩空间的几种常见的格式VLC的wiki有篇详尽的文章 可以参考，这里不再赘述。
要谈论transform的对pixel format转换的影响，得先说说如果不用它，直接LAV输出到渲染器是怎样的一个流程。例如最常见的YUV 4:2:0（YUV色彩空间，纵向横向均有2:1的色度抽样）的8 bit视频（注意：俗称的8 bit、10 bit指的是单通道。实际上，对于YUV 4:2:0，每个pixel平摊下来有一个Y通道像素+1/4个U通道像素和1/4个V通道像素，所以一共有8+2+2=12bit）在LAV勾选默认所有输出方式（除了AYUV）的情况下，会用NV12输出给渲染器。这里罗列一下常见的几种格式都会是怎样：
原始格式
LAV输出格式
YUV 4:2:0 8 bit
NV12
YUV 4:4:4 8 bit
YV24
YUV 4:2:0 10 bit
P010
可以看到，LAV自动选用的位深和色度抽样都是和原来一样的，不会进行多余的操作。
顺便一提，如果细心看，会发现LAV会输出2048×1080，而不是1920，这是因为使用了叫做Image stride 的技巧，把图像尺寸填充到2的整数幂来加快GPU运算。LAV作者的原帖见此 。
YUV 4:2:0 8 bit视频
现在来看看如果开启PotPlayer的转换滤镜，会发生什么。还是先看看最常见的YUV 4:2:0 8 bit格式：
从OCD信息可以看出，LAV依然输出的是NV12（这里写“Input”，因为是相对Pot的转换滤镜而言），不过经过了转换滤镜之后就变成了YUY2这个4:2:2（水平有色度抽样，纵向没有）的格式——也就是说Pot自作多情地把U、V通道给upscale了一倍。很显然，我们是希望所有的upscaling工作全部在MadVR进行，因为其拥有最优秀的算法；Pot的算法？已经不能用“一般”来形容了——事实上可以看出，他根本就是用的nearest neighbor（截图均为200%缩放，下同）：
Pot转换滤镜，默认（YUY2）输出 转换滤镜禁用，LAV直出MVR 这个结果显然是无法接受的，那么怎么能拯救一下呢？PotPlayer相关的选项有这些：
这里我们主要可以调整的是三个：一个是输出格式（Output color space），一个是所谓的“直接转换”（Direct conversion），一个是下面那个高质量（High quality YUY2/RGB24/32 conversion）选项。
首先想到的自然是勾选那个high quality选项了。勾选之后，PotPlayer会用比NN高级那么一点的算法，结果如下：
Pot转换滤镜，默认（YUY2）输出+HQ 比上面那个锯齿到爆的自然是好多了，但是理想情况下我们还是希望能让MVR来处理，所以我们还可以选成强制NV12输出（注意，非YUY2输出的话那个HQ选项勾选与否没有任何区别）：
Pot转换滤镜，NV12输出 这里可能几乎看不出区别，不过如果放再大点可以看出这个会比上面那个稍微锐化那么一点。另外很奇怪的是，即使是选成NV12输出，结果也和直接禁用转换滤镜（LAV用NV12直传MVR）不是逐像素相等，我初步怀疑是截图的帧数不同（虽然这是我拿静止图片做的视频，但是毕竟是有损压缩每一帧还是略有区别的）导致的，也有可能Pot的转换滤镜还干了其他什么，但是无论如何，这个区别是肉眼完全没有可能区分 的了。
哦其实还有个直接转换的选项——有啥用呢？具体原理不明，不知道所谓的“直接”是指什么，但是选了之后YUY2（默认）会变成“Direct YUY2”，NV12会变成“Direct NV12”，其中前者结果和默认+HQ 一样，后者和NV12一样，所以感觉意义不大。
你当然也可以选成那些4:4:4的格式来输出（而且不用勾选HQ选项，自动会使用比NN强的算法），来获得能接受的结果，但是这样完全是把MadVRupscaling的工作给做了，自然不是我们想要的。
值得一提的是RGB输出的选项……首先RGB24+HQ选项=直接崩溃，是很彻底那种，连用Pot内置滤镜解码都崩（啥时候抽空汇报一下）。RGB32+HQ倒是不会崩溃，但是这下不但U/V的upscaling、连YUV->RGB都在Pot做了，不是很让人放心。不过也算有个优点：PotPlayer至少可以手动改Color matrix，放到MadVR或者LAV里做的话全靠自动判断了，如果有什么文件的元数据不对，没办法纠正。
题外话，RGB32比起24是多了8位的Alpha通道这点没错，但是绝大部分情况，alpha通道是根本不会使用的。那为啥会用32？其实是因为可以在x86（32位机）下做到下完全对齐，这会显著影响到内存和运算单元的速度。参见[1] 、[2] 。
关于Color matrix
嗯这里得插播一段。上图中出现的那个视频其实是我当初研究浏览器色偏问题时，自己拿一张RGB图片用ffmpeg做的。当时用的命令很简单就是：
ffmpeg -loop 1 -i colortest_hd.bmp -c:v libx264 -t 30 -pix_fmt yuv420p out.mp4
出来之后至少0,0,0、16,16,16、235,235,235、255,255,255等几个灰色很准所以我一直没注意过。知道今天才偶然发现，我在里面用的纯红色文字，也就是255,0,0的，显示出来居然是255,25,0！
究其原因，原来用ffmpeg将RGB的图转换成YUV视频时，默认是使用的Rec. 601 的转换矩阵。但是，如果不手动指定，是不会把转换矩阵写入元数据的。而由于生成的视频是HD的，会默认为Rec. 709的矩阵，所以最后渲染回RGB的时候，就出现了色偏。
解决这个问题可以这么写：
ffmpeg -loop 1 -i colortest_hd.bmp -vf scale=out_color_matrix=bt709 -color_primaries 1 -color_trc 1 -colorspace 1 -t 30 -pix_fmt yuv420p out2.mp4
其中-vf scale=out_color_matrix=bt709部分是把图片转换成BT.709（Rec. 709的另外一个名称），后面的-color_primaries 1 -color_trc 1 -colorspace 1的是在元数据里标注。当然，如上所述，如果是HD视频可以略去不写。
也可以选择保留BT.601，但是就要显式声明了：
-color_primaries smpte170m -color_trc smpte170m -colorspace smpte170m
（NTSC和PAL还略有不同，参见此文 。另外不推荐这种做法。有的滤镜/渲染器根本无视元数据。HD视频还是老老实实用BT.709就好。）
除了-vf scale，似乎还可以用-vf colormatrix=bt601:bt709，不知道有没有本质区别。几个讨论可以参见这帖 和这帖 。
在测试过程中我又 发现PotPlayer一个BUG：
LAV输入NV12+转换滤镜+RGB输出（RGB24/32+MVR或RGB32+EVR）+Auto color matrix的情况下，永远使用Rec. 601。不但不会自动识别HD视频，连有显式Ret. 709的tag都不行。所以Pot转换滤镜RGB输出这条心还是死了吧。
YUV 4:2:0 10 bit视频
一般的8 bit视频还是比较容易找到一个靠谱的方案，我们再来看看10 bit。和8 bit相比，主要的问题在于，Pot这个transform滤镜能接受的输入很少[主要包括：NV12/YV12、YUY2/UYVY、RGB32，基本和EVR能接受的输入差不多。不支持任何10 bit及其以上或者4:4:4的YUV的格式]。前面提到LAV一般是直出P010给MadVR，而transform滤镜恰恰不接受这个输入。所以，默认情况下，LAV会选择抖动降低8bit然后NV12输出给转换滤镜。
这之后的流程自然和上面就一样了，Pot这边也选择NV12输出的话，无非就是把10->8转换的步骤从MAR变到了LAV，两者的dither质量都OK（虽然MVR的选项更多）。
YUV 4:4:4视频
其实这个没什么测试的意义，因为你99%根本不会见到这类视频，纯粹是为了蛋疼。而且这个的毛病可就太多了：首先，PotPlayer也不接受YV24输入，所以LAV会直接转换好RGB32送过来。接下来怎么办？显然不能再用NV12或者默认的YUY2了，我们本来明明没有任何色度抽样的，不能自降质量。最简单的就是这边也设成RGB32输出——由于无色度抽样完全不牵扯到resizing，所以这样的结果和LAV YV24直出MVR完全没有区别，锐度满分。不过兼容性还是有点，经常视频如果不重头开始播放就会出现这种屌炸天的现象：
如果你手贱一定要用NV12输出，也就是让转换滤镜从RGB32转换成NV12，那么除了显而易见的视频会变模糊以外（你自己引入了色度抽样），PotPlayer还会莫名地引入color range压缩的问题（最后出来的视频是16-235的）。而且我LAV那边无论是设成输出full还是limited的RGB都不行，PotPlayer一定会搞糟。结合MVR的OSD，我们来猜测下发生了什么：
如果LAV输出full的RGB：
Pot将full的RGB转换成limited的YUV，但是不修改stream的信息，所以MVR会认为还是full，不伸张，导致最后输出limited RGB；
如果LAV输出limited的RGB：
Pot根本不知道还有Limited的RGB一说，当成full来用又再压缩一次变成double limited的YUV；stream信息依然不修改（limited），所以MVR那边会伸张一次，但是结果依然是limited的。
你倒是可以在Pot这边手动修改YCbCr的color range为full来修复，但是这样你如果用Pot做YUV→RGB转换又要遭重… 嗯，前面提到过的Pot只用Rec. 601的color matrix问题在反向的RGB→YUV也存在。总之，就是Pot对上流的metadata的识别能力非常弱智，或者说根本不读取的。
不过，就在我无计可施的时候，我发现之前提到过的Direct conversion选项能用上！如果选成“Enable: change default output color space”，即使上的么color space选的是NV12（或者Auto），那么当输入时RGB32的时候也会自动触发“Direct RGB32”，完美规避了各种色彩空间转换的BUG！试了下4:4:2的视频，结果也是一样喜人。
结论
一言以蔽之，要避免让Pot的transform滤镜干任何事（……），我们用他的唯一目的就是防止PotPlayer崩溃。由于它夹在LAV和MVR中间，所以最简单的办法就是把10bit->8bit交给LAV，把色彩空间转换和resizing交给MVR。因此，对于99%的4:2:0视频，把PotPlayer的输出选成NV12即可——反正转换滤镜不支持10 bit输入，LAV那边也会先dither到NV12的。之所以要手动设一下而不用默认的Auto，是因为Pot默认会自作主张upscale到YUY2。对于高于4:2:0的视频，通过把Direct conversion设为Enable: change default output color space，会自动复制输入的格式（YUY2或者RGB32），依然完美规避转换问题。
Lav那边不需要做任何调整，默认输出全勾的状态就OK。
补记
呃我都忘了补记一下了，我后来发现如果开启了Direct conversion，部分视频（还不少…）会直接崩掉Pot。所以这个选项暂时改回去了，反正非4:2:0的视频实践中基本没有。
