协议选错，现场就尴尬
做活动直播久了，我发现一个怪现象：同样两路直播，一路稳得没存在感，另一路动不动卡顿掉帧。很多人以为是网络的问题，其实很多时候，问题出在推流协议上。今天聊点偏技术的——RTMP、SRT、WebRTC 三种主流协议，我一般在什么场合选哪个。
RTMP 稳网省心
它是直播圈的老前辈，十来年一直在用，绝大部分平台和编码器都认它。优点是稳、兼容好、门槛低，手里的设备基本都能直接推。缺点是它基于 TCP，网络一抖会死等重传，结果就是画面卡住、缓冲。所以 RTMP 我一般用在场地网络稳、有专线的室内活动，比如发布会、年会，图个省心。它是那种不出彩但不出错的稳妥选项。
SRT 抗丢包保稳
这两年我用得越来越多。它的特点是抗丢包——网络不理想时，靠前向纠错和重传把信号拼回来，画面不容易断。户外、跨场地、走公网这类网络不太干净的场合，SRT 几乎是我的默认选项。有次乡镇广场活动，场地只有普通宽带，用 RTMP 准卡，换成 SRT 之后整场顺下来。代价是两边设备都得支持 SRT，配置比 RTMP 麻烦些，加密传输也更值得留意。
WebRTC 低延迟互动
它主打低延迟，能做到亚秒级，观众几乎和现场同步。适合需要实时互动的场合——比如线上连麦、抽奖问答，延迟高了体验就垮。但它对带宽和服务端要求高，大规模活动直接用得少，更多是配合专门的低延迟服务。如果这场直播不需要互动，硬上 WebRTC 反而是给自己加负担。
码率也要跟着协议调
协议和码率是搭档，不是各管各的。RTMP 走稳网，码率可以给得足，画质更讨好；SRT 走弱网，码率要留余量，别把本来就不宽裕的带宽吃满，否则抗丢包的优势被高码率抵消；WebRTC 对带宽敏感，码率太高延迟就上去了。所以定协议的同时，要把码率区间一并框定，别等到现场再拍脑袋。
怎么判断自己该用哪个
给客户出方案，我通常先问三个问题：场地网络稳不稳、要不要实时互动、两边设备认不认这个协议。三个答案一组合，协议基本就定了。稳网室内、无互动，RTMP；网络没底、户外跨城，SRT；要连麦抽奖、低延迟，WebRTC。别被新协议迷住眼，也别守着老协议不放，按场地挑才是正路。
平台支持对照
- RTMP：几乎通吃，主流平台和小平台都接，兼容性让人放心。
- SRT：主流云平台大都已支持，个别小平台未必认，定方案前要确认。
- WebRTC：更挑服务端，通常需要专门的低延迟服务配合，不是插上就用。
两个常见误区
- 误区一：协议越新越好。WebRTC 虽新，但大规模稳网活动用它反而添负担。
- 误区二：SRT 能解决一切弱网。它抗丢包，但带宽本身不够时，降码率仍要做。
我的判断逻辑其实很清楚：室内稳网用 RTMP 图省心；网络没把握、户外跨城用 SRT 保稳；要实时互动、低延迟才上 WebRTC。协议不是越新越好，匹配场地才是关键。定方案前，先确认你推流的那一端认不认这个协议，别到现场才发现对不上。
开播前的推流测试
定好协议不等于万事大吉，开播前一定要先推一分钟测试流，看接收端实际收到的画面和延迟。有次方案定了 SRT，现场一测发现云平台那一侧没开 SRT 接收，临时切回 RTMP 才救场。所以协议选定后，务必用真实链路跑一遍，确认两端握手成功、码率扛得住，再正式开播。测试流花不了几分钟，却能挡掉大部分现场翻车。
—— 摄行影像
延伸：RTMP、SRT、WebRTC，活动直播推流协议我这样选 的实操落地
在直播技术的实际落地中，「RTMP、SRT、WebRTC，活动直播推流协议我这样选」是客户咨询的高频环节。结合摄行影像在全国 60 余个项目的现场经验，下面把流程、设备与避坑点一次说清，照着做少踩坑。
平台差异
各平台推流地址与码率上限不同，OBS 配置分别保存。视频号对私域友好，抖音公域流量大，B站适合长内容沉淀。同一场直播多平台推，配置要逐个核对。
我们维护一份平台参数对照表，开播前逐项核对推流地址、码率上限与画质要求，避免某平台被压缩或推流失败，多平台分发才稳。
互动与数据
抽奖、投票、留资提升停留与转化。复盘看峰值、停留、分享，用数据迭代下一场的内容与节奏设计。
互动不是点缀，是留住人的核心手段。我们在直播中每 5–8 分钟埋一个互动点，并实时监控互动曲线，发现掉人立即切下一个钩子，把留存数据做厚。
码率与画质平衡
码率过低糊，过高卡。先测上行带宽，预留 30% 余量。弱网环境宁可降码率保流畅，也别赌带宽导致全程卡顿。
观众对卡顿的容忍度远低于对画质瑕疵的容忍度。我们的经验法则是「流畅优先」：宁可 720p 流畅，也不要 1080p 反复缓冲，留存数据会诚实反映这一点。
平台差异
各平台推流地址与码率上限不同，OBS 配置分别保存。视频号对私域友好，抖音公域流量大，B站适合长内容沉淀。同一场直播多平台推，配置要逐个核对。
我们维护一份平台参数对照表，开播前逐项核对推流地址、码率上限与画质要求，避免某平台被压缩或推流失败，多平台分发才稳。
