NDI 源从 1080p 切到 720p 后花屏，接收端怎样按帧重建缓冲

源切换后花屏时，应比较连续帧的分辨率、FourCC、行跨距和场类型，检查接收方有没有继续复用旧缓冲布局。源仍能连接不代表格式恒定。不能只在创建接收器时读取一次1920×1080，然后假设以后所有帧都能塞进相同纹理。

先固定输入与适用条件

本例用三个连续格式阶段模拟1920×1080 UYVY、1280×720 BGRA及恢复原格式，不启动NDI运行库。状态机只表示应用应在哪些边界重新确认资源，实际释放、复制和线程同步仍需遵守目标SDK。输入为空或尚未取得视频时，应明确无有效画面，不能复用未初始化内存。

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

按字段与边界执行

1. 逐帧形成格式键，至少包含宽、高、FourCC、stride和场类型。音频若也变化，应另建音频格式键，不能由视频切换推断声道配置保持不变。

2. 将新格式键与当前资源描述比较。相同则继续处理，不同则进入格式变更分支，暂停使用旧纹理解释新数据。

3. 为新格式计算最低字节需求并建立正确资源，成功后再更新活动键；失败时保留明确错误状态，不能先宣布切换完成再处理分配失败。

4. 记录格式变更前后首个有效帧，区分检测到变化、资源重建、恢复显示三个时刻。需要多个线程时，按目标API设计同步与缓冲释放顺序。

用具体样例核对结果

附件五个帧描述的格式键变化发生在首帧、第3帧和第5帧。前两帧相同不应重复触发重建；第三帧虽然像素更少，但BGRA每像素四字节，stride从3840变为5120，不能简单沿用旧值。脚本输出三个资源阶段与各段字节需求，断言只在真正变化处标记重建。

这里的通过只表示状态分段与计算正确，不证明具体播放器支持热切换。恢复原分辨率也不保证旧对象仍可安全使用；资源可能已被释放或换到另一线程。若现场只在切换瞬间错误，附上连续描述和资源重建日志比截图更有用。若固定格式也错，应回到FourCC或行跨距专项，不要把所有花屏都归因格式变化。

下载与复现

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

input.json是按帧排列的格式序列，result.json包含格式键与新阶段编号。交给软件开发者时另附实际SDK、线程模型及资源创建错误码；禁止把合成状态机的“重建点”写成真实GPU分配已通过。

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

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

对接下一步与一级来源

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

• 每帧自带分辨率与FourCC描述。
• 接收格式可变化且应广泛支持帧属性。

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