Windows Media Foundation下拷贝RGB至Media Buffer的H.264编码对齐异常

两种不同RGB数据采集路径最终复现完全一致的解码异常，说明问题根本不在数据采集环节，而是自定义系统内存输入路径下，开发者遗漏了之前DXGI surface绑定路径下由框架自动兜底的格式、内存、设备配置约定。硬件MFT在接收绑定ID3D11Texture2D的IMFMediaBuffer时，会自动完成内存布局、步长、色彩空间、设备上下文的全链路匹配；一旦切换为自定义系统内存media buffer，所有匹配逻辑都需要开发者手动对齐，任何环节的偏差都会直接导致编码输出的画面异常。

输入媒体类型（IMFMediaType）的全字段匹配 #

• 最常见的异常触发原因，是开发者直接复用DXGI路径下协商完成的媒体类型。
  • DXGI输入路径下，硬件H.264 MFT默认协商的子类型通常是NV12、P010这类硬件原生YUV格式，并非RGB格式。如果沿用该类型，编码器会直接把RGB像素数据强行按照YUV布局解析，必然出现大块色彩错位、块效应的显示异常。
  • 切换系统内存RGB输入后，必须重新和编码器协商输入媒体类型：
    • 明确设置MF_MT_MAJORTYPE为MFMediaType_Video
    • 按照实际采集的RGB格式匹配MF_MT_SUBTYPE：比如32位BGRA数据对应MFVideoFormat_RGB32、非预乘Alpha的RGBA数据对应MFVideoFormat_RGBA
    • 手动填充所有布局相关字段：包括MF_MT_FRAME_SIZE、MF_MT_DEFAULT_STRIDE、MF_MT_PIXEL_ASPECT_RATIO，这些字段在DXGI路径下会由MFT根据纹理属性自动填充，系统内存路径下必须和实际buffer的布局完全一致。

内存步长（Stride）的逐行对齐 #

• 不管是通过BitBlt/GetDIBits还是D3D11_MAPPED_SUBRESOURCE采集RGB，源数据的行步长（即每一行像素占用的字节数）都不会是理论上的「像素宽度*每像素字节数」，默认会按照4字节边界对齐，部分D3D硬件的纹理步长甚至会按照64字节、256字节边界做硬件对齐。
  • 常见错误操作是直接memcpy整块连续的RGB数据到IMFMediaBuffer中，没有按照源数据的实际行步长逐行搬运，也没有按照媒体类型中设置的目标步长预留行间空白，导致每一行的像素位置相对编码器读取的位置发生固定偏移，最终表现为画面横向错位、拉伸、块带错位。
  • 正确的拷贝逻辑：
    1. 从数据源获取实际行步长：GetDIBits场景下从BITMAPINFOHEADER的biSizeImage反推行步长，D3D映射场景下直接读取D3D11_MAPPED_SUBRESOURCE结构体的RowPitch值
    2. 逐行将源像素复制到IMFMediaBuffer的对应内存位置，行间间隔完全匹配媒体类型中声明的MF_MT_DEFAULT_STRIDE值
    3. 对二维布局的视频内存，优先通过IMF2DBuffer2接口完成内存访问，不要直接将IMFMediaBuffer::Lock拿到的连续内存块当作紧凑排列的线性像素数组处理。

硬件MFT的D3D设备上下文关联配置 #

• 即便是使用系统内存的RGB media buffer作为输入，硬件H.264 MFT依然需要关联D3D11设备完成内部的RGB转YUV格式转换、硬件编码运算。
  • DXGI输入路径下，框架会自动为MFT关联开发者创建的D3D设备管理器；如果切换系统内存输入时遗漏了该配置，MFT会自动创建独立的默认D3D设备完成格式转换，两套设备的内存对齐规则、色彩转换矩阵存在差异，会直接导致转换后的YUV数据布局、色彩出现偏差。
  • 正确的配置逻辑：无论输入是DXGI surface还是系统内存RGB，初始化编码器时都需要向MFT发送MFT_MESSAGE_SET_D3D_MANAGER消息，将自己创建的D3D11设备对应的IMFDXGIDeviceManager句柄传给MFT，保证格式转换、编码运算全流程在同一个D3D设备上下文中执行。

像素通道排列顺序校验 #

• 通过BitBlt/GetDIBits获取的32位RGB数据，默认是B、G、R的通道排列顺序（即BGRA格式），和D3D11常用的R8G8B8A8_UNORM纹理的通道顺序相反。如果通道顺序和媒体类型中声明的子类型不匹配，即便内存布局完全正确，也会出现R/G通道对调、整体偏色的异常效果。
  • 校验时需明确：
    • GetDIBits获取的BGRA数据，对应MFT的MFVideoFormat_RGB32子类型，不可误用MFVideoFormat_ARGB32（后者对应预乘Alpha的BGRA格式，Alpha通道处理逻辑存在差异）
    • D3D11映射获取的R8G8B8A8_UNORM纹理数据，对应MFVideoFormat_RGBA子类型，不可直接复用BGRA对应的类型定义

绕开BitBlt、D3D纹理采集的环节，直接加载一张本地已知格式、已知步长的标准RGB测试图片，按照自定义media buffer的封装流程送入编码器，如果复现完全一致的异常效果，即可定位问题为格式匹配、步长对齐、设备配置三类公共环节，与数据采集流程无关。

内容的提问来源于stack exchange，提问作者Bhuvanesh Murugaiyan