一、OBS集成SRT时的常见配置问题

很多人刚开始用OBS搭低延迟直播，第一反应就是选SRT推流，但实际操作中总遇到各种问题，这些问题大多不是SRT本身不行，而是配置没踩对节点，我整理了最常见的三类坑。

1.1 网络配置错误导致无法建立连接

比如有人随便找个IP填进去，或者服务器的IP写错了，或者用了内网IP但推流端在外面，这种情况就像你给外卖员写了个不存在的地址，外卖员永远到不了。还有人搞混了SRT的推流和监听模式，OBS作为推流端，要填服务器的公网IP和SRT监听端口，要是反过来填成本地端口，肯定连不上。我之前踩过的坑就是，把家里的内网IP当成服务器IP填了，折腾半小时才反应过来是服务器用的是公网IP，内网IP只有本地才能用。

1.2 端口占用或防火墙拦截

这是第二个重灾区，比如你填的端口10000，已经被电脑上的其他软件占了，或者服务器的防火墙没开这个端口，就像快递站的门没开，你填了地址也没法送。举个实际例子：我之前在公司用云服务器做SRT直播，第一次配置时没开防火墙的UDP端口，结果OBS一直报错连不上，后来用命令firewall-cmd --list-all检查，才发现端口10000根本没放行，手动加了规则后才正常。还有一种情况是，本地电脑的端口被其他进程占了，比如用了两个SRT工具同时监听同一个端口，换个不冲突的端口就行。

1.3 OBS SRT参数配置混乱

OBS里的SRT设置里有几个关键参数，比如“延迟（Latency）”“最大带宽”“ payload size”，很多人直接抄网上的乱配，比如把延迟设成10ms，结果推流几秒钟就断，因为SRT的延迟是指两端等待的最大时间，太小的话遇到网络波动就会丢包断开。还有人把最大带宽设得比实际上传速度还高，比如上行只有5Mbps，却设成10Mbps，导致上传卡顿，推流失败。这些参数就像快递的不同规则，延迟小是为了快，但太小会容易丢件，带宽太大也会导致运输堵塞。

二、实现低延迟直播的技术解决要点

既然知道了坑，那怎么才能真的做到低延迟？核心是围绕SRT协议的特性和OBS的优化，还有网络的配合，不是光调参数就行。

2.1 理解SRT协议的核心参数

SRT之所以能低延迟，是它在UDP基础上做了可靠传输，但又不像TCP那样重传所有包，它有个“重传阈值”，超过一定数量的丢包就不重传了，换延迟更小的方式。这里的关键参数有两个：一是延迟（Latency），推流端和接收端的延迟要匹配，比如推流设50ms，接收端也要设50ms，不然就会出现“我等你等得太久”或者“你传得太快我接不住”；二是 payload size，就是每次传的数据包大小，设成和MTU（最大传输单元，一般是1500字节）差不多，太大就会拆包耗时，太小就会包头占比高，增加额外消耗。我之前测过，payload size设1316字节时，SRT的传输效率最高，因为刚好减去SRT头和IP头的大小，不会浪费带宽。

2.2 OBS中SRT的优化配置

OBS里的SRT设置要对应网络情况，比如上行网速是10Mbps，那最大带宽就设成9Mbps（留10%给其他网络用，避免卡顿），延迟设成30-50ms（别低于20ms，不然容易断），缓冲区大小别改默认，除非你确定网络非常差。还有，OBS的“视频编码”要选低延迟模式，比如用NVENC或者x264的“veryfast”预设，这会让编码速度更快，减少推流延迟，就像你写作业用最快的笔，能少等很久。另外，OBS的“输出”里的“延迟帧”要设成0，别留多余的缓冲，这能直接降低延迟。

2.3 网络层面的低延迟准备

光调OBS和SRT没用，网络是基础，比如推流端和服务器之间的路径要尽量短，别跨太多路由器，最好用有线连接（WiFi延迟忽高忽低，不适合低延迟），还要避开网络高峰时段，比如晚上7-10点，很多人上网就会卡顿，延迟上去，低延迟直播就白搭。还有，服务器要选离观众近的CDN节点，或者用单独的公网IP，别和其他服务共用，避免带宽被抢。比如我做游戏直播时，选的是离自己最近的阿里云节点，推流延迟从150ms降到了80ms，效果很明显。

