多院区的手术示教，跟单院区完全是两件事。单院区只需要把术野画面送到示教室，多院区要考虑的是，几个地方的人看到的是不是同一个瞬间。
广州有个项目，总院做手术，两个分院区同时观摩，还要能提问互动。我们前后去了四次，最后一次才把延迟压到能用的水平。
三条链路，一条也不能少
第一条是术野视频链路。术间到本院区的导播间，这一段我们走的是院内光纤加 SDI 转换，延迟在 1 帧以内，基本可以忽略。
第二条是院区之间的传输链路。这一段是延迟的主要来源。如果走公网加 VPN，实测单程要 80 到 150 毫秒，来回加上编解码，往往超过一秒。如果医院之间有专线，能压到 20 毫秒以内，那就完全不一样。
第三条是返场音频链路，也就是分院区提问的声音回到术间或者主会场。这条最容易被漏掉，但它是互动能否成立的关键。
第一次尝试：全走公网，失败了
这个项目我们第一次的方案是想省事，全部走公网推流，分院区用普通播放器拉流。
结果问题一堆。
首先是延迟不可控。我们现场测过，分院区 A 的画面比主会场慢 1.8 秒，分院区 B 慢 2.4 秒。两个分院区彼此也不同步，提问的时候，A 问的问题 B 还没看到画面，场面很尴尬。
其次是画质不稳定。下午三点左右医院的公网出口拥塞，码率自己往下掉，术野细节糊成一团，主任当场说看不清。
最后是音频反馈。分院区 A 的提问声音传到主会场，主会场的音箱又把它送回去，形成了明显的回声，讲师听不清问题。
这次尝试以失败告终，当天下午我们就改了方案。
第二次尝试：专线加本地导播
第二次我们把架构整个换了。
院区之间走医院自有的教育专线，带宽 100Mbps，实际用 40Mbps 做双向。传输协议从 RTMP 换成 SRT，抗丢包能力明显好一截。实测在 3% 丢包的情况下，画面基本没有卡顿。
反向音频不再走公网，单独走一路低带宽的稳定通道，延迟压到 300 毫秒左右。这个数字比视频延迟还低，是为了让提问的人感觉不到明显的时滞。
最关键的一步是每个分院区都配了一台本地导播机，不再让分院区直接拉流，而是由主会场推一路干净信号过去，分院区本地做一次解码分发。这样分院区内部的多个屏幕可以共用一路输入，不会各自拉流抢占带宽。
改完之后，三个会场之间的画面差异控制在 400 毫秒以内。现场主任说，基本感觉不出来。
时钟对齐这件事，比想象中重要
即使链路延迟压下来了，如果各会场的设备时钟不一样，回放的时候还是会对不上。
我们那次就遇到过：主会场录制的视频和分院区录制的视频，同一次手术，时间码差了 47 秒。原因是分院区的录播机没有做 NTP 同步，走的是出厂默认时间。
后来我们要求所有录制设备统一对接院内 NTP 服务器，同步周期设成 5 分钟一次。这样多路录像事后拼接或者比对的时候才不会错位。
这事听起来是小事，但对于需要留存作为教学资料的项目来说，时间码错了等于没法用。
互动提问要留一点缓冲
完全实时的互动体验其实不好。
我们现在的做法是让导播留出大约 1.5 秒的缓冲，提问时先由主持人复述一遍问题，再请讲师回答。一方面给音频链路留出时间，另一方面也让所有会场都听清楚问题。
讲师那边会更从容，不用急着回应一个还没听全的提问。
设备和人的备份
多院区项目的现场至少有四个环节可能断：术间采集、主会场导播、院区传输、分院区接收。
我们每个环节都留了备份，但真正救过场的是最土的那个：每个分院区派一名现场工程师，不带别的任务，只盯屏幕和声音。有一次分院区 B 的解码器死机，现场工程师 20 秒内重启完成，主会场那边甚至没察觉到。
远程监控再全，也替代不了一个人在现场。
这套方案后来成了广州摄行直播在广州做多院区示教的标准架构。有专线就用专线，没有专线就退回去做单向直播，不勉强做互动。勉强上互动，最后受罪的是讲者和学员。