试验是这样的~
这是一张包含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没有这样做。