『漫游』酷论坛>『影音数码技术学习交流』>[原创]火星发现：VMR9 ..
[原创]火星发现：VMR9吃错药，YUV转RGB有严重问题！
techneek@2007-02-28 20:37
试验是这样的~
这是一张包含0，16，235，255这4个灰阶的图片：
用下面的代码，生成视频：
引用
imagesource("level.png")
trim(0,120)
ConvertToYV12(matrix="pc.601")
代码中的这句话 ConvertToYV12(matrix="pc.601") 意思是在RGB转YUV的过程中，不要做luma和chroma的scale，也就是继续保持0-255的动态范围。
生成后的图像：
可见16和235的灰阶都丢失了。这是很正常的情况，因为正常来讲RGB转到YUV会做一次动态范围压缩（也就是常说的PC level到TV level），而YUV转RGB会再做一次动态提范围扩展。但是这里在RGB转YUV处理时未作动态范围压缩，但是解码器不知道，解码器解码时做YUV转RGB的时候还是会把16-235扩展至0-255，所以原来的0和16就都变成了0，原来的235和255就都变成了255（细看是253和255，这应该量化误差），注意这里负责做YUV到RGB转换的是color space converter。
下图的graph可以说明这一点：
然后把这个视频以YV12送进Xvid压一下，Xvid解码输出强制YV12。这里需要注意的是，Xvid从编码到解码，全程保持YV12处理，不存在色彩空间转换，也不存在level-scale。所以，YUV范围得以保留0-255。
看一下Xvid解码的graph图，该图表明，YV12被直接送进视频渲染器也就是VMR9，YUV转RGB由VMR9负责。
接下来让我们看看VMR9干了什么：
呵呵，看不见的灰阶又能看见了！
VMR9本来在YUV转RGB的过程中应该做16-235扩展到0-255的转换，但是很明显这里VMR9没有这样做。
qyqgpower@2007-02-28 20:56
VMR9向来这样，不然也不会存在RGB32输出可以得到PC Scale画面而YV12输出就成了TV Scale的毛病了
如果你说这是bug，那么Vista中全新编写的Enhanced Video Renderer也是这么处理YUV系的色空间的，微软的人是不是都吃错药了？
techneek@2007-02-28 22:31
引用
最初由 qyqgpower 发布
VMR9向来这样，不然也不会存在RGB32输出可以得到PC Scale画面而YV12输出就成了TV Scale的毛病了
如果你说这是bug，那么Vista中全新编写的Enhanced Video Renderer也是这么处理YUV系的色空间的，微软的人是不是都吃错药了？
是不是bug，是不是吃错药都无所谓。
重要的是，这么做究竟有什么意义~
至少从现在来看，如果decoder直接喂YUV数据给VMR9，那么如果decoder不做相应补偿的话，出来的颜色肯定是错的~
那么微软执意这么做的意义何在？你能解释清楚吗？
就拿Xvid来说，VMR的做法直接导致Xvid必须强制RGB输出，这么做显然会降低效率，特别是在播放HDRE的时候，CPU的负荷会增加很多。
CoreAVC解码264的时候还好一些，因为这个解码器有补偿机制。
还有其他好多MPEG2解码器，都没有补偿机制，如果用VMR渲染器，如果他们输出用YUV的话，出来的也是错的~
所以不管VMR这么干是不是bug，这些现实问题都是我们要面对的~
你关于这一点有什么好的解决措施吗？
qyqgpower@2007-02-28 22:46
用haali video renderer，效果自己去看
techneek@2007-02-28 23:12
引用
最初由 qyqgpower 发布
用haali video renderer，效果自己去看
你这不是废话吗？
现在研究的是VMR9的问题，如果我要用Haali，我还研究VMR9干什么？
qyqgpower@2007-02-28 23:47
你很有攻击性么
微软为什么要这么写渲染器，我不是微软的人，我怎么知道。究竟有什么意义大家都只能推测，我个人认为是为了保持在电视上的色彩效果而特意转回TV Scale
至于VMR9就是这样，你想要什么解决方法？
1. RGB32输出
2. Level Filter再转回来
3. 据说改注册表的某个地方可以让VMR9在YUV系色空间下输出PC Scale，但具体我也记不清了，且有印象看到后来被指出是行不通的
adamhj@2007-03-04 01:53
怪不得ffdshow设成强制rgb32输出以后看片子会觉得颜色鲜艳一点...
不过lz啊，vmr做yuv->rgb的时候应该只是没做颜色空间的扩展，并没有做压缩吧...
其实应该这样才对啊...
我们压DVDrip的时候，先要作颜色空间扩展的啊，如果render再扩展一遍就不对了啊...
shinjico@2007-03-04 01:57
正常情况下编码好的东西都经过YC压缩，VMR9应该是没做相应的伸张，至于对0~255的YUV强制YC压缩，没试过，或许是MS要搞家庭娱乐中心接电视？
BTW，蛋蛋真是好久不见啊，想你想到蛋疼了~
realsweet@2007-03-04 02:06
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....
adamhj@2007-03-04 02:44
引用
最初由 realsweet 发布
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....
eh..也就是说..什么都不做的其实是偶家显卡么...
pc上放的东西还是弄成601 pc scale好...
另外这样的片子用overlay/haali放的话颜色会过于鲜艳..
realsweet@2007-03-04 02:56
解码用的overlay+FF里高质量YV12->RGB32转换........
这片本身电脑制作,整个一30P的DVD,IVTC都不需要-_____-
techneek@2007-03-04 09:44
引用
最初由 realsweet 发布
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....
这么说应该不对啊~
Xvid和Divx之类的解码哪来的硬件加速啊~
realsweet@2007-03-04 12:08
播放器的硬件加速...
解码器哪有渲染模式的...
运行DXDIAG
把显示里的硬件加速取消最直接
shinjico@2007-03-04 14:41
说起来R9000系的WMV加速看起来像是屏幕在流血~
| TOP