直播低延迟优化到底要花多少代价：从 8 秒压到 800 毫秒

去年 11 月中旬的周四下午两点半，华东某制造园区的供应商大会开场前四十分钟，客户的 IT 负责人把我拉到侧幕帘子后面问了一句：能不能做到跟站在会场里听一样快？我说能，但在签字之前，得先把直播低延迟优化这笔账摊开算给你看。延迟每往下压一档，钱不是线性涨的，是一级一级往上跳的台阶。

那天我们最后停在 1.7 秒，客户挺满意。今天我把这张台阶表整个写出来，谁看了都能对着自己的预算划一刀。做直播低延迟优化这些年，我最常干的事不是把数字往下压，而是劝客户别压。

直播低延迟优化本质上是一张阶梯标价单

先把概念说平。业内讲的延迟，一般指从摄像机 SDI 出画面，到观众手机上看到这一帧的端到端时间。中间要过编码、推流、转码、分发、播放器缓冲五道关，每道关都在吃时间。

我们内部把它切成四档：8 秒、3 秒、1.2 秒、800 毫秒。这四个数字不是拍脑袋定的，是摄行科技近三年一百二十多场企业会议实测出来的中位数。每一档对应一条明确的技术路线，也对应一笔明确的增量开销。

8 秒档：HLS 和 LL-HLS，几乎不用额外掏钱

标准 HLS 切片 6 秒、播放器缓三片，18 秒起步是常态。改成 2 秒切片、只缓两片，实测能落到 7.8 秒到 9 秒之间。LL-HLS 用分块传输能再往下拉到 4 秒上下，但对 CDN 节点的支持有要求，不是所有节点都开了这功能。

这一档便宜到几乎不用算：普通云直播按流量计费，1080P 一场三小时、两千三百人在线，带宽账单大概三千二。观看端也不挑设备，五年前的安卓机照样开。

内部培训、季度通报会、年会回放这类没有实时互动的场景，停在这档完全够。我见过太多客户一上来就要"零延迟"，我问一句"您这场有连麦吗"，答"没有"，那这钱纯属白烧。

有个细节容易被忽略：这一档的延迟波动很小。切片机制天然稳，观众之间的进度差通常在 1.5 秒以内，抽奖、投票这类要求大家看到同一画面的环节反而更公平。到了低延迟档，不同网络的观众进度能差出两三秒，抽奖口令一喊，网快的人先按，客服电话当场就打爆了。这种事我们遇上过两回。

3 秒档：RTMP 直推，钱主要压在编码器上

RTMP 走 TCP，链路顺畅时端到端 2.6 到 3.4 秒。想稳在这个区间，编码器得换。会场自带的那种几千块硬编盒子，缓冲策略是写死的，压不下去。得上带 zerolatency 预设、能手动锁 GOP 的机器，采购价一万八到三万，租一天六百到九百。

GOP 是这一档最容易翻车的参数，设长了首帧慢，设短了码率飙。这里面门道不少，直播推流的 GOP 参数怎么设才稳 里写得比较细，我不重复。

还有一笔隐性账：为了降缓冲，回源请求会变密，回源带宽跟着涨。有客户拿着账单来问我怎么多了一千多，直播回源带宽为什么总是超预算 说的就是这个坑。

另外 RTMP 有个老毛病，走 TCP 就躲不开重传队头阻塞。会场网络一抖，画面不是花屏而是直接停住，等积压的包补齐了再猛追一段。追的那几秒音画不同步，观众看着比卡顿还难受。所以这一档我们通常会同时配一路备线，主线抖了就切，切换逻辑本身也有讲究。

1.2 秒档：SRT 上专线，从这里开始真花钱

SRT 基于 UDP 加 ARQ 重传，抗丢包能力比 RTMP 强一大截，公网上 3% 丢包还能稳住画面。我们实测端到端 1.1 到 1.4 秒。至于 SRT 为什么值得换，SRT协议凭什么取代RTMP成为专业推流首选 讲得挺清楚。

但 SRT 只解决传输，不解决出口。会场那条 200 兆共享宽带，晚高峰能被隔壁写字楼吃掉一半。要稳就得拉临时专线，100 兆点对点按天算，一天四千二到六千八，还得提前七个工作日报装。

再加边缘节点。默认调度可能把观众甩到两千公里外的节点上，多出来的物理时延光速都救不回来。指定区域边缘这一项，一场加两千一左右。

