聊活动直播推流协议这事，现场执行的人和写方案的人经常不在一个频道上。方案里写"采用SRT保障弱网稳定"看着很专业，到了现场才发现甲方指定的平台压根不收SRT，还得在中间加一层转封装，多一层就多一层出事的可能。
2025年4月，我们在合肥滨湖国际会展中心接了一场装备行业的展中活动。场馆自带网络在开展当天被两万人挤到几乎不可用，运营商临时给的4G聚合上行只有稳定4Mbps上下，丢包率在3%到11%之间跳。那天我们同时开了三路做对比，数据后面细说。
三种协议到底差在哪
RTMP是老将，基于TCP，几乎所有国内平台都收。它的问题在于TCP的重传机制在丢包时会拖累整体吞吐，一旦网络抖起来，画面就是一卡一卡的爬。
SRT走UDP，自己实现了一套带前向纠错和选择性重传的机制，可以设置延迟缓冲区（latency）来换稳定。缓冲设500毫秒，它就有500毫秒的窗口去补丢掉的包。代价是端到端延迟增加。
WebRTC也是UDP底子，为实时通话设计，延迟能压到一秒以内甚至几百毫秒。但它对拥塞的应对策略是主动降码率，网差的时候画质会肉眼可见地糊。
摄行影像内部一句话概括活动直播推流协议的差异：RTMP求兼容，SRT求稳，WebRTC求快。三者没有谁全面胜出，看场景。
合肥那场的实测数据
同一路信号源，同时推三条，接收端在杭州机房。测了连续四十分钟。
| 协议 | 平均端到端延迟 | 卡顿次数 | 累计卡顿时长 | 画质稳定性 |
|---|---|---|---|---|
| RTMP | 3.2秒 | 27次 | 4分11秒 | 码率大幅波动 |
| SRT（latency 800ms） | 4.6秒 | 2次 | 9秒 | 基本恒定 |
| WebRTC | 0.9秒 | 6次 | 41秒 | 分辨率三次下调 |
SRT在这种丢包环境下的表现确实碾压，代价是多了一秒多延迟。那场活动没有连线互动，延迟无所谓，所以我们主链路走SRT，备链路留RTMP。
要提醒的是，这个数据只在丢包环境下成立。同年5月在南京一场网络条件极好的产品发布现场，我们又测了一轮，三种协议的卡顿次数都是0，SRT的延迟优势反而变成了劣势。
什么时候必须上SRT
判断标准就一条：上行链路是否可能丢包。摄行影像这几年在活动直播推流协议上的取舍，基本都绕着这条线走。
具体到现场，有四种情况我们会直接锁定SRT。一是用4G/5G聚合设备推流，无论运营商说得多好听，移动网络的丢包是必然的。二是展馆、体育场这类人员密集场所，无线环境被挤爆是常态。三是跨省甚至跨国的长距离传输。四是甲方给的网络是酒店或者写字楼的公用宽带，这种线路白天什么情况完全看运气。
摄行影像现在的标配是编码器上同时开SRT主推和RTMP备推，两条链路同时在线，接收端做自动切换。多这一条备份增加的成本很有限，但救过我们不止一次。相关的链路设计我们在直播知识里写过更细的拆解。
WebRTC的适用面比想象中窄
很多人被"超低延迟"四个字吸引，觉得应该全面上WebRTC。实际做下来，它真正不可替代的场景只有两类。
一类是有实时连线的活动。异地嘉宾要跟现场主持对话，三秒延迟就没法聊，必须压到一秒内。另一类是需要即时反馈的互动，比如现场大屏要显示线上投票结果，延迟高了观众体验会很割裂。
除此之外的绝大多数活动直播，延迟三秒和延迟零点九秒，观众根本感知不到差别。但WebRTC带来的麻烦是实打实的：平台支持度参差不齐、大规模分发成本高、网络一差就降分辨率。
2025年6月徐州一场文旅节目，甲方坚持要WebRTC，理由是"看起来更先进"。我们照做了，结果户外信号一波动，画面从1080p掉到540p，甲方看到手机上糊掉的画面比谁都急。后来那场中途切回了SRT。
编码参数得跟着协议改
这一步很多人漏掉。选了活动直播推流协议不调参数，等于白选。
走SRT的时候，latency参数不是越大越好。经验值是设成往返时延（RTT）的三到四倍。RTT如果是60毫秒，latency设200到250毫秒就够，设成2000毫秒纯属浪费延迟预算。我们习惯先ping一下接收端，拿到RTT再定。
走RTMP的时候，关键是把码率压到实测上行带宽的六成以下。上行测出来10Mbps，码率就别超过6Mbps。TCP在接近带宽上限时的表现会急剧恶化，留够余量比什么优化都管用。
走WebRTC的话，主动限定最低分辨率下限，别让它一路降到360p。大部分编码器都能设，设了之后宁可卡也不糊。这些参数细节在影像课堂里配合截图讲会更清楚。
平台兼容性是硬约束
写方案之前，摄行影像会先确认甲方要推到哪些平台。这个顺序不能倒。
国内主流的几个内容平台，官方推流地址基本都是RTMP，少数支持SRT接入但需要提前申请。如果客户要求同时推到三四个平台，最省事的做法是本地推一路SRT到自建中转服务器，由服务器转成RTMP再分发出去。中转这层可以放在云上，成本一天几十块。
自建服务器要注意备案和合规，涉及公开传播的内容需符合国家广播电视总局的相关管理要求。跨境传输的场景还要额外核对国家互联网信息办公室的规定，别在这上面栽跟头。
一张能直接用的选型表
把两年的项目归拢下来，选型其实可以简化成几个提问。
| 现场情况 | 推荐主协议 | 备链路 | 备注 |
|---|---|---|---|
| 有线专线，无互动 | RTMP | 4G聚合RTMP | 最省事 |
| 有线专线，有连线 | WebRTC | RTMP | 注意平台支持 |
| 移动网络推流 | SRT | RTMP | latency按RTT算 |
| 展馆/大型场馆 | SRT | 4G聚合SRT | 双链路都要备 |
| 户外无固定网络 | SRT | 卫星或多卡聚合 | 码率压到4M以内 |
| 跨省多会场同步 | SRT | RTMP | 中转服务器统一分发 |
这张表摄行影像在内部用了一年多，新人照着填基本不会出大错。特殊情况还是要现场实测，表只能给个起点。
现场怎么验证协议真的在工作
最后说个执行细节。很多团队设完参数就以为万事大吉，其实推流协议有没有按预期跑起来，需要验证。
方法很土但有效：开播前四十分钟，用真实码率推一段测试流，在接收端盯着后台的丢包统计和缓冲区状态看十分钟。SRT的后台一般能看到实时的丢包重传数，如果重传数一直在涨，说明latency设小了。RTMP看不到这么细，就盯缓冲区，缓冲反复清空就是带宽不够。
我们还有个习惯，测试流录一段下来存着。万一正式开播出问题，对比测试录像能很快定位是网络变了还是设备变了。这类现场核对清单在服务问答里整理过一份。
需要帮你定一套推流方案吗
如果你手上有一场活动，场地网络情况不明，不确定活动直播推流协议该怎么定，可以把场地名称、预计人数和甲方指定的播出平台发给我们。摄行影像可以先做一次远程评估，必要时提前去现场测一次上行，测试本身不收费。
已经在筹备中的项目，建议至少提前一周确认平台侧的接入方式，SRT申请通道有时候要等三五天。往期同类项目可以翻案例中心。咨询电话 400-883-2046。
#摄行影像
