如何修复MicroSIP本地视频窗口红蓝互换、颜色显示错误问题

开发者阿泽

2026-8-27

问题梳理

运行环境：Windows平台，基于MicroSIP开展定制化二次开发
异常表现：本地视频窗口加载虚拟摄像头Screen Capture Recorder输出的屏幕采集流时，出现红色与蓝色通道互换的色彩异常，效果参考上传示例截图
已尝试修复操作：将依赖组件FFmpeg升级至5.0.1版本、SDL升级至2.0.22版本（均为当前最新正式版本），问题未解决
复现验证结论：
- 该问题可在MicroSIP最新官方正式版（3.21.2）上稳定复现
- MyCam等其他支持调用该虚拟摄像头的软件均可正常显示正确色彩，无通道错位问题
关联代码范围：MicroSIP官方源码、为其提供底层音视频接口的PJSIP源码（初步判定该模块为高风险问题点）

重点排查方向

第一优先级排查PJSIP的Windows端视频采集模块的格式识别逻辑：Windows平台摄像头采集链路普遍存在MEDIASUBTYPE_RGB24与MEDIASUBTYPE_BGR24格式标识混淆问题。虚拟摄像头输出的RGB类格式通常为BGR字节序，如果PJSIP枚举采集格式时未正确读取位图信息头的biCompression字段判断实际通道顺序，硬编码按照RGB字节序做后续渲染处理，会直接触发红蓝通道互换的问题。
第二优先级排查SDL渲染层的纹理格式匹配逻辑：重点核对传入SDL的视频帧实际通道顺序，和创建渲染纹理时指定的像素格式是否一致。如果帧数据实际为BGR24排列，但创建纹理时传入的格式参数为SDL_PIXELFORMAT_RGB24，渲染阶段就会出现通道错位。注意不要仅核对FFmpeg、SDL的版本号，版本升级不会修正代码里硬编码的格式传参错误。
第三优先级排查本地预览分支的格式处理逻辑：PJSIP的本地视频预览流和远端编解码视频流走独立的格式处理链路，不要因为远端视频显示正常就跳过本地预览路径的格式转换代码检查。
可跳过FFmpeg编解码模块排查：其他软件调用同个虚拟摄像头显示正常，且升级FFmpeg版本无效果，说明虚拟摄像头输出的视频流本身无格式错误，问题出在采集到渲染之间的格式识别、转换环节，和编解码逻辑无关。

可落地修复方案

先在PJSIP的Win32视频采集源码段加调试日志，打印采集输出帧的位图信息头字段：biBitCount、biCompression，确认虚拟摄像头输出的RGB格式实际字节序是RGB还是BGR。
若确认采集输出帧为BGR字节序，可二选一实现修复：
- 低侵入快速修复：在采集帧送渲染前增加轻量通道转换逻辑，逐像素交换红蓝通道，注意按照帧实际行步长遍历，避免出现花屏，核心转换代码参考：
```
// 逐像素交换BGR/RGB的红蓝通道
for (int y = 0; y < frame_height; y++) {
    uint8_t *row = frame_buf + y * frame_stride;
    for (int x = 0; x < frame_width; x++) {
        uint8_t *pixel = row + x * 3;
        uint8_t tmp = pixel[0];
        pixel[0] = pixel[2];
        pixel[2] = tmp;
    }
}
```
- 高性能修复：修正SDL纹理创建时的像素格式参数，若输入帧为BGR24格式，创建纹理时直接指定格式为SDL_PIXELFORMAT_BGR24，不需要额外做帧数据拷贝转换，无额外性能损耗。
修复完成后需要做兼容性验证：除Screen Capture Recorder虚拟摄像头外，同步测试实体USB摄像头、其他主流虚拟摄像头的色彩显示，避免修复后导致其他采集设备出现反向的通道错位问题。

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