x264 10bit编码推广讨论

[upyzl]

视频画面非全屏并缩放至屏幕大小时，一些特殊动态效果定位出现问题（如妇联K-ON! NCOP中的“雪飘工作室”图标）。
而且这个字幕是设置为1920x1080的，在我笔记本上（1366x768）MPC的字幕无论边框宽度、阴影，或者是blur效果（如果有的话），都会被放大，我猜测是它将本来给1080p匹配的字体（除了字体本身的大小）给放在1366x768下输出了。而DirectVobSub则没有这些问题。
原因应该是DirectVobSub是在渲染器前端就把字幕给弄在视频里了，所以1080p的字幕和1080p的视频相匹配，再经过resize输出后，依然是原始的效果。而MPC-HC的VSFilter是和渲染器并行的，在渲染器的画面上再弄上去字幕，而这字幕的效果就直接决定于屏幕分辨率。如果视频是1080p，字幕是1080p，屏幕也是1080p，那全屏下的效果是正常的。

嗯，DirectVobSub渲染字幕到帧，MPC-HC内置则是渲染到窗口

[mawen1250]

我正在缓慢上传几张截图，说一下主要问题。
前2张是原本的1080p视频配上1920x1080的字幕，除了上面所说的分辨率问题，色彩也有区别，但具体是哪个色彩有问题我也不清楚，个人感觉MPC-HC的更正常一些。
后2张是把这个字幕随便放在一个720p的视频里，可以看出这时DirectVobSub把1920x1080的字幕渲染到720p的视频上也出现了问题，MPC-HC则是把1920x1080的字幕渲染到1366x768的窗口上。而且明显是MPC-HC的字幕更清楚，因为分辨率与屏幕匹配。

点击图片查看原图
1920x1080字幕，1920x1080视频，1920x1080屏幕，MPC-HC字幕，最正确的显示

1920x1080字幕，1920x1080视频，1920x1080屏幕，DirectVobSub字幕的图就不上了，2者除了颜色有区别，效果都是正常的。
1920x1080字幕，1920x1080视频，1366x768屏幕，MPC-HC字幕

1920x1080字幕，1920x1080视频，1366x768屏幕，DirectVobSub字幕

1920x1080字幕，1280x720视频，1366x768屏幕，MPC-HC字幕

1920x1080字幕，1280x720视频，1366x768屏幕，DirectVobSub字幕



总结以后，如果要正确显示字幕的样式，MPC-HC字幕需要字幕属性里的分辨率和最后输出的屏幕分辨率相同，DirectVobSub则是需要字幕属性里的分辨率和视频的分辨率相同，而且后者在视频分辨率与屏幕分辨率不同时，字幕也会做Resize，导致视觉效果变差，特别是upscale的情况。

关于颜色的问题，我猜测是DirectVobSub的字幕弄进视频帧用的YV12和RGB转换矩阵是BT.601，但是整个高清视频最后在渲染器里转换时用的是BT.709，所以导致颜色出错。我试了EVR和madVR都是一样。
所以我又试了一下ffdshow强制RGB32输出，配合EVR渲染器，这样DirectVobSub的字幕弄进视频帧就直接是RGB的了，渲染器中不需要再进行YV12和RGB的转换，实际截图也证明了这样的色彩和MPC-HC字幕是一样的。但是这种RGB32强制输出的方式目前是不适用于10bit视频的，所以总的来说能用MPC-HC的字幕就尽量用。

[4h4h270]

我使用10bit压制之后发现画面里的高光部分较源片更亮了,就像开了hdr效果,亮的挺不习惯的

[sunyata]

http://share.dmhy.org/topics/view/21824 ... -bits.html
出来了出来了，支持一下

--------
有两个问题
一是在妇联那边看到有提到x264 10bit转换颜色错误（http://flsnow.net/bbs/thread-28959-1-1.html，9楼），查了一下还就是几天前提出的，不知道这个问题有没有解决，还是说用顶楼脚本没有影响？
二是10bit下编码质量怎么看？我用顶楼的脚本crf21尝试压了一小段，输出的qp是39，33，37，有点搞不明白

[06_taro]

http://share.dmhy.org/topics/view/21824 ... -bits.html
出来了出来了，支持一下

--------
有两个问题
一是在妇联那边看到有提到x264 10bit转换颜色错误（http://flsnow.net/bbs/thread-28959-1-1.html，9楼），查了一下还就是几天前提出的，不知道这个问题有没有解决，还是说用顶楼脚本没有影响？
二是10bit下编码质量怎么看？我用顶楼的脚本crf21尝试压了一小段，输出的qp是39，33，37，有点搞不明白

