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