搜索 社区服务 统计排行 帮助
  • 2608阅读
  • 13回复

[原创]火星发现:VMR9吃错药,YUV转RGB有严重问题!

楼层直达
级别: 新手上路
注册时间:
2007-02-26
在线时间:
0小时
发帖:
185
试验是这样的~

这是一张包含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没有这样做。
级别: 侠客
注册时间:
2005-02-09
在线时间:
0小时
发帖:
512
只看该作者 1楼 发表于: 2007-02-28
VMR9向来这样,不然也不会存在RGB32输出可以得到PC Scale画面而YV12输出就成了TV Scale的毛病了

如果你说这是bug,那么Vista中全新编写的Enhanced Video Renderer也是这么处理YUV系的色空间的,微软的人是不是都吃错药了?
级别: 新手上路
注册时间:
2007-02-26
在线时间:
0小时
发帖:
185
只看该作者 2楼 发表于: 2007-02-28
引用
最初由 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,这些现实问题都是我们要面对的~
你关于这一点有什么好的解决措施吗?
级别: 侠客
注册时间:
2005-02-09
在线时间:
0小时
发帖:
512
只看该作者 3楼 发表于: 2007-02-28
用haali video renderer,效果自己去看
级别: 新手上路
注册时间:
2007-02-26
在线时间:
0小时
发帖:
185
只看该作者 4楼 发表于: 2007-02-28
引用
最初由 qyqgpower 发布
用haali video renderer,效果自己去看


你这不是废话吗?

现在研究的是VMR9的问题,如果我要用Haali,我还研究VMR9干什么?
级别: 侠客
注册时间:
2005-02-09
在线时间:
0小时
发帖:
512
只看该作者 5楼 发表于: 2007-02-28
你很有攻击性么

微软为什么要这么写渲染器,我不是微软的人,我怎么知道。究竟有什么意义大家都只能推测,我个人认为是为了保持在电视上的色彩效果而特意转回TV Scale

至于VMR9就是这样,你想要什么解决方法?
1. RGB32输出
2. Level Filter再转回来
3. 据说改注册表的某个地方可以让VMR9在YUV系色空间下输出PC Scale,但具体我也记不清了,且有印象看到后来被指出是行不通的
级别: 新手上路
注册时间:
2003-06-23
在线时间:
1小时
发帖:
2882
只看该作者 6楼 发表于: 2007-03-04
怪不得ffdshow设成强制rgb32输出以后看片子会觉得颜色鲜艳一点...

不过lz啊,vmr做yuv->rgb的时候应该只是没做颜色空间的扩展,并没有做压缩吧...

其实应该这样才对啊...
我们压DVDrip的时候,先要作颜色空间扩展的啊,如果render再扩展一遍就不对了啊...

不学无术中..

eMule ID:[eDtoon][CHN]adamhj@eMule-Official
级别: 超级版主
注册时间:
2004-07-25
在线时间:
121小时
发帖:
3898
只看该作者 7楼 发表于: 2007-03-04
正常情况下编码好的东西都经过YC压缩,VMR9应该是没做相应的伸张,至于对0~255的YUV强制YC压缩,没试过,或许是MS要搞家庭娱乐中心接电视?

BTW,蛋蛋真是好久不见啊,想你想到蛋疼了~

级别: 工作组
注册时间:
2005-04-23
在线时间:
0小时
发帖:
4259
只看该作者 8楼 发表于: 2007-03-04
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....

Lux Aeterna

过去一直去,未来一直来...
级别: 新手上路
注册时间:
2003-06-23
在线时间:
1小时
发帖:
2882
只看该作者 9楼 发表于: 2007-03-04
引用
最初由 realsweet 发布
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....


eh..也就是说..什么都不做的其实是偶家显卡么...

pc上放的东西还是弄成601 pc scale好...
另外这样的片子用overlay/haali放的话颜色会过于鲜艳..

不学无术中..

eMule ID:[eDtoon][CHN]adamhj@eMule-Official
级别: 工作组
注册时间:
2005-04-23
在线时间:
0小时
发帖:
4259
只看该作者 10楼 发表于: 2007-03-04
解码用的overlay+FF里高质量YV12->RGB32转换........
这片本身电脑制作,整个一30P的DVD,IVTC都不需要-_____-

Lux Aeterna

过去一直去,未来一直来...
级别: 新手上路
注册时间:
2007-02-26
在线时间:
0小时
发帖:
185
只看该作者 11楼 发表于: 2007-03-04
引用
最初由 realsweet 发布
VMR9(renderless)只接受RGB的数据,开了硬件加速才会走overlay直接输出YV12 丢给显示卡去做 YUV -> RGB 的转换工作并做YC扩展
关闭硬件加速 解码器自己会解码为RGB
这问题记得以前在哪个贴子看到过,差点给忘了,果然梦游状态有灵感啊....


这么说应该不对啊~
Xvid和Divx之类的解码哪来的硬件加速啊~
级别: 工作组
注册时间:
2005-04-23
在线时间:
0小时
发帖:
4259
只看该作者 12楼 发表于: 2007-03-04
播放器的硬件加速...
解码器哪有渲染模式的...
运行DXDIAG
把显示里的硬件加速取消最直接

Lux Aeterna

过去一直去,未来一直来...
级别: 超级版主
注册时间:
2004-07-25
在线时间:
121小时
发帖:
3898
只看该作者 13楼 发表于: 2007-03-04
说起来R9000系的WMV加速看起来像是屏幕在流血~

快速回复

限150 字节
上一个 下一个