1. 据说可能是madshi说的不对，x264的10bit的conversion本身没问题……没去做代码级的研究……
2. qp和质量没关系，如果要量化地看质量的话可以用--ssim

另外LAV Video本身确实直接支持10bit的csp直接输出，在mpc-hc里用madVR接LAV Video的输出，10bit 420看到的P010，10bit 444看到的是Y410，pin info也可以检验。但是如果接上了DirectVobSub，输出就变成了YUY2（444->422）或者YV12（420->420）。实际上这不是DirectVobSub自己做了downsample，而是因为DirectVobSub本身不支持P010/Y410的输入输出，LAV Video为了连接上它，直接解码成8bit的输出，在DirectVobSub内部仍然完全是8bit处理的。

以lav+madvr来播放10bit 444为例，简单地看一下流程：

不连接DirectVobSub时：

代码： 全选

filter：	lav		madvr
输入：		---		Y410
输出：		Y410		---

连接DirectVobSub时：

代码： 全选

filter：	lav	DVobSub	madvr
输入：		---	YUY2		YUY2
输出：		YUY2	YUY2		---

8bit444/10bit420时类似，对应的是AYUV->YUY2/P010->YV12而已。

所以综上所述，不加载DirectVobSub时可以做到10bit444数据无损从解码器到渲染器的连接，而加载DirectVobSub之后则是解码阉割到8bit~422的输出给字幕渲染，再把渲染好的阉货丢给madVR，必然是在处理中就损失了一次。

至于上面的挂字幕比较，实际上不管是DirectVobSub还是mpc-hc内置字幕组件，走YUV时渲染过程都是最高8bit 422的，不同之处则是DirectVobSub要把解码的视频和字幕混合渲染输出给video renderer，而mpc-hc内置字幕组件是不破坏解码与渲染器的连接，而是在最后与视频并行渲染。因此前者过程中对视频是有损失的，而后者过程中不降低视频质量，因此mpc-hc内置字幕组件对视频质量的保留应该更好。但是字幕本身的渲染结果上看现在做ass时特效一般都是以DirectVobSub为标准（虽然ass这东西基本上可以说没有标准……），mpc-hc因为渲染机制不一样所以不同之处往往不被特效保证。至于比较哪个的字幕色彩渲染是正确的，只能说如果渲染给10bit的显示器的话，上DirectVobSub和mpc-hc都是8bit->10bit的，所以现在字幕渲染没有原生的10bit渲染方式……

[sunyata]

1.如果没问题的话那敢情好
2.因为考虑到一般压片都开psy，用ssim心里没底……既然可以作为参考那我就放心了（刚想到可以关掉psy来测试……）
谢谢解答

[SAPikachu]

一是在妇联那边看到有提到x264 10bit转换颜色错误（http://flsnow.net/bbs/thread-28959-1-1.html，9楼），查了一下还就是几天前提出的，不知道这个问题有没有解决，还是说用顶楼脚本没有影响？

前几天研究过源代码，x264内部是故意转换成这样的（经过dither），注释是这样的：

/* this function mimics how swscale does upconversion. 8-bit is converted
* to 16-bit through left shifting the orginal value with 8 and then adding
* the original value to that. This effectively keeps the full color range
* while also being fast. for n-bit we basically do the same thing, but we
* discard the lower 16-n bits. */

不过我是不太明白这样做的意义。。。

[histamine]

能否这样解释

8bit下数值范围是0-255

16bit下数值范围是0-65535

如果采用左移8位转换，8bit下的255直接左移8位，那么就是65280
于是16bit下65281-65535这段就没有对应的8bit数值了？！

或者说如果采用左移8位转换，原先8bit下0-255的范围转换到16bit则是0-65280？！

[SAPikachu]

能否这样解释

8bit下数值范围是0-255

16bit下数值范围是0-65535

如果采用左移8位转换，8bit下的255直接左移8位，那么就是65280
于是16bit下65281-65535这段就没有对应的8bit数值了？！

或者说如果采用左移8位转换，原先8bit下0-255的范围转换到16bit则是0-65280？！

可能确实是这样，不过没有官方标准的话也很难说哪个公式是正确的吧

[histamine]

可能确实是这样，不过没有官方标准的话也很难说哪个公式是正确的吧

确实只能说，写这段代码的人可能是这样考虑的

不过按照BT.709标准的话，这样做似乎是错误的
片源本身就不是full range的

所幸的是如果使用dither系列工具输出16bit交给x264 10bit编码，似乎就不会产生这么大的误差
但是x264/filters/video/depth.c里面的dither算法需要改一下

如果对色彩不是很敏感，个人感觉还是别纠结这个问题了吧