三、实际应用场景与完整示例

光说不练假把式，我给两个完整示例，都是我实际用过的，保证能跑通。

3.1 示例：OBS推流到SRT服务器（技术栈：OBS Studio 29.1 + SRT协议）

第一步准备服务器，用的是阿里云轻量应用服务器，先安装SRT接收端，用命令行执行以下代码：

# 安装SRT接收端（基于Linux系统，示例用CentOS）
yum install srt -y
# 启动SRT服务器，监听10000端口的UDP连接
srt-live-server -l :10000

然后打开OBS，在“设置-输出-流”里，协议选“SRT”，服务器填服务器的公网IP，端口填10000，流键随便填个名字（比如“live/test”），然后在高级配置里输入以下参数：

// OBS中SRT的高级配置参数（需手动输入的部分）
{
  "srt_latency": 50,  // 延迟设50毫秒，符合中等网络的低延迟要求
  "srt_max_bitrate": 9000000,  // 最大带宽9Mbps，对应上行10Mbps的情况
  "srt_payload_size": 1316  // 1316字节，刚好避开IP和SRT头的额外消耗，避免拆包
}

最后启动推流，服务器端就能收到流了，此时延迟一般在100ms以内，完全满足互动直播的要求。

3.2 示例：调试低延迟的关键步骤

要是推流后延迟高，怎么排查？第一步，先测推流端的上传速度，用speedtest工具测，要是没到设定的最大带宽，就把最大带宽调低（比如上行只有5Mbps，就设4Mbps）；第二步，查网络路径，用traceroute命令查推流到服务器的跳数，超过10跳的话，换个离你近的服务器；第三步，把OBS的视频码率调低，比如从9Mbps降到6Mbps，减少编码时间，也能降低延迟。还有个小技巧，把OBS的“输出-延迟帧”设成0，别留缓冲，这能直接减少10-20ms的延迟。

四、技术优缺点与注意事项

4.1 应用场景

OBS+SRT的组合适合什么场景？比如游戏直播的互动连麦（需要延迟低，观众能马上看到主播操作），或者远程制作的直播（比如户外直播，导演要马上看到画面），还有教育类的互动直播，延迟太高互动就没意义了。另外，它也适合户外手机直播，因为SRT在有轻微丢包的网络下也能保证可靠传输，不会像RTMP那样容易断流。

4.2 技术优缺点

优点是SRT本身是开源免费的，比传统的RTMP延迟低很多（RTMP一般是3-5秒，SRT能到100ms以内），而且在有丢包的网络（比如4G/5G）也能保证传输稳定，不会卡顿；缺点是对网络要求比RTMP高，要是丢包率超过5%，SRT也会出现卡顿，而且需要手动配置参数，不像RTMP那样一键就能用，适合有一定基础的开发者。

4.3 注意事项

第一，端口一定要在服务器和本地都开放，Linux服务器要开防火墙端口，比如用firewalld的话，执行firewall-cmd --add-port=10000/udp --permanent，然后firewall-cmd --reload；第二，延迟参数推流和接收端必须一致，不然要么延迟高要么断流；第三，别用代理或者VPN推流，会增加额外的延迟；第四，OBS要更新到最新版本，旧版本的SRT支持不好，容易出现连接失败的问题。

五、总结

其实OBS集成SRT的核心就是把每个参数和网络情况对应好，别乱抄网上的配置，还要注意端口和防火墙的问题，低延迟的关键是参数匹配和网络优化，不是光靠调OBS的设置。只要把这些点踩对，就能做出延迟在100ms以内的直播，满足互动需求。很多新手觉得低延迟直播是靠高配置，其实不然，我之前用旧的笔记本电脑（i5-8代，16G内存）推流，只要参数对，延迟也能达到90ms，所以核心还是配置和网络，不是硬件。