NDI 有画面却少一路解说，怎样按平面音频缓冲核对通道映射

NDI接收端有画面但少一路解说，先确认音频帧的通道数、样本数和通道字节跨距，再核对应用的输出路由。FLTP按通道连续存储，并不是左右交替的交错音频；把数据按交错方式读，即使每个浮点数都合法，也会把解说混进错误的输出。

先固定输入与适用条件

适用输入是SDK交出的音频v3描述及同一帧缓冲快照。本例用四个逻辑通道代表左声道、右声道、解说和备用；这些名称是项目约定，协议中的第三通道不会自动叫解说。采集时要保留sample_rate、no_channels、no_samples、FourCC和channel_stride_in_bytes，不能只截一张声卡设置图。

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

按字段与边界执行

1. 先从同一帧记录字段，确认FourCC为FLTP且每个样本为四字节浮点。为零通道、零样本和缓冲不足建立拒绝条件，避免把尚未收到音频当正常静音。

2. 按通道索引乘字节跨距找到各通道起点，再读取该通道的样本数。跨距可能包含对齐空间，不能用总缓冲长度直接除通道数来猜。

3. 先向离线样本中的四路分别写入可区分的数列，检查解析得到的每列是否仍来自同一路，再把应用的逻辑通道编号映射到输出端。

4. 最后才接入现场路由记录。逐路单独识别音频，在接收软件、系统音频设备及实际扬声器三个位置分别留证；缓冲解析通过只覆盖第一层。

用具体样例核对结果

附件每路六个样本，通道有效数据24字节，跨距却是32字节。第二路起点是32而不是24，解说路起点为64。四路分别用0.01、0.02、0.03、0.04的倍数作为签名，padding填入不同值。按32字节读取时每路保持单调；误按24字节读取会踩到padding，读出的数字即便有限也没有声学意义。

结果应同时满足四路都可寻址、每路六个样本、padding未被当成声音、通道标签在路由表中唯一。若解析结果正常而输出仍缺解说，应转查应用是否只请求立体声，以及下游是否明确选择了第三路。不要把第三路直接叠加进左右声道作为默认修复，增益和内容责任需要另行确认。

下载与复现

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

下载的input保留字段和合成样本，analyze会实际打包为浮点缓冲、跳过padding并生成逐路result.json。交接时把实际帧描述和应用路由一起提供，不能只说“NDI有四声道”。

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

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

对接下一步与一级来源

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

• 音频v3 FLTP及通道字节跨距。

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