这个标题对我来说太有发言权了。团队直播间从单平台切到多平台分发到现在用服务器做多路推流刚好满一个月。这一个月里我踩过的坑比过去一年直播踩的还多带宽被打满、平台断流、时间戳错乱导致音画不同步、推流进程半夜自己死掉……今天把这些经验完整复盘一遍给正准备做多路推流的朋友们一个参考。先说清楚多路推流能解决什么问题。以前做直播要么用OBS直接推流到单一平台要么在电脑上装各种虚拟摄像头、分身工具把画面复制到多个直播软件里再分别推出去。前者只能覆盖一个平台后者对电脑性能消耗极大笔记本用户推两路就开始风扇狂转、掉帧。多路推流的思路是只在一台机器上做一次采集和推流把码流推到一台中间服务器上由服务器再分发到各个直播平台。这样做的好处很明显——采集端压力小、网络波动容错高、还能在服务器侧做转码和录制。这套方案适合谁适合需要把同一路画面同时分发到多个平台的主播、做直播带货的运营团队、做线上活动转播的机构。如果你是个人主播只推一个平台完全用不上但只要你开始做多平台分发而且对稳定性有要求这篇内容就能帮你少走至少一个星期的弯路。1. 多路推流的整体架构与方案选型多路推流这件事表面上看只是“一个画面发到多个地方”但真正落地时核心问题会变成三件事谁来做分发、用什么协议分发、分发到哪些平台。这三个问题决定了整个系统的复杂度。1.1 方案选型为什么最终选了服务器中转我先把自己试过的路都列出来方便你对照自己的情况做取舍。第一种纯软件方案也就是在直播电脑上多开OBS或用OBS的多路输出插件。这个方案的优势是零成本、配置简单几分钟就能跑起来。缺点是CPU占用直接翻倍一路1080p编码已经吃掉不少性能两路三路同时编码很容易导致帧率不稳。另一个隐患是电脑本身的网络出口通常不够稳定家用宽带的公网体验并不好高峰期上传一大所有平台一起卡。第二种用直播平台自带的转播功能或云厂商的直播分发服务。这个方案稳定性好但受制于平台规则比如有些平台会限制转播码率、需要在不同平台分别配置推流域名而且一般都要付费或者受平台等级影响。第三种自建服务器中转也就是我最终选的路。具体做法是租一台带宽足够的云服务器装Nginx和RTMP模块或者用SRS这类开源流媒体服务器接收来自OBS或FFmpeg的原始推流再通过服务器向所有直播平台分发。这个方案的特点是可玩性极高你能控制转码参数、推流节奏、断流重连策略但前提是你对Linux和流媒体协议有一定基础。我最终选了自建服务器中转核心原因是团队需要同时在五个平台开播两个主流短视频平台、一个视频平台、一个电商平台和一个海外平台。这种规模下电脑端的软件方案完全不现实云服务的成本又不低自建服务器虽然要花点心思配置但算下来一个月服务器费用比云直播服务便宜一大截而且调度非常灵活。1.2 多路推流的链路拆解与核心角色先说清楚整个链路里都有哪些角色。采集端就是你的编码推流设备通常是直播电脑上的OBS负责采集摄像头、麦克风、桌面画面编码成H.264或H.265视频流通过RTMP协议推送到中继服务器的指定端口。中继服务器这是多路推流系统的核心。它主要负责接收上游的推流然后把这一路流复制成多路分别转发到各个目标平台。这个“复制”不是简单拷贝因为每个平台的推流地址、流密钥、甚至编码兼容性要求都可能不一样你需要针对每个目标平台单独配置一个转发点。目标平台就是你要分发到的各个直播平台。它们各自的直播服务会给你一个推流地址RTMP地址你的服务器向这些地址发流即可。这套架构最关键的一点是所有编码压力都在采集端中继服务器只做转发和轻量级处理。所以服务器的CPU不需要特别强但带宽和稳定性必须过硬。我给自己的服务器配的是4核CPU、8GB内存、50Mbps公网带宽。如果你要推4路以上的高清视频至少准备100Mbps带宽否则很容易在高峰时段被打满。这个链路里还有两个容易被忽略的细节。一个是协议选择目前主流直播平台基本都接受RTMP推流但海外平台有的更推荐SRT或RTMPS如果你要推海外平台需要先确认对方支持的推流协议。另一个是授权问题绝大多数平台都允许你用合法的推流软件进行推流但通过服务器中转本质上相当于使用了第三方推流工具个别平台会有风控机制需要你关注平台规则尽量使用合规的配置方式。2. 部署实操从零搭建服务器并完成多路分发选择和搭建往往只花半天真正折磨人的是把每一路推流调通、调稳。这一章我把服务器的部署流程、关键参数和踩坑点全部写清楚你照着复制就能少走弯路。2.1 服务器初始化与Nginx-RTMP模块编译基础环境我用的是Ubuntu Server 22.04 LTS。第一次部署时我图省事直接用apt install nginx装了个干净Nginx结果发现默认包里没有RTMP模块测试推流时服务器半天没响应。后来才明白Nginx官方mainline版本本身不带RTMP模块必须自己编译安装或安装带RTMP模块的第三方包。推荐做法是用源码编译。下面是一套稳定的安装流程# 安装编译依赖 apt update apt install -y build-essential libpcre3-dev libssl-dev zlib1g-dev # 下载Nginx源码和RTMP模块源码 cd /usr/local/src wget http://nginx.org/download/nginx-1.24.0.tar.gz git clone https://github.com/arut/nginx-rtmp-module.git # 解压并编译 tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure --with-http_ssl_module --add-module../nginx-rtmp-module make -j4 make install编译安装后Nginx默认会装在/usr/local/nginx目录下。启动前先编辑/usr/local/nginx/conf/nginx.conf在文件末尾追加RTMP配置块rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # 允许来自内网或指定IP的推流 allow publish 127.0.0.1; allow publish 你的本机内网IP; deny publish all; } # 转发到平台A application relay_a { live on; record off; } # 转发到平台B application relay_b { live on; record off; } } }listen 1935是RTMP的默认端口chunk_size 4096是分块大小这个值不是越大越好我用4096和8192分别测过推流延迟差别不大但4096兼容性更好。先别急着同时配置多个application我后面会解释为什么用这种方式做多平台分发容易踩坑并给你更稳妥的替代方案。2.2 通过FFmpeg实现多路分发这步最关键一开始我天真地认为服务器收到一路RTMP流之后再用Nginx-RTMP模块的push指令复制到各个平台地址就行。一个典型的错误配置是application live { live on; record off; push rtmp://platformA.com/live/streamKeyA; push rtmp://platformB.com/live/streamKeyB; push rtmp://platformC.com/live/streamKeyC; }这个配置的思路没错但有个严重的隐患Nginx的push指令对所有平台使用同一个流媒体处理管线只要有一个平台的推流地址返回超时或拒绝连接整个Nginx worker进程就可能被卡住导致其他平台也一起断流。我第一天上线就被坑了一次平台A的推流密钥填错结果平台B和平台C的流在几分钟内陆续出现频繁卡顿。正确的做法是服务器只负责收流每个平台的分发任务交给独立的FFmpeg进程单独处理。这样哪怕一路推流失败其他路完全不受影响。具体架构是在Nginx里只保留一个application接收OBS推流然后为每个目标平台分别写一个FFmpeg转推命令。示例命令如下# 从服务器本地接收流转推到平台A ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c copy -f flv rtmp://platformA.com/live/streamKeyA \ -loglevel error -y # 转推到平台B平台B要求视频参数稍有不同可加转码参数 ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c:v libx264 -preset veryfast -b:v 2500k \ -c:a aac -b:a 128k -f flv rtmp://platformB.com/live/streamKeyB \ -loglevel error -y关键点在于每个FFmpeg进程只负责一个目标平台并且用-c copy进行流复制不做转码这样CPU占用极低同时彼此隔离一个进程挂了重启它就行不影响其他路。还要注意一个细节每个平台的推流地址和流密钥不能写死在前台命令里最好写成独立的shell脚本方便修改和重启。日志也需要单独存文件排查问题时会省很多事。2.3 用srs替代Nginx的另一种选择如果你觉得NginxFFmpeg的组合配置起来有点繁琐可以试试SRS这个专门为直播场景设计的流媒体服务器。SRS对RTMP、SRT、HLS、WebRTC等协议的支持更原生很多商用直播系统的底层就是它。SRS的部署方式很简单wget https://github.com/ossrs/srs/archive/refs/tags/v5.0.0.tar.gz tar -zxvf v5.0.0.tar.gz cd srs-5.0.0 ./configure --prefix/usr/local/srs make make install配置转发时SRS用vhost和cluster做分发也支持forward指令。比如把收到的live/origin流转到多个平台vhost __defaultVhost__ { forward { enabled on; backend rtmp://platformA.com/live/streamKeyA; } forward { enabled on; backend rtmp://platformB.com/live/streamKeyB; } }SRS的优势是并发处理能力强、内置监控API劣势是对新手来说配置文件的概念比Nginx多。我的建议是团队里有人熟悉Nginx就选NginxFFmpeg想学一套更专业的流媒体服务器就上SRS两者没有本质差别。3. 带宽、延迟与音画同步影响直播质量的三个关键参数服务器搭起来了流也推起来了但如果你直接开播很快就会发现问题观众反馈画面卡顿、声音对不上、延迟忽高忽低。这些问题几乎都和带宽、延迟、时间戳这三个参数有关。3.1 带宽计算与上行限制不是你带宽大就能推高清很多人在规划服务器时直接把带宽理解成“我按最大码率算就行”这是个大坑。多路推流的带宽消耗不只是直播码率本身还有协议开销和峰值波动。先看一个基础计算公式一路1080p踩在3500Kbps码率、音频128Kbps总码率大约3628Kbps。如果你要推5路同样的流理论带宽需求是总码率 单路码率 × 路数 3628Kbps × 5 ≈ 18140Kbps ≈ 18Mbps但这是理想值实际还要考虑RTMP协议本身有握手和包头开销约占5%-10%平台端偶尔会做短时间缓存导致服务器发送速率波动还有一些平台的网络节点在高峰期会回源拉流影响你的上行。所以我推荐一个经验公式实际带宽需求 总码率 × 1.3。五路流至少需要24Mbps带宽再加上服务器本身的管理流量。我第一周开的服务器带宽是30Mbps五路流时CPU占用不高但带宽利用率长期在80%以上观众端偶尔出现卡顿后来升级到50Mbps才完全解决。下表是不同规格的判断参考推流路数单路码率Kbps理论总码率推荐带宽3路25007.5Mbps10Mbps3路800024Mbps35Mbps5路350018Mbps30Mbps5路600036Mbps50Mbps10路250030Mbps45Mbps还要提醒一点大多数云服务器的带宽是按“下行上行”计费的但实际对直播来说上行才是瓶颈。购买时不要只看宣传的百兆带宽要确认上行的保证值。如果预算够尽量选按固定带宽计费而不是按流量计费否则多路推流一个月下来流量费可能比服务器本身贵好几倍。3.2 延迟优化与缓存策略直播卡不卡关键在于缓冲延迟就是主播说话到观众听到之间隔了多长时间。多路推流链路比单一平台推流多了一个中继节点延迟天然会增加1到2秒。所以你不能用单路直播的延迟标准去要求多路推流。RTMP协议本身是低延迟协议延迟主要产生于两个环节编码端的GOP关键帧间隔设置以及播放端的缓冲策略。关键帧间隔通常叫GOP是影响直播延迟的核心参数之一。如果GOP设置过大比如10秒一个关键帧观众在切换清晰度或网络抖动缓冲时会长时间看到模糊画面体验极差。我建议OBS里把GOP设为2秒对H.264编码就是keyint2*FPS。比如30帧视频GOP就设为60。这样即便某一路平台出现短暂卡顿恢复起来也快。还有一个容易踩的坑是FFmpeg转推时的-re参数。-re表示按原始帧率读取输入模拟实时推流。但我在写脚本时如果输入源是本地RTMP地址加不加-re其实无所谓服务器收到流本来就是实时的但有些教程会建议在FFmpeg命令里加-re这不但在多路分发时毫无帮助反而可能造成输入缓冲区堆积增加延迟。正确的转推命令不应该加-re。播放端的缓冲策略你控制不了那是各平台播放器自己的逻辑。你能做的是尽量压低源端延迟把平台端的延迟误差控制在可接受范围内。3.3 音画同步问题多路转推最容易忽视的隐藏坑音画不同步是我这一个月里遇到最隐蔽的问题。最开始我以为是平台转码导致的后来发现根源出在FFmpeg转推时的时间戳处理上。很多平台的清洗转码流程在收到流后会根据时间戳DTS/PTS重新整理音频和视频包。如果原始流的时间戳有偏移或跳变平台的转码管道就会出错表现就是音画逐渐不同步有的甚至在开播后10分钟才出现明显偏差。我踩到的一个具体问题OBS推流时音频采样率使用了48kHz视频帧率是30fpsFFmpeg转推时用-c copy直接拷贝音视频数据理论上时间戳不该有问题。但实际监控发现某一路平台偶尔会出现音量正常但画面慢半拍的情况。排查后发现问题出在-b:a参数上。为了统一各平台的音频码率我在某路FFmpeg命令里加了音频重编码参数结果FFmpeg默认会修改音频时间基准导致音视频时间戳差异积累。解决方式是要么全部用-c copy保持原样要么显式指定音频的采样格式和比特率并对视频流也做完整的转码让时间戳重新统一生成。# 不改变音频编码直接复制只转视频编码 ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c:v libx264 -preset veryfast -b:v 3000k \ -c:a copy \ -f flv rtmp://platformA.com/live/streamKeyA \ -loglevel error -y如果平台要求音频必须是AAC但源流是其他格式就建议显式重编码音频并加上统一的-ar 44100 -ac 2参数同时检查转码后是否插入了正确的-r命令来稳定视频帧率。另外我发现Nginx-RTMP模块默认的app名称、流名称如果包含中文或特殊字符也可能导致FFmpeg解析时间戳异常所以推流名称一律用纯英文和数字。4. 稳定运行一个月那些值得写下来的真实故障与排查记录这一章是整篇文章含金量最高的部分。配置能跑通只是开始真正考验系统工程能力的是故障处理和排查。我把这一个月遇到的最典型的问题按发生频率整理出来每个都附上排查路径和解决方案。4.1 平台主动断开推流你越热越容易被断多路推流一个月最频繁遇到的是平台主动断开RTMP连接。有些人第一反应是平台封杀第三方推流但其实大部分情况是推流参数不符合平台规则。比如某个短视频平台要求视频编码为H.264 high profile音频采样率必须是44.1kHz或48kHz关键帧间隔不能超过4秒。你从OBS采集的视频解码参数是baseline转推时又没有重新编码平台转码服务一检测到参数不符就直接踢流。排查方法其实不复杂。先用FFmpeg解析原始流的参数信息ffprobe -show_streams rtmp://127.0.0.1:1935/live/origin重点查看codec_name、profile、width、height、r_frame_rate、time_base这几个字段。用-c copy转推时这些参数会原样传给平台如果某个平台不兼容就需要对这一路单独做转码适配。我实测下来遇到的平台兼容性要求如下表平台类型视频Profile要求关键帧间隔要求音频要求常见表现平台Ahigh2秒内AAC 44.1kHz/48kHz过几分钟断流平台Bmain/high4秒内AAC 44.1kHz画面卡顿平台C无严格限制建议4秒内AAC 48kHz延迟增高海外平台high建议2秒内AAC 或不要求偶尔断流每一路推进前先花几分钟做兼容性测试比开播后被踢再慌慌张张排查省太多时间。4.2 服务器负载看起来不高但推流就是卡内核网络参数调优运行到第二周时我发现服务器CPU只有30%带宽也没满但平台B的观众持续反馈画面卡顿。深入排查后发现问题出在Linux内核的TCP连接跟踪和文件描述符限制上。Nginx和FFmpeg同时建立大量长连接如果net.ipv4.ip_local_port_range范围过小或者net.core.somaxconn队列不够新连接会被丢弃或排队表现就是推流端和平台端握手成功后数据时断时续。我最终在/etc/sysctl.conf里调整了几组参数# 本地端口范围调大允许更多并发连接 net.ipv4.ip_local_port_range 1024 65535 # 接收和发送缓冲区加大减少TCP拥塞导致的丢包 net.core.rmem_max 16777216 net.core.wmem_max 16777216 # 允许更快的TIME_WAIT复用 net.ipv4.tcp_tw_reuse 1 # 最大文件描述符调高 fs.file-max 6553560执行sysctl -p生效。这个优化做完平台B的卡顿问题明显改善。顺带把Nginx的worker_processes也调成了和CPU核心数一致worker_connections调到4096。有时候问题不在服务器而在网络链路。跨运营商网络延迟尤其明显比如服务器在电信机房平台节点在联通或移动高峰期丢包率会飙升。有条件就在多个云服务商各备一台低配机器做容灾或者用云厂商提供的CDN直播分发能力来中转会省心不少。4.3 推流进程挂掉但没人发现写一个简单的监控告警脚本多路推流最怕的不是断流而是断流了你还不知道。观众弹幕刷屏骂卡顿你这边看服务器还开着但FFmpeg的转推进程早就崩溃退出了。手动盯着不是办法写一个监控脚本轮询检查进程状态是最基本的保障。我的做法很朴素#!/bin/bash # 检查所有目标平台的FFmpeg转推进程是否存在 if ! pgrep -f platformA.*live/streamKeyA /dev/null; then echo $(date) 平台A进程挂了重启中 /var/log/stream_monitor.log nohup ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c copy -f flv rtmp://platformA.com/live/streamKeyA \ /dev/null 21 fi再用crontab每分钟执行一次* * * * * /usr/local/bin/check_stream.sh这只是一个保底方案。后来我又加了一层更精确的检测用ffprobe验证上游源流本身有没有断ffprobe -v error -select_streams v:0 -show_entries streamwidth \ -of csvp0 rtmp://127.0.0.1:1935/live/origin /dev/null 21 if [ $? -ne 0 ]; then # 源流断了触发告警 curl -s https://your-alert-webhook-url -d 源流断了请检查OBS状态 fi如果你用的是钉钉、企业微信或Telegram都可以通过Webhook收到告警。没有告警机制的推流系统白天开着还行晚上主播播完没人盯第二天早上所有平台都是黑屏重播这滋味我太熟悉了。4.4 上游源流波动导致所有平台连锁故障加一层缓冲运行期间我遇到过一次最惊险的故障本地网络瞬间抖动OBS向服务器的推流中断了5秒自动重连成功。但问题是这5秒的断流导致FFmpeg和Nginx连接缓冲区里的数据被快速清空恢复后Nginx把断流前最后的几个GOP又重复推给了所有平台结果所有平台回来后的画面都不一样有的慢了几秒有的恢复到断点场面比较混乱。这个问题的根源在于RTMP的接收缓冲设置。在Nginx配置里可以显式设置接收缓冲大小application live { live on; record off; max_connections 100; wait_key on; interleave on; }wait_key on是关键它保证断流恢复后Nginx会等待下一个关键帧才继续向转发模块推送数据而不是把缓存的半截视频帧发出去。这个参数默认是开启的但有些版本打包可能关闭了需要手动加上。另外FFmpeg进程也要加上-rw_timeout参数避免源断流后进程傻傻等待占用资源不放ffmpeg -rw_timeout 2000000 -i rtmp://127.0.0.1:1935/live/origin ...2000000是微秒即2秒。超过2秒没有收到源流数据FFmpeg主动退出重启配合监控脚本自动拉起整体断流恢复时间能从几十秒缩短到几秒。5. 常见问题速查表与部署检查清单这一个月踩坑无数我把最容易反复出现的问题整理成了一张速查表方便你遇到类似情况快速定位。表中涉及的参数均基于我实际测试时的设置不同平台可能略有差异但排查方向是通用的。故障现象大概率原因排查命令/方法解决思路所有平台同时卡顿服务器上行带宽不足iftop查看实时带宽升级带宽或降低码率单个平台频繁断流该平台不兼容当前编码参数ffprobe查看流参数单独转码适配推流进程自动退出源流中断后FFmpeg卡死看FFmpeg日志加-rw_timeout并监控重启开播正常半小时后音画不同步时间戳偏移平台端回放对比统一音频参数或全转码观众端画面模糊、恢复慢GOP太大看OBS关键帧设置设置keyint2*FPS服务器CPU不高但连接数超限文件描述符限制ulimit -n调整系统限制平台返回握手超时本地网络运营商与平台节点不互通mtr看路由丢包换机房或加中转部署完成后建议按下面这个清单过一遍很多问题都能提前规避服务器上行带宽是否留足了30%余量。OBS的GOP是否设置在2秒左右1080p30建议60。每个平台是否都做过至少5分钟试播确认编码参数兼容。FFmpeg脚本是否加入了-rw_timeout。监控脚本是否已经验证能自动拉起进程。有没有把Nginx的wait_key on和interleave on打开。服务器时间和本地时间是否一致避免日志排查时混乱。6. 一个月后的总结与维护心得多路推流稳定跑了一个月最深的体会是这套系统建起来容易维护才是重头戏。它不是一个配完就一劳永逸的东西平台的推流规则会变带宽的需求会变服务器也可能抽风。像我之前的处理方式一样把每一路转推脚本都放在独立目录里有问题单独重启不牵连其他路对整个系统的稳定性帮助极大。还有一个心得是关于报警的。刚开始我图省事只在FFmpeg进程崩了时重启后来发现观众反馈才会发现某个平台实际已经断流很久了。后来加了基于ffprobe的探活检查每隔一分钟检查一次源流状态和各路转推连接状态遇到异常立刻往群里推消息。说实话多路推流最值钱的就是这套探活机制哪怕脚本写得很简陋也比没有强得多。另外如果你想进一步扩展可以在FFmpeg命令里加上录制功能把直播内容同时存一份到服务器磁盘做复盘素材还可以接入一个简单的Web页面实时展示各路推流的状态和码率团队其他人不需要登录服务器就能看到整条链路的健康状况。这些功能都是在现有架构上小步快跑加出来的不会推倒重来。多路推流这条路踩坑是肯定的但只要把每一路分发的独立性、监控告警的及时性和参数适配的逻辑搞清楚稳定跑几个月是完全可以实现的。希望这篇复盘能帮你少走点弯路更早地把精力放回到直播内容和用户互动上。
多路推流实战：从Nginx+FFmpeg到SRS的服务器中转架构与踩坑复盘
这个标题对我来说太有发言权了。团队直播间从单平台切到多平台分发到现在用服务器做多路推流刚好满一个月。这一个月里我踩过的坑比过去一年直播踩的还多带宽被打满、平台断流、时间戳错乱导致音画不同步、推流进程半夜自己死掉……今天把这些经验完整复盘一遍给正准备做多路推流的朋友们一个参考。先说清楚多路推流能解决什么问题。以前做直播要么用OBS直接推流到单一平台要么在电脑上装各种虚拟摄像头、分身工具把画面复制到多个直播软件里再分别推出去。前者只能覆盖一个平台后者对电脑性能消耗极大笔记本用户推两路就开始风扇狂转、掉帧。多路推流的思路是只在一台机器上做一次采集和推流把码流推到一台中间服务器上由服务器再分发到各个直播平台。这样做的好处很明显——采集端压力小、网络波动容错高、还能在服务器侧做转码和录制。这套方案适合谁适合需要把同一路画面同时分发到多个平台的主播、做直播带货的运营团队、做线上活动转播的机构。如果你是个人主播只推一个平台完全用不上但只要你开始做多平台分发而且对稳定性有要求这篇内容就能帮你少走至少一个星期的弯路。1. 多路推流的整体架构与方案选型多路推流这件事表面上看只是“一个画面发到多个地方”但真正落地时核心问题会变成三件事谁来做分发、用什么协议分发、分发到哪些平台。这三个问题决定了整个系统的复杂度。1.1 方案选型为什么最终选了服务器中转我先把自己试过的路都列出来方便你对照自己的情况做取舍。第一种纯软件方案也就是在直播电脑上多开OBS或用OBS的多路输出插件。这个方案的优势是零成本、配置简单几分钟就能跑起来。缺点是CPU占用直接翻倍一路1080p编码已经吃掉不少性能两路三路同时编码很容易导致帧率不稳。另一个隐患是电脑本身的网络出口通常不够稳定家用宽带的公网体验并不好高峰期上传一大所有平台一起卡。第二种用直播平台自带的转播功能或云厂商的直播分发服务。这个方案稳定性好但受制于平台规则比如有些平台会限制转播码率、需要在不同平台分别配置推流域名而且一般都要付费或者受平台等级影响。第三种自建服务器中转也就是我最终选的路。具体做法是租一台带宽足够的云服务器装Nginx和RTMP模块或者用SRS这类开源流媒体服务器接收来自OBS或FFmpeg的原始推流再通过服务器向所有直播平台分发。这个方案的特点是可玩性极高你能控制转码参数、推流节奏、断流重连策略但前提是你对Linux和流媒体协议有一定基础。我最终选了自建服务器中转核心原因是团队需要同时在五个平台开播两个主流短视频平台、一个视频平台、一个电商平台和一个海外平台。这种规模下电脑端的软件方案完全不现实云服务的成本又不低自建服务器虽然要花点心思配置但算下来一个月服务器费用比云直播服务便宜一大截而且调度非常灵活。1.2 多路推流的链路拆解与核心角色先说清楚整个链路里都有哪些角色。采集端就是你的编码推流设备通常是直播电脑上的OBS负责采集摄像头、麦克风、桌面画面编码成H.264或H.265视频流通过RTMP协议推送到中继服务器的指定端口。中继服务器这是多路推流系统的核心。它主要负责接收上游的推流然后把这一路流复制成多路分别转发到各个目标平台。这个“复制”不是简单拷贝因为每个平台的推流地址、流密钥、甚至编码兼容性要求都可能不一样你需要针对每个目标平台单独配置一个转发点。目标平台就是你要分发到的各个直播平台。它们各自的直播服务会给你一个推流地址RTMP地址你的服务器向这些地址发流即可。这套架构最关键的一点是所有编码压力都在采集端中继服务器只做转发和轻量级处理。所以服务器的CPU不需要特别强但带宽和稳定性必须过硬。我给自己的服务器配的是4核CPU、8GB内存、50Mbps公网带宽。如果你要推4路以上的高清视频至少准备100Mbps带宽否则很容易在高峰时段被打满。这个链路里还有两个容易被忽略的细节。一个是协议选择目前主流直播平台基本都接受RTMP推流但海外平台有的更推荐SRT或RTMPS如果你要推海外平台需要先确认对方支持的推流协议。另一个是授权问题绝大多数平台都允许你用合法的推流软件进行推流但通过服务器中转本质上相当于使用了第三方推流工具个别平台会有风控机制需要你关注平台规则尽量使用合规的配置方式。2. 部署实操从零搭建服务器并完成多路分发选择和搭建往往只花半天真正折磨人的是把每一路推流调通、调稳。这一章我把服务器的部署流程、关键参数和踩坑点全部写清楚你照着复制就能少走弯路。2.1 服务器初始化与Nginx-RTMP模块编译基础环境我用的是Ubuntu Server 22.04 LTS。第一次部署时我图省事直接用apt install nginx装了个干净Nginx结果发现默认包里没有RTMP模块测试推流时服务器半天没响应。后来才明白Nginx官方mainline版本本身不带RTMP模块必须自己编译安装或安装带RTMP模块的第三方包。推荐做法是用源码编译。下面是一套稳定的安装流程# 安装编译依赖 apt update apt install -y build-essential libpcre3-dev libssl-dev zlib1g-dev # 下载Nginx源码和RTMP模块源码 cd /usr/local/src wget http://nginx.org/download/nginx-1.24.0.tar.gz git clone https://github.com/arut/nginx-rtmp-module.git # 解压并编译 tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 ./configure --with-http_ssl_module --add-module../nginx-rtmp-module make -j4 make install编译安装后Nginx默认会装在/usr/local/nginx目录下。启动前先编辑/usr/local/nginx/conf/nginx.conf在文件末尾追加RTMP配置块rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; # 允许来自内网或指定IP的推流 allow publish 127.0.0.1; allow publish 你的本机内网IP; deny publish all; } # 转发到平台A application relay_a { live on; record off; } # 转发到平台B application relay_b { live on; record off; } } }listen 1935是RTMP的默认端口chunk_size 4096是分块大小这个值不是越大越好我用4096和8192分别测过推流延迟差别不大但4096兼容性更好。先别急着同时配置多个application我后面会解释为什么用这种方式做多平台分发容易踩坑并给你更稳妥的替代方案。2.2 通过FFmpeg实现多路分发这步最关键一开始我天真地认为服务器收到一路RTMP流之后再用Nginx-RTMP模块的push指令复制到各个平台地址就行。一个典型的错误配置是application live { live on; record off; push rtmp://platformA.com/live/streamKeyA; push rtmp://platformB.com/live/streamKeyB; push rtmp://platformC.com/live/streamKeyC; }这个配置的思路没错但有个严重的隐患Nginx的push指令对所有平台使用同一个流媒体处理管线只要有一个平台的推流地址返回超时或拒绝连接整个Nginx worker进程就可能被卡住导致其他平台也一起断流。我第一天上线就被坑了一次平台A的推流密钥填错结果平台B和平台C的流在几分钟内陆续出现频繁卡顿。正确的做法是服务器只负责收流每个平台的分发任务交给独立的FFmpeg进程单独处理。这样哪怕一路推流失败其他路完全不受影响。具体架构是在Nginx里只保留一个application接收OBS推流然后为每个目标平台分别写一个FFmpeg转推命令。示例命令如下# 从服务器本地接收流转推到平台A ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c copy -f flv rtmp://platformA.com/live/streamKeyA \ -loglevel error -y # 转推到平台B平台B要求视频参数稍有不同可加转码参数 ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c:v libx264 -preset veryfast -b:v 2500k \ -c:a aac -b:a 128k -f flv rtmp://platformB.com/live/streamKeyB \ -loglevel error -y关键点在于每个FFmpeg进程只负责一个目标平台并且用-c copy进行流复制不做转码这样CPU占用极低同时彼此隔离一个进程挂了重启它就行不影响其他路。还要注意一个细节每个平台的推流地址和流密钥不能写死在前台命令里最好写成独立的shell脚本方便修改和重启。日志也需要单独存文件排查问题时会省很多事。2.3 用srs替代Nginx的另一种选择如果你觉得NginxFFmpeg的组合配置起来有点繁琐可以试试SRS这个专门为直播场景设计的流媒体服务器。SRS对RTMP、SRT、HLS、WebRTC等协议的支持更原生很多商用直播系统的底层就是它。SRS的部署方式很简单wget https://github.com/ossrs/srs/archive/refs/tags/v5.0.0.tar.gz tar -zxvf v5.0.0.tar.gz cd srs-5.0.0 ./configure --prefix/usr/local/srs make make install配置转发时SRS用vhost和cluster做分发也支持forward指令。比如把收到的live/origin流转到多个平台vhost __defaultVhost__ { forward { enabled on; backend rtmp://platformA.com/live/streamKeyA; } forward { enabled on; backend rtmp://platformB.com/live/streamKeyB; } }SRS的优势是并发处理能力强、内置监控API劣势是对新手来说配置文件的概念比Nginx多。我的建议是团队里有人熟悉Nginx就选NginxFFmpeg想学一套更专业的流媒体服务器就上SRS两者没有本质差别。3. 带宽、延迟与音画同步影响直播质量的三个关键参数服务器搭起来了流也推起来了但如果你直接开播很快就会发现问题观众反馈画面卡顿、声音对不上、延迟忽高忽低。这些问题几乎都和带宽、延迟、时间戳这三个参数有关。3.1 带宽计算与上行限制不是你带宽大就能推高清很多人在规划服务器时直接把带宽理解成“我按最大码率算就行”这是个大坑。多路推流的带宽消耗不只是直播码率本身还有协议开销和峰值波动。先看一个基础计算公式一路1080p踩在3500Kbps码率、音频128Kbps总码率大约3628Kbps。如果你要推5路同样的流理论带宽需求是总码率 单路码率 × 路数 3628Kbps × 5 ≈ 18140Kbps ≈ 18Mbps但这是理想值实际还要考虑RTMP协议本身有握手和包头开销约占5%-10%平台端偶尔会做短时间缓存导致服务器发送速率波动还有一些平台的网络节点在高峰期会回源拉流影响你的上行。所以我推荐一个经验公式实际带宽需求 总码率 × 1.3。五路流至少需要24Mbps带宽再加上服务器本身的管理流量。我第一周开的服务器带宽是30Mbps五路流时CPU占用不高但带宽利用率长期在80%以上观众端偶尔出现卡顿后来升级到50Mbps才完全解决。下表是不同规格的判断参考推流路数单路码率Kbps理论总码率推荐带宽3路25007.5Mbps10Mbps3路800024Mbps35Mbps5路350018Mbps30Mbps5路600036Mbps50Mbps10路250030Mbps45Mbps还要提醒一点大多数云服务器的带宽是按“下行上行”计费的但实际对直播来说上行才是瓶颈。购买时不要只看宣传的百兆带宽要确认上行的保证值。如果预算够尽量选按固定带宽计费而不是按流量计费否则多路推流一个月下来流量费可能比服务器本身贵好几倍。3.2 延迟优化与缓存策略直播卡不卡关键在于缓冲延迟就是主播说话到观众听到之间隔了多长时间。多路推流链路比单一平台推流多了一个中继节点延迟天然会增加1到2秒。所以你不能用单路直播的延迟标准去要求多路推流。RTMP协议本身是低延迟协议延迟主要产生于两个环节编码端的GOP关键帧间隔设置以及播放端的缓冲策略。关键帧间隔通常叫GOP是影响直播延迟的核心参数之一。如果GOP设置过大比如10秒一个关键帧观众在切换清晰度或网络抖动缓冲时会长时间看到模糊画面体验极差。我建议OBS里把GOP设为2秒对H.264编码就是keyint2*FPS。比如30帧视频GOP就设为60。这样即便某一路平台出现短暂卡顿恢复起来也快。还有一个容易踩的坑是FFmpeg转推时的-re参数。-re表示按原始帧率读取输入模拟实时推流。但我在写脚本时如果输入源是本地RTMP地址加不加-re其实无所谓服务器收到流本来就是实时的但有些教程会建议在FFmpeg命令里加-re这不但在多路分发时毫无帮助反而可能造成输入缓冲区堆积增加延迟。正确的转推命令不应该加-re。播放端的缓冲策略你控制不了那是各平台播放器自己的逻辑。你能做的是尽量压低源端延迟把平台端的延迟误差控制在可接受范围内。3.3 音画同步问题多路转推最容易忽视的隐藏坑音画不同步是我这一个月里遇到最隐蔽的问题。最开始我以为是平台转码导致的后来发现根源出在FFmpeg转推时的时间戳处理上。很多平台的清洗转码流程在收到流后会根据时间戳DTS/PTS重新整理音频和视频包。如果原始流的时间戳有偏移或跳变平台的转码管道就会出错表现就是音画逐渐不同步有的甚至在开播后10分钟才出现明显偏差。我踩到的一个具体问题OBS推流时音频采样率使用了48kHz视频帧率是30fpsFFmpeg转推时用-c copy直接拷贝音视频数据理论上时间戳不该有问题。但实际监控发现某一路平台偶尔会出现音量正常但画面慢半拍的情况。排查后发现问题出在-b:a参数上。为了统一各平台的音频码率我在某路FFmpeg命令里加了音频重编码参数结果FFmpeg默认会修改音频时间基准导致音视频时间戳差异积累。解决方式是要么全部用-c copy保持原样要么显式指定音频的采样格式和比特率并对视频流也做完整的转码让时间戳重新统一生成。# 不改变音频编码直接复制只转视频编码 ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c:v libx264 -preset veryfast -b:v 3000k \ -c:a copy \ -f flv rtmp://platformA.com/live/streamKeyA \ -loglevel error -y如果平台要求音频必须是AAC但源流是其他格式就建议显式重编码音频并加上统一的-ar 44100 -ac 2参数同时检查转码后是否插入了正确的-r命令来稳定视频帧率。另外我发现Nginx-RTMP模块默认的app名称、流名称如果包含中文或特殊字符也可能导致FFmpeg解析时间戳异常所以推流名称一律用纯英文和数字。4. 稳定运行一个月那些值得写下来的真实故障与排查记录这一章是整篇文章含金量最高的部分。配置能跑通只是开始真正考验系统工程能力的是故障处理和排查。我把这一个月遇到的最典型的问题按发生频率整理出来每个都附上排查路径和解决方案。4.1 平台主动断开推流你越热越容易被断多路推流一个月最频繁遇到的是平台主动断开RTMP连接。有些人第一反应是平台封杀第三方推流但其实大部分情况是推流参数不符合平台规则。比如某个短视频平台要求视频编码为H.264 high profile音频采样率必须是44.1kHz或48kHz关键帧间隔不能超过4秒。你从OBS采集的视频解码参数是baseline转推时又没有重新编码平台转码服务一检测到参数不符就直接踢流。排查方法其实不复杂。先用FFmpeg解析原始流的参数信息ffprobe -show_streams rtmp://127.0.0.1:1935/live/origin重点查看codec_name、profile、width、height、r_frame_rate、time_base这几个字段。用-c copy转推时这些参数会原样传给平台如果某个平台不兼容就需要对这一路单独做转码适配。我实测下来遇到的平台兼容性要求如下表平台类型视频Profile要求关键帧间隔要求音频要求常见表现平台Ahigh2秒内AAC 44.1kHz/48kHz过几分钟断流平台Bmain/high4秒内AAC 44.1kHz画面卡顿平台C无严格限制建议4秒内AAC 48kHz延迟增高海外平台high建议2秒内AAC 或不要求偶尔断流每一路推进前先花几分钟做兼容性测试比开播后被踢再慌慌张张排查省太多时间。4.2 服务器负载看起来不高但推流就是卡内核网络参数调优运行到第二周时我发现服务器CPU只有30%带宽也没满但平台B的观众持续反馈画面卡顿。深入排查后发现问题出在Linux内核的TCP连接跟踪和文件描述符限制上。Nginx和FFmpeg同时建立大量长连接如果net.ipv4.ip_local_port_range范围过小或者net.core.somaxconn队列不够新连接会被丢弃或排队表现就是推流端和平台端握手成功后数据时断时续。我最终在/etc/sysctl.conf里调整了几组参数# 本地端口范围调大允许更多并发连接 net.ipv4.ip_local_port_range 1024 65535 # 接收和发送缓冲区加大减少TCP拥塞导致的丢包 net.core.rmem_max 16777216 net.core.wmem_max 16777216 # 允许更快的TIME_WAIT复用 net.ipv4.tcp_tw_reuse 1 # 最大文件描述符调高 fs.file-max 6553560执行sysctl -p生效。这个优化做完平台B的卡顿问题明显改善。顺带把Nginx的worker_processes也调成了和CPU核心数一致worker_connections调到4096。有时候问题不在服务器而在网络链路。跨运营商网络延迟尤其明显比如服务器在电信机房平台节点在联通或移动高峰期丢包率会飙升。有条件就在多个云服务商各备一台低配机器做容灾或者用云厂商提供的CDN直播分发能力来中转会省心不少。4.3 推流进程挂掉但没人发现写一个简单的监控告警脚本多路推流最怕的不是断流而是断流了你还不知道。观众弹幕刷屏骂卡顿你这边看服务器还开着但FFmpeg的转推进程早就崩溃退出了。手动盯着不是办法写一个监控脚本轮询检查进程状态是最基本的保障。我的做法很朴素#!/bin/bash # 检查所有目标平台的FFmpeg转推进程是否存在 if ! pgrep -f platformA.*live/streamKeyA /dev/null; then echo $(date) 平台A进程挂了重启中 /var/log/stream_monitor.log nohup ffmpeg -i rtmp://127.0.0.1:1935/live/origin \ -c copy -f flv rtmp://platformA.com/live/streamKeyA \ /dev/null 21 fi再用crontab每分钟执行一次* * * * * /usr/local/bin/check_stream.sh这只是一个保底方案。后来我又加了一层更精确的检测用ffprobe验证上游源流本身有没有断ffprobe -v error -select_streams v:0 -show_entries streamwidth \ -of csvp0 rtmp://127.0.0.1:1935/live/origin /dev/null 21 if [ $? -ne 0 ]; then # 源流断了触发告警 curl -s https://your-alert-webhook-url -d 源流断了请检查OBS状态 fi如果你用的是钉钉、企业微信或Telegram都可以通过Webhook收到告警。没有告警机制的推流系统白天开着还行晚上主播播完没人盯第二天早上所有平台都是黑屏重播这滋味我太熟悉了。4.4 上游源流波动导致所有平台连锁故障加一层缓冲运行期间我遇到过一次最惊险的故障本地网络瞬间抖动OBS向服务器的推流中断了5秒自动重连成功。但问题是这5秒的断流导致FFmpeg和Nginx连接缓冲区里的数据被快速清空恢复后Nginx把断流前最后的几个GOP又重复推给了所有平台结果所有平台回来后的画面都不一样有的慢了几秒有的恢复到断点场面比较混乱。这个问题的根源在于RTMP的接收缓冲设置。在Nginx配置里可以显式设置接收缓冲大小application live { live on; record off; max_connections 100; wait_key on; interleave on; }wait_key on是关键它保证断流恢复后Nginx会等待下一个关键帧才继续向转发模块推送数据而不是把缓存的半截视频帧发出去。这个参数默认是开启的但有些版本打包可能关闭了需要手动加上。另外FFmpeg进程也要加上-rw_timeout参数避免源断流后进程傻傻等待占用资源不放ffmpeg -rw_timeout 2000000 -i rtmp://127.0.0.1:1935/live/origin ...2000000是微秒即2秒。超过2秒没有收到源流数据FFmpeg主动退出重启配合监控脚本自动拉起整体断流恢复时间能从几十秒缩短到几秒。5. 常见问题速查表与部署检查清单这一个月踩坑无数我把最容易反复出现的问题整理成了一张速查表方便你遇到类似情况快速定位。表中涉及的参数均基于我实际测试时的设置不同平台可能略有差异但排查方向是通用的。故障现象大概率原因排查命令/方法解决思路所有平台同时卡顿服务器上行带宽不足iftop查看实时带宽升级带宽或降低码率单个平台频繁断流该平台不兼容当前编码参数ffprobe查看流参数单独转码适配推流进程自动退出源流中断后FFmpeg卡死看FFmpeg日志加-rw_timeout并监控重启开播正常半小时后音画不同步时间戳偏移平台端回放对比统一音频参数或全转码观众端画面模糊、恢复慢GOP太大看OBS关键帧设置设置keyint2*FPS服务器CPU不高但连接数超限文件描述符限制ulimit -n调整系统限制平台返回握手超时本地网络运营商与平台节点不互通mtr看路由丢包换机房或加中转部署完成后建议按下面这个清单过一遍很多问题都能提前规避服务器上行带宽是否留足了30%余量。OBS的GOP是否设置在2秒左右1080p30建议60。每个平台是否都做过至少5分钟试播确认编码参数兼容。FFmpeg脚本是否加入了-rw_timeout。监控脚本是否已经验证能自动拉起进程。有没有把Nginx的wait_key on和interleave on打开。服务器时间和本地时间是否一致避免日志排查时混乱。6. 一个月后的总结与维护心得多路推流稳定跑了一个月最深的体会是这套系统建起来容易维护才是重头戏。它不是一个配完就一劳永逸的东西平台的推流规则会变带宽的需求会变服务器也可能抽风。像我之前的处理方式一样把每一路转推脚本都放在独立目录里有问题单独重启不牵连其他路对整个系统的稳定性帮助极大。还有一个心得是关于报警的。刚开始我图省事只在FFmpeg进程崩了时重启后来发现观众反馈才会发现某个平台实际已经断流很久了。后来加了基于ffprobe的探活检查每隔一分钟检查一次源流状态和各路转推连接状态遇到异常立刻往群里推消息。说实话多路推流最值钱的就是这套探活机制哪怕脚本写得很简陋也比没有强得多。另外如果你想进一步扩展可以在FFmpeg命令里加上录制功能把直播内容同时存一份到服务器磁盘做复盘素材还可以接入一个简单的Web页面实时展示各路推流的状态和码率团队其他人不需要登录服务器就能看到整条链路的健康状况。这些功能都是在现有架构上小步快跑加出来的不会推倒重来。多路推流这条路踩坑是肯定的但只要把每一路分发的独立性、监控告警的及时性和参数适配的逻辑搞清楚稳定跑几个月是完全可以实现的。希望这篇复盘能帮你少走点弯路更早地把精力放回到直播内容和用户互动上。
