有次我们去一家教学医院谈直播方案，对方张嘴就问：“能不能做到零延迟？”我反问他，这场会是要远端医生实时提问、术者当场回应，还是只是把手术播出去给大家看回放。他愣了一下，说主要是后者。这就对了——大多数医学示教，根本不需要追那个“零”，把延迟选错反而多花钱。
先分清：你的会是“看”还是“聊”
纯观看型的学术直播，比如把一台手术播给分会场和线上同行看，RTMP或SRT三到八秒的延迟完全够用，稳定还省心。但凡涉及远端专家实时提问、术者当场解答，或者多中心连线会诊，延迟就得压到一两秒甚至一秒内，这时候得上SRT的低延迟模式或者WebRTC。
SRT：稳，而且抗丢包
SRT是我们用得最多的协议，好处是能在不稳定的网络上把延迟压到一到两秒，还能抗三成左右的丢包。医学直播最怕现场网络抖，SRT这点特别对症。一场普通的院内示教，SRT配5G聚合，基本能把端到端延迟控制在五百毫秒到一秒，远端医生看动作、提问题都跟得上。
WebRTC：快，但挑场景
WebRTC能压到一秒以内，适合真正的实时互动——比如远端专家要“现在就看到这个角度”、要打断提问。但它对服务器和带宽要求高，规模一大容易崩。所以我们一般只在明确的互动环节上WebRTC，其余时段退回SRT，既快又稳。
还有个常被忽略的账：延迟越低，成本越高。WebRTC的并发和运维投入，比SRT高出一截。我们见过科室为了“显得先进”全场开WebRTC，结果三百人同时进，卡到一半。其实把互动环节单独拎出来用WebRTC，主直播走SRT，体验反而更好。
给科室一句实在话：选延迟协议，先看这场会“要不要远端的人插得上话”。要，就上WebRTC或SRT低延迟；不要，SRT常规档足够。别为用不上的低延迟买单，也别在需要互动时图省事用RTMP——那点延迟，足够远端专家的问题变成“马后炮”。协议没有好坏，只有合不合这场会的脾气。