先说结论:别迷信最低延迟
远程会诊和手术示教,很多人开口就要"最低延迟"。但说句实在话,延迟低不等于体验好,关键是看互动模型。我把常用三件套放一起比一下:
- RTMP:公网延迟 3 到 8 秒,协议层面的锅,握手重、无前向纠错,但生态成熟,几乎啥平台都收,适合做公开转播分发。
- SRT:1 到 2 秒,主打抗丢包,自动重传加前向纠错,弱网照样稳,我们院间示教主推它。
- WebRTC:亚秒级,通常 200 到 800 毫秒,真正双向实时,适合"这边问那边答"的会诊和指导。
判断标准就一句:示教单向,观众晚几秒无所谓;但会诊里专家喊"停"主刀才停,延迟必须压到 1 秒以内,否则那声"停"到不了,就真出事了。
什么场景选 SRT
纯示教、单向为主、偶有主播解说,选 SRT 最稳。我去年接一家学会的年会转播,主会场到分会场跨三个城市,公网质量参差,SRT 的 ARQ 重传把丢包吃掉,画面没花过一帧。它不挑播放端,接收方用 vMix、OBS 或我们自己的网关都能拉,部署成本也低,一台聚合路由器加一台边缘接收机就够,2 到 4 Mbps 就能跑 1080p。
缺点是它不是真双向,远端想插话得另开一路语音或走会议系统,所以纯讲课型没问题,真要来回对话就别难为它。我们一般把 SRT 主路配一路独立的语音会议桥,勉强补上互动。
什么场景必须 WebRTC
远程会诊要"实时对话"——专家看术野同时口述指导,主刀要立刻回应,这时候 3 秒延迟就耽误事了。WebRTC 的 SFU 架构能把往返压到亚秒,某三甲做神经介入远程指导就用它,专家在几百公里外实时纠正导管角度,迟一秒可能就是别的结局。双向各占 1.5 到 3 Mbps,公网波动时要预留余量。
代价也实在:SFU 服务器得自己搭,要维护信令和 TURN 穿透,规模上来运维重。小场子用 PaaS 凑合,大并发还是得私有化部署,还得考虑院内网和公网的边界安全。我们给这类客户默认上私有化,数据不出院。
安全和合规也是选型项
医学数据出网,加密不是可选项。SRT 自带 AES,WebRTC 走 DTLS 和 SRTP,都比裸 RTMP 明文传输安全,这一点在等保和伦理审查里都是加分项。所以即便不追延迟,我们也倾向用 SRT 或 WebRTC 替代裸 RTMP 做核心链路。
带宽与实测别只信标称
实测时别只看厂商标称。我们在院间链路常用端到端卡表测:从术野主机位出图到观摩端上屏,掐表记往返。SRT 我们压到 1.2 秒左右,WebRTC 多数在 600 毫秒内。这个数值和你现场带宽、编码器 GOP 设置强相关,提前联调比现场救火强得多。
我们的取舍建议
示教直播单向为主 → SRT;跨中心实时会诊双向互动 → WebRTC;RTMP 留着做对外公开转播的兜底分发,别拿它做核心互动。还有个混合思路:主路 SRT 保稳,需要实时问答时临时拉一路 WebRTC 小窗,各取所长。
延迟是手段不是目的,按互动密度选协议,比追一个数字实在。先想清楚这场直播"谁在跟谁说话",协议自然就定了。
