NDI 接收画面红蓝颠倒，怎样从 FourCC 判定真实字节顺序

红蓝颠倒时，应读取接收帧实际返回的FourCC，再决定怎样解释内存中的字节。接收设置表达允许返回的格式，不能代替每帧格式字段。BGRA与RGBA各占四字节却通道顺序相反，UYVY则是两个像素共享色度，不能按四字节独立RGBA像素处理。

先固定输入与适用条件

本例仅在CPU缓冲层验证通道排列，选择两个可辨认的纯色像素作为样本，不接显示卡和屏体。先保存FourCC、有效宽高、行跨距和前几个像素的十六进制值；若日志只有“32位颜色”，证据不足。像素格式、颜色矩阵与色度范围属于不同字段，本题只解决第一项。

本篇按NDI官方滚动SDK文档解释视频v2或音频v3帧描述。文档核对日期为2026-10-24；这不是本地已安装NDI运行库的版本声明，设备与第三方软件需另录版本。

按字段与边界执行

1. 固定接收设置，保存每帧返回FourCC。若使用fastest或best，允许的返回类型可能变化，调用方需要按实际描述分支，不按历史第一帧猜测。

2. 取两个已知颜色的像素，逐字节标上位置。BGRA的首字节是蓝，RGBA的首字节是红；BGRX或RGBX的第四字节不应被当成有效透明变化。

3. 遇到UYVY，先按U0、Y0、V0、Y1拆出一个宏像素，确认共享关系。不要把这四个字节当一个屏幕像素，也不要未经矩阵换算直接称其为红色。

4. 完成离线检查后，再比较应用上传GPU的纹理格式和着色器采样方式。若缓冲读取正确而窗口错误，修复点可能在纹理解释阶段。

用具体样例核对结果

附件中红像素的BGRA是00 00 FF FF，蓝像素是FF 00 00 FF；同样的红蓝顺序在RGBA中则交换首尾颜色分量。脚本把两段数据分别按声明格式解码，结果都得到红后蓝。另一个UYVY样本只输出U、Y0、V、Y1四个分量，故意不输出未经色彩矩阵定义的RGB结果。

验收条件是声明格式对应字节顺序、两个像素颜色身份不变、UYVY宏像素没有错误拆半。若把同一BGRA字节强行交给RGBA解析，脚本明确展示红蓝交换，这比修改屏体色温更能定位问题。不要把同样的数据重新写入图片却没有注明写出格式，也不要以截图正常推断原始缓冲格式正常；截图可能经过了另一条转换链。

下载与复现

analyze.py、input.json、result.json。

下载的解析器只进行格式拆分，不做网络采集或色彩管理。给接收端开发者时，保留FourCC、原始hex和预期像素身份三个信息；行跨距错误请继续使用独立的stride夹具，不把两类问题混在同一条修复结论里。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看NDI 网络视频传输协议详解。相关流程收在多媒体播放专题；需要项目对接时，带上本文输入及结果向SoftPlayer核对实际能力。

• FourCC缓冲排列。
• 接收color_format与实际返回格式。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。