我正在开发一个应用程序,使用媒体基础 h264 编码器对视频进行编码。使用 VRAM 中的 RGB 输入时,Sink writer 在 Windows 7 上崩溃,显示“0x8876086C D3DERR_INVALIDCALL”,因此我在 GPU 上实现了自己的 RGB->NV12 转换,节省了超过 60% 的 PCI Express 带宽。
到目前为止,我用这个公式得到的最好结果是:
我的担忧是这个公式与我在互联网、代码示例和ITU官方规范中读到的一切相矛盾。
对于Y,公式没问题,我使用了BT.709系数,并将它们线性缩放以将[0..255]映射到[16..235],正如规范中所写的那样。亮度是正常的。
规范要求我必须将U和V缩放以将[0..255]映射到[16..240]。然而,我的眼睛告诉我它色彩不饱和。为了得到正确的颜色,我必须将U和V反向缩放,从[0..255]映射到[-8,255 + 8]之类的值。
为什么我需要反向缩放才能在h264编码和解码后获得正确的颜色?这段代码能在其他人的电脑上运行吗?
这是我的媒体类型中的内容,包括输入(NV12)和输出(h264):
mt->SetUINT32( MF_MT_VIDEO_CHROMA_SITING, MFVideoChromaSubsampling_MPEG2 ); // Specifies the chroma encoding scheme for MPEG-2 video. Chroma samples are aligned horizontally with the luma samples, but are not aligned vertically. The U and V planes are aligned vertically.
mt->SetUINT32( MF_MT_YUV_MATRIX, MFVideoTransferMatrix_BT709 ); // ITU-R BT.709 transfer matrix.
mt->SetUINT32( MF_MT_VIDEO_NOMINAL_RANGE, MFNominalRange_0_255 ); // The normalized range [0...1] maps to [0...255] for 8-bit samples or [0...1023] for 10-bit samples.
mt->SetUINT32( MF_MT_TRANSFER_FUNCTION, MFVideoTransFunc_10 ); // Linear RGB (gamma = 1.0).
到目前为止,我用这个公式得到的最好结果是:
inline float3 yuvFromRgb(float3 rgba)
{
float3 res;
res.x = dot( rgba, float3( 0.182585880, 0.614230573, 0.0620070584 ) );
res.y = dot( rgba, float3( -0.121760942, -0.409611613, 0.531372547 ) );
res.z = dot( rgba, float3( 0.531372547, -0.482648790, -0.0487237722 ) );
res += float3( 0.0627451017, 0.500000000, 0.500000000 );
return saturate( res );
}
我的担忧是这个公式与我在互联网、代码示例和ITU官方规范中读到的一切相矛盾。
对于Y,公式没问题,我使用了BT.709系数,并将它们线性缩放以将[0..255]映射到[16..235],正如规范中所写的那样。亮度是正常的。
规范要求我必须将U和V缩放以将[0..255]映射到[16..240]。然而,我的眼睛告诉我它色彩不饱和。为了得到正确的颜色,我必须将U和V反向缩放,从[0..255]映射到[-8,255 + 8]之类的值。
为什么我需要反向缩放才能在h264编码和解码后获得正确的颜色?这段代码能在其他人的电脑上运行吗?