多机帧同步架构实战

多机播放架构先解决“谁提供节目与时间参考、节点怎样跟随、失效时怎样恢复”，再验证各层对齐。网络主从、公共时钟与硬件帧锁不是互相替代的三种套餐：它们可能作用于不同层，需要组合与测量。

用同一套四层术语画架构

时钟层提供事件的时间参考；内容进度层确定节目、循环和PTS；渲染提交层处理解码、缓冲与present；显示刷新层涉及输出扫描及接收设备处理。这与帧同步和网络同步定义一致。本页不再把“内容、帧、信号”描述为自动升级就能覆盖前层的三个等级。

节目清单与素材摘要 ──> 各节点本地文件与节目身份
时钟/主节点事件   ──> 应用进度协调 ──> 解码与渲染提交
硬件参考（若采用）────────────────> 支持设备的输出刷新
每层独立日志与观测 ──> 同一验收事件ID ──> 结果及未知项

每种声明都对应条件

声明	必须确认的实现与条件	验证方式	本轮状态
节点按统一时间线同播	节目版本、素材摘要、时间基、同步协议	节目ID与展开PTS比较	仅协议设计，未测产品
能长期限制内容漂移	纠偏策略、弱机处理、循环与加载行为	固定测点曲线与失败轮次	未接实体多机
渲染提交协调	应用与图形后端支持、队列配置	present证据或可解释的替代测量	未测
硬件帧锁/外部参考	GPU、同步卡、驱动、显示模式与参考信号支持	厂商锁定状态加输出端测量	未验证，不作产品承诺

NTP/PTP完成对时不代表渲染和刷新锁定。带宽高也不自动保证低抖动；网络划分只是降低某些干扰，不能代替接收端超时与恢复策略。同一显卡多输出仍需核验支持条件，不能省略刷新层。

部署时把正常与失败都写成合同

1. 先固定节目身份与源文件，保证节点取得正确内容。相同文件名不够，摘要与本地路径都要查；预分发完成后再开始性能测试。
2. 明确时间参考、主角色、跟随方式和可观察接口。需要厂商专用端口与消息格式的，以受测版本手册为准，不自创“通用同步端口”。
3. 明确性能不足时等谁、跳帧还是退出组；这类策略由实现决定，不应假设所有从机都会拖住全组。
4. 分别演练晚加入、主链路失效、主进程退出和旧主恢复。自动选主、备机接管都必须有明确实现与测试，不能只把另一台也设成主。

持久运行按一小时漂移曲线协议记录；角色故障按主节点失效演练执行；连续画面观测按帧号样片协议保存原录像。测试网络应隔离，正式开馆期间不制造拔线故障。

输入、判断与未测范围

合成例：两机在开播时相差10ms，一小时后相差34ms，则新增内容漂移为24ms；这不证明授时误差24ms，也不证明显示输出相差24ms。可下载演算原始输入，Python 3.12.4已核验差分与单位换算，曲线明确标为合成。

实际报告应列所有主机、GPU、同步设备、驱动、播放器版本、输出模式、文件摘要、测试长度和采样分辨率；每种同步声明分别标“已测、文档声明、未确认”。没有数据时写未知，不能以“绝大多数展厅够用”代替本项目判据，也不承诺零撕裂。

一级来源

2026-10-23核对：NVIDIA多系统同步配置用于硬件条件；FFmpeg ffprobe用于素材时间信息。本轮没有硬件支持矩阵实机核验、同步卡锁定截图或现场录像。