延迟低了，网络抖动时补救时间就少了；抗丢包做好，往往又要牺牲缓冲时间，协调两者的核心思路是分层处理编码端加前向纠错、传输端选对协议、播放端做动态缓冲，让每一层都只解决自己该解决的问题。
直播低延迟怎么设置：先搞懂延迟从哪来
很多朋友上来就调缓冲参数,结果延迟没降下来，画面倒先卡了，延迟不是某一个环节的事，它是一整个链条的累积，一个典型直播链路的延迟构成：
- 采集端：摄像头到采集卡或驱动接口，一般几毫秒到十几毫秒
- 编码端：x264硬编或软编，取决于预设，通常几十毫秒到几百毫秒
- 推流端：上传到边缘节点的网络缓冲，几十毫秒到几秒不等
- 分发端：CDN或RTC网络的转发层级，CDN通常到秒级
- 播放端：解码缓冲和抗抖动缓冲，这个环节最容易被忽视
设置之前,先把链条拆开看，如果推流端用的是RTMP，那从协议层面就已经决定了延迟下限RTMP的TCP重传机制对网络丢包很敏感，一丢包就要等重传，缓冲稍微小一点就直接卡顿，行业共识认为，RTMP端到端延迟能做到三到五秒已经算不错的水平，想要再次往下压，就得换协议。
用测速和日志定位延迟瓶颈
延迟高的原因不一定是设置问题,也可能是上行带宽不够，按下面的方式排查：
- 在推流端用ping -t命令观察延迟和丢包率，延迟超过30ms或丢包率超过1%，先找网络原因
- 用OBS的日志功能关闭自动重新连接,记录推流过程中的缓冲时间戳变化
- 播放端抓取首帧耗时,配合服务器侧的拉流日志对比，就知道延迟花费在推流还是分发
低延迟直播和抗丢包怎么平衡：两条技术路线的取舍
谈起低延迟直播,绕不开WebRTC和SRT这两个协议，它们都声称低延迟，但抗丢包的思路完全不同。
WebRTC：谁丢包，谁就要准备好双份数据
WebRTC使用UDP传输,支持前向纠错，通俗讲就是
把数据包复制几份一块发出去，丢了一个，还有副本顶着，不用等重传，这在丢包率5%以内时效果明显，延迟可以稳定压在500ms以内，问题是副本也占用带宽，带宽不够时反而加剧拥塞，丢包率超过15%，WebRTC也会撑不住，画面马赛克、声音断续。
SRT：用重传换低延迟，但不加缓冲
SRT走UDP但加入了ARQ选择性重传,只重传丢失的那部分数据，同时把应用层缓冲做到很低，它跟WebRTC的差异在于：WebRTC用多余的带宽防丢包，SRT用时间换取可靠性，在正常网络下，SRT延迟能做到1秒左右，丢包3%以内时体验稳定，适合对延迟要求没那么极致，但画面完整性要求更高的场景。
协议对比，按场景去选
| 协议 | 基准延迟 | 抗丢包方式 | 弱网表现 | 适用场景 |
|---|---|---|---|---|
| RTMP | 3-5秒 | TCP重传 | 丢包即卡顿 | 传统推流、兼容性要求高 |
| SRT | 8-2秒 | 选择性重传 | 中高丢包仍可用 | 活动直播、卫星回传替代 |
| WebRTC | 2-0.8秒 | 前向纠错 | 低丢包在线清 | 连麦、互动、一对一 |
三者之间没有绝对优劣,关键是先明确你的直播形式，纯粹的广播式直播，用SRT或RTMP加边缘节点就够；需要双向互动的，必须WebRTC或低延迟RTC方案。
直播延迟和卡顿先解决哪个：不同场景的取舍逻辑
延迟和卡顿在实际直播中是一对跷跷板：压延迟就减少缓冲，画面遇到抖动就卡；保流畅就加缓冲，延迟跟着上升，先解决哪个，要看观众在意什么。
电商直播：延迟可以让步，卡顿绝不能忍
观众在直播间下单的时候,主播其实已经说完了好几句话，据统计，电商直播的延迟容忍度普遍在5秒以内，但卡屏超两秒就会有人退出，这种情况下锁帧率、加大播放缓冲优先级更高，延迟只要不出圈就可以不管，把精力放在CDN调度和边缘节点的覆盖上。
在线连麦和互动课堂：延迟是核心矛盾
嘉宾连麦这种场景,半秒的延迟都能让对话重叠，这时候抗丢包反而要让位给全链路低延迟调度，WebRTC的拥塞控制算法本身就是为互动而设计的，它会主动牺牲画质来保延迟和音频清晰度，丢包严重时降低分辨率，而不是增大缓冲，先保声音和交互节奏，视频画质稍降观众能接受。
赛事和演出直播：两者都要，靠多码率阶梯
体育赛事延迟超过10秒就容易被剧透,同时画面不能糊，多码率阶梯是主流做法：同一路流推四个档位，播放端根据网络状况自动切换，观众网络差时降到低码率档位，延迟基本不变，代价是清晰度，这个场景下hls的延迟通常在10-20秒，换用LL-HLS可以压缩到3秒左右，代价是服务器成本上升。
低延迟直播推流的实操配置：从OBS到服务器
纸上谈兵说完,落到实际操作，假设你现有设备是一台普通PC，推流工具是OBS，服务器位置在国内，按照下面这几个步骤优化直播低延迟设置：
第一步：OBS输出参数这么调
- 输出模式选高级,关键帧间隔设为2秒，B帧关掉
- 速率控制选CBR,码率按上行带宽的70%设置，留出余量
- 在高级选项里把播放缓冲关闭,将最大内存占用调到32MB以下
- 编码器用NVENC或x264的medium档,不要追求fastest，压缩效率低反而更容易断流
第二步：换一个国内直播低延迟节点
国内直播低延迟服务器选择重点看节点的BGP线路和到本地的路由距离,用tracert命令测试你的上行链路，超过15跳的节点直接排除，很多推流服务商提供了就近接入的首节点，把推流地址里的机房标识换成离你最近的区域代码，延迟能降不少，有条件就用云厂商的全球加速链路，把推流上行分发给边缘节点，不需要远距离绕行。
第三步：抗丢包的最后一层播放器缓冲
推流端调整完毕,播放端的缓冲策略也不能忽视，播放器缓冲参数设置得好，能弥补传输端的不足：
- 初始缓冲设为500ms,保证首帧秒开
- 播放中缓冲上限设为1.5秒，超过即触发快进补偿
- 保守模式下开启丢帧策略,音频优先，丢视频帧保节奏
抗丢包的隐藏大招：网关重传和冗余编码
除了前向纠错和ARQ,还有两个容易被忽略但效果明显的抗丢包手段，其一是服务端的丢包重传网关，播放端反馈丢包信息后，网关直接补发，不需要客户端重建连接，其二是冗余编码，把原始码率提高20%做FEC，丢包时能直接恢复约3%-5%的数据，这两种方式在大型直播平台中已经是标配，自建的话用SRS或Janus的开源实现都能搭起来。
核心矛盾没有完全消灭的办法，只能用一个问题覆盖另一个，延迟和卡顿的平衡点，由直播的场景属性决定，技术手段只是把这个平衡点移动到更精确的位置。
直播低延迟常见问题
直播低延迟怎么设置最快见效？
最快的调整是改动两处：一是播放端把缓冲上限从默认的3-5秒压到1秒以内，第二是推流端把帧间隔从5秒改成2秒，这两步在大多数平台都能有效降低延迟和开播时的首帧等待，但可能轻微增加弱网下的卡顿概率。
WebRTC和RTMP延迟差距具体有多大？
常规公网条件下,WebRTC的端到端延迟通常在300-800毫秒，RTMP经过CDN分发后延迟普遍在3-8秒，差距主要的来源是协议栈的丢包处理机制不同，WebRTC用UDP加前向纠错，RTMP用TCP重传，后者遇到网络抖动需要反复等待。
低延迟直播方案价格贵不贵？
自建方案中,SRT推流加上开源媒体服务器的成本主要体现在服务器带宽费上，国内主流云厂商的BGP带宽价格按流量计费比普通CDN贵，使用公有云的低延迟直播产品，通常有基础套餐加按时长计费的叠加模式，整体成本比传统RTMP方案高出三分之一左右，比专线视频传输的硬件方案便宜得多，具体到月的开销，通常取决于并发和码率。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/714099.html
