嗯，DirectVobSub渲染字幕到帧，MPC-HC内置则是渲染到窗口mawen1250 写了：视频画面非全屏并缩放至屏幕大小时，一些特殊动态效果定位出现问题（如妇联K-ON! NCOP中的“雪飘工作室”图标）。
而且这个字幕是设置为1920x1080的，在我笔记本上（1366x768）MPC的字幕无论边框宽度、阴影，或者是blur效果（如果有的话），都会被放大，我猜测是它将本来给1080p匹配的字体（除了字体本身的大小）给放在1366x768下输出了。而DirectVobSub则没有这些问题。
原因应该是DirectVobSub是在渲染器前端就把字幕给弄在视频里了，所以1080p的字幕和1080p的视频相匹配，再经过resize输出后，依然是原始的效果。而MPC-HC的VSFilter是和渲染器并行的，在渲染器的画面上再弄上去字幕，而这字幕的效果就直接决定于屏幕分辨率。如果视频是1080p，字幕是1080p，屏幕也是1080p，那全屏下的效果是正常的。
1. 据说可能是madshi说的不对，x264的10bit的conversion本身没问题……没去做代码级的研究……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，有点搞不明白
代码： 全选
filter： lav madvr
输入： --- Y410
输出： Y410 ---代码： 全选
filter： lav DVobSub madvr
输入： --- YUY2 YUY2
输出： YUY2 YUY2 ---前几天研究过源代码，x264内部是故意转换成这样的（经过dither），注释是这样的：sunyata 写了：
一是在妇联那边看到有提到x264 10bit转换颜色错误（http://flsnow.net/bbs/thread-28959-1-1.html，9楼），查了一下还就是几天前提出的，不知道这个问题有没有解决，还是说用顶楼脚本没有影响？
不过我是不太明白这样做的意义。。。/* 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 写了：可能确实是这样，不过没有官方标准的话也很难说哪个公式是正确的吧