Media Foundation：ReadSample访问违例异常技术咨询

咱们来一步步拆解你遇到的这个访问违例问题——我之前在Media Foundation里处理自定义帧操作时也踩过类似的坑，结合你的流程来看，大概率是帧数据处理、媒体类型匹配或者资源管理环节出了问题，下面是几个重点排查方向：

1. 自定义降采样后的帧与SinkWriter的媒体类型不匹配 #

Media Foundation的SinkWriter对输入帧的格式要求非常严格，哪怕是像素格式、步幅（stride）、分辨率对齐这些细节不匹配，都会导致写入的视频文件损坏，后续读取时触发访问违例。你需要重点检查：

• 确认给SinkWriter设置的IMFMediaType，其MF_MT_FRAME_SIZE（分辨率）、MF_MT_PIXEL_FORMAT（像素格式）、MF_MT_DEFAULT_STRIDE（每行字节数）这几个核心属性，是否和你自定义降采样后的帧数据完全一致。比如你降采样到720p，但如果宽度没有对齐到4的倍数（MF对多数格式有这个要求），或者声明的是NV12格式但实际字节是RGB排列，都会出问题。
• 自定义处理字节时，步幅的计算是否符合MF的规则：比如对于YUY2格式，步幅是宽度 * 2向上取整到4的倍数；对于NV12，亮度平面的步幅是宽度向上取整到4，色度平面是宽度/2向上取整到4。

2. 帧数据的内存管理不当 #

自定义操作字节数据时，内存的锁定、释放和分配如果不符合MF的规范，很容易导致无效内存访问：

• 从SourceReader拿到IMFSample和IMFMediaBuffer后，是否正确调用了Lock()和Unlock()来访问内部字节？直接操作未锁定的缓冲区会导致未定义行为。
• 降采样后创建新的媒体缓冲区时，是否使用MF提供的API（比如MFCreateMemoryBuffer）来创建？手动分配的内存可能不符合MF的对齐要求，写入后会导致后续读取时的访问违例。
• 所有COM接口对象（比如IMFSample、IMFMediaBuffer、ISinkWriter）是否都正确释放了？在C#里要确保调用Marshal.ReleaseComObject()或者通过using语句（如果包装了IDisposable）来释放，避免内存泄漏或无效指针。

3. SinkWriter的收尾操作不完整 #

写完视频后如果没有正确收尾，生成的文件会缺少关键的索引或文件头，导致SourceReader读取时解析失败：

• 循环结束后，必须先调用ISinkWriter.Finalize()让SinkWriter完成所有写入操作（包括文件头和索引），然后再调用Close()释放资源。跳过这两步的话，文件会处于不完整状态，读取时必然出错。

4. 读取低分辨率视频时的媒体类型协商问题 #

读取生成的视频时，SourceReader可能没有协商到合适的输出媒体类型，导致尝试读取不支持的格式：

• 创建SourceReader时，显式设置输出媒体类型，匹配你生成视频的像素格式和分辨率，不要依赖自动协商。比如调用IMFSourceReader.SetCurrentMediaType()时，传入你写入时使用的媒体类型，确保返回值为S_OK。
• 如果自动协商失败，SourceReader可能会返回错误的媒体类型，此时调用ReadSample()就会触发访问违例。

调试建议 #

• 开启Media Foundation的调试日志：设置环境变量MF_DEBUG_LEVEL=3，然后运行程序，查看输出的日志信息，MF会详细记录媒体类型不匹配、缓冲区无效等错误，这是定位问题的关键。
• 把降采样后的帧数据保存成RAW或BMP文件，检查画面是否正确，确认是处理环节的问题还是SinkWriter写入的问题。
• 用Windows Media Player播放生成的视频，如果无法播放，说明文件本身损坏，问题出在写入环节；如果能播放但ReadSample出错，说明读取时的SourceReader配置有问题。

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