SRT 的延迟其实是可调的。latency 参数设 120 毫秒，抗丢包能力弱但更快；设 800 毫秒，链路再烂也能兜住，代价是端到端多出大半秒。我们的习惯是开播前跑二十分钟丢包测试，按实测丢包率的三倍去反推这个值，而不是照文档默认的 120 毫秒直接用。

这档一场下来，比 3 秒档多花一万二上下。摄行科技给客户报到这一档时，我一般先问：您这场有跨会场问答吗？没有就别上。

800 毫秒档：WebRTC 的并发授权才是大头

WebRTC 是目前商用能落地的最低延迟方案，协议细节在 W3C 的 WebRTC 规范 里写得很全。实测端到端 380 到 820 毫秒，具体看观众网络。

麻烦在于计费方式变了。HLS 按流量算，WebRTC 按并发路数授权，一路一路地卖。三千人同时在线就是三千路，主流云厂商每路每小时 0.06 到 0.11 元浮动，一场三小时下来六百到一千。听着不多？把回放、多码率、备用线路都算进去，翻两三倍很正常。

兼容性更烦人。老版本浏览器、部分政企内网的白名单策略、某些安卓定制系统，都可能直接连不上。我们的做法是 WebRTC 打头、HLS 兜底，双路并发，成本再叠一层。这种混合架构怎么取舍，混合云直播架构怎么兼顾安全与弹性 里有更完整的说法。

四档摆一起看直播低延迟优化的增量成本

从 1.2 秒到 800 毫秒，省下 400 毫秒，多掏九千多。这笔账值不值，得看场景。

我在西南一个会展中心踩过的坑

今年 3 月 6 号早上七点四十，西南一个会展中心。客户咬死要 800 毫秒，理由是"领导要感觉不到延迟"。我们照办，WebRTC 全套上齐。

结果那天出问题的不是延迟，是声音。会场临时电源不稳，调音台跟着抽了一下，主话筒哑火 3.2 秒。观众端画面倒是快，800 毫秒实时看着一个人张嘴没声。散场后甲方那位负责人的脸色，我到现在还记得。当时我脸都绿了，蹲在满是线缆的走线槽边上啃半盒凉透的盒饭，机房那台老风机嗡嗡响，脑子里就一个念头：这钱花错地方了。

后来复盘算过账，那两万多要是分一半做音频冗余，双备份话筒加一路独立小电源，加起来不到五千，这事故根本不会发生。

那 400 毫秒的钱不如花在音频冗余上

这就是我最想说的反常识结论：大多数企业会议直播根本不需要 800 毫秒。

观众看会议直播的容忍阈值，比行业想象中高得多。我们做过一轮小范围回访，纯观看场景下 1.5 秒以内没人能感知出延迟；就算到 3 秒，也只有做互动问答时才会觉得别扭。真正让观众骂人的从来不是慢半秒，是卡顿，是花屏，是听不清人说话。

音频这条线的投入产出比高得离谱。一路备份话筒加一台独立小电源，成本不到两千，能挡掉八成以上的翻车。而那 400 毫秒的延迟收益，除了让甲方在验收单上打个勾，实际感知几乎为零。

延迟指标在行业里怎么定义，中国通信标准化协会 那边有相关技术文件可以查，看完就明白所谓"零延迟"是个营销词，物理上不存在。摄行科技出方案报价时，会把这一栏单独列出来让客户自己勾，而不是默认往最贵那档推。

所以定档之前，有几个问题得先问自己。有没有实时互动？有连麦、抢答、跨会场对话，往 1.2 秒档以上考虑；纯单向播，8 秒或 3 秒足够。观众端环境什么样？政企内网多、老旧设备多，WebRTC 连接成功率会掉，硬上不如老实做兜底。预算天花板在哪？摄行科技的经验是，先把总预算的 15% 划给音频和电源冗余，剩下的再谈延迟，事故率会明显低一截。

这套直播低延迟优化的定档逻辑，说白了就是别为了参数好看去买用不上的东西。我们内部有个不成文的判断标准：如果这场会取消了低延迟档，观众体验上说不出第二条差别，那这钱就该省。

要报价可以直接找我们聊

延迟这事儿没有标准答案，得看会场、看观众、看预算。摄行科技可以按您这场的实际情况先做一次现场勘查，把四档方案的报价和风险都摆出来，您自己挑。手上有会场图纸和网络情况的话发过来，我们先看，一般两个工作日内出方案。想聊直播低延迟优化怎么定档的，随时找摄行科技。

#摄行科技