做直播这两年我最大的感受是真正让人头大的从来不是开播而是怎么把一路信号稳定地送到所有该出现的地方。以前我试过同时开三个 OBS 实例分别推到不同平台结果 CPU 直接拉满推流一断就是三份事故还要手忙脚乱去重连。后来我干脆做了一个叫 OneLive 的自用项目核心思路只有一句话一路信号进多路信号出。所有的转码、分发、监控都收拢到一台中心服务器上前端只推一次流剩下的事交给它来做。这套东西我已经在几十场常规播和几场大活动里跑通了从 OBS 参数到 Nginx 配置到 ffmpeg 分发脚本每一步都踩过坑。这篇就当是给志同道合的人留的一份完整实操笔记适合正在做多平台直播、在线课程、也适合想自建推流中继而不再依赖第三方付费服务的人参考。1. OneLive 到底在解决什么问题1.1 直播行业里那个没人愿意提的痛点很多人以为直播就是个打开 OBS、点开始推流的简单事情。但当你真正靠直播干活的时候总有一天会遇到一个绕不开的场景同一场直播要同时出现在几个不同的平台上。比如一场新品发布会主会场在 A 平台官方账号在 B 平台合作渠道还要在 C 平台同步。这时候你面临的选择通常是开三份 OBS分别采集同一画面然后各自推流。这条路我走过体验很糟糕。第一是资源开销三份 OBS 意味着三份编码运算普通笔记本的 CPU 直接冒烟画面卡顿、风扇狂转第二是稳定性任何一个实例崩了对应平台的黑屏事故就来了人跑去补救的时候根本顾不上全局第三是平台差异有的平台限码率、有的平台对音频采样率敏感你在 OBS 里配的参数只能适配一个平台其他平台要么被压画质要么直接被拒流。OneLive 的出发点就是把每一路推流这件事从一个个孤立的 OBS 窗口里抽出来变成一条标准化的处理流水线。主播端永远只做一件事用任意推流工具把画面送到中心服务器。之后中心服务器负责拷贝、转码、适配、分发同一份内容按不同平台的规格要求送到各个目标地址。这相当于给直播加了一个信号总调度它的价值不是省一台电脑而是把所有可变因素收拢到一个可控的位置。1.2 设计思路为什么是单路进、多路出而不是多路各自推确定这个思路之前我也对比过市面上现成的多平台分发方案。有些是云服务商的付费转推功能优点是省心缺点是按月收费、单路信号要单独计费长期用其实不便宜还有一些是多开模拟器式的软件方案本质还是在你电脑上开多份推流进程治标不治本。反复比较之后我选了自建中心的分发架构。这个方案有几个肉眼可见的优势首先信号源只有一路出问题的地方变得非常清晰排查链路从排查多个 OBS 实例收敛成排查一个中心服务其次转码参数按平台单独配置A 平台要 1080p 高码率、B 平台只要 720p中心服务器可以分别处理不再需要为迁就某个平台而拖累所有人再次中心服务器本身可以做监控、录像、转推这些能力是单纯的 OBS 多开永远给不了的。当然自建也意味着这些事都得自己扛服务器要自己选型、ffmpeg 要自己配、断线重连要自己写脚本。这就是下面几节要讲的核心内容我会把每一步的参数和踩坑经历都说清楚。2. 核心链路与技术拆解2.1 一条直播信号是怎么走到各个平台的先把链路画清楚。OneLive 的整体路径是采集端 → 中心服务器 → 各平台边缘节点 → 观众端。采集端通常是 OBS、或者手机相机加编码器通过 RTMP 协议把流推到中心服务器的 1935 端口。中心服务器上跑着 Nginx 和它的 RTMP 模块负责接收这一路流然后由 ffmpeg 进程把它作为输入经过转码或者直接拷流stream copy之后分别推到各平台给到的 RTMP 推流地址。这里有两个协议层面的选择值得多说一句。接入端用 RTMP是因为它是目前兼容性最好的推流协议几乎所有平台提供的推流地址都是rtmp://...格式OBS 也原生支持不需要额外装插件。而输出端其实还有一个更好用的选择SRT。SRT 的中继稳定性比 RTMP 好不少尤其适合长距离传输丢包重传机制做得更精细。不过各平台目前开放给主播的推流地址基本都是 RTMP所以对 OneLive 来说日常主要输出还是 RTMPSRT 更适合用在中心服务器到另一个中心服务器这种私有链路上。我自己的做法是对外推平台用 RTMP自己内部多机房做灾备链路时用 SRT两边各取所长。关于延迟OneLive 的定位是普通交互直播不是连麦级低延迟场景所以延迟目标定在 3 到 8 秒之间。这个目标 RTMP 链路完全能满足。需要注意的是转码环节会引入额外的缓冲延迟所以转码参数里要尽量用低延迟取向的编码配置这一点在下一节的实操命令里会专门说明。2.2 转码方案选型CPU、GPU 还是干脆不转码OneLive 里最影响成本和画质的一个决策就是到底要不要转码。最简单的场景如果所有目标平台对画质的要求一致比如都支持 1080p、4500kbps那根本不需要转码直接用 ffmpeg 的 stream copy 模式把视频流和音频流原封不动地复制分发服务器几乎不产生编码开销画质零损失一台小水管服务器都能带得动。这也是 OneLive 默认最快的跑法。但现实里总会遇到平台规格不一致的情况。比如某平台非互动直播间把码率上限压在 4000kbps另一平台对视频编码有兼容性要求。这时候就必须转码。转码怎么选我先说结论自用场景优先选 CPU 软编用 libx264 加 veryfast preset如果服务器有独立显卡且目标是高路数并发再考虑 NVENC 硬编。软编的好处是兼容性最好、画质在同码率下通常优于硬编缺点是吃 CPU。以 1080p 4500kbps 为例一个 4 核虚拟机用 veryfast preset 软编占用率大概在 60% 到 80% 之间还能接受但如果同时要转两路或者更多路就得考虑扩容或者上硬编。NVENC 的好处是编码速度快、占用低一台带 T4 的服务器转十来路都没问题缺点是低码率下画质不如 x264 细腻尤其是动态大的画面容易出现细节糊掉的情况。我的实际选择很简单常规双平台分发全部用 stream copy零转码遇到平台规格不一致只对需要降码率的那一路做软编其余路继续拷贝。这样既控制了成本也把画质风险控制在最小范围。2.3 延迟目标与平台兼容性的取舍OneLive 是典型一条流打天下的架构但各家平台对视频流的细节要求其实差异不小。有的平台要求关键帧间隔 2 秒有的平台要求编码 profile 别太高有的平台对非标准分辨率特别敏感。这些差异如果不在中心侧处理掉观众端的表现差异会很离谱轻则首帧加载慢重则直接黑屏。我的兼容性处理原则是入站宽松、出站严格。入站只要 RTMP 能握手成功、音视频流存在就照单全收出站则以各平台最严格的规格为基准做适配。具体落地就是视频编码用 H.264 High profile 但不开 B 帧避免解码兼容性问题关键帧间隔固定设置 2 秒分辨率保持偶数且不低于平台下限音频统一转成 AAC 48kHz 双声道。这套基线在我实测的几个主流平台里都能稳定推流不容易被拒流。具体命令放到第 3 节那里是能直接抄作业的部分。3. 实操从零搭起 OneLive 的关键模块3.1 推流端配置OBS 里的几个关键参数OneLive 对推流端的要求其实很低但低要求不等于随便配。推流端的几个参数直接决定了中心服务器拿到的信号质量也更影响后续所有分发的品质。我在 OBS 里固定用的是这套配置输出模式选高级视频比特率 4500kbps、编码器选 x264、速率控制选 CBR、关键帧间隔 2 秒、CPU 编码预设 veryfast、音频比特率 128kbps、采样率 48kHz。为什么非要用 CBR因为 CBR 码率波动小网络传输稳定中心服务器接收时不会出现因为码率突增而丢包的情况。关键帧间隔 2 秒是和平台兼容性直接挂钩的很多平台的切片器就是按照关键帧来切间隔太长会导致观众开播后迟迟加载不出画面。如果采集端不是 OBS而是相机直接输出到编码器盒子也要把同样的参数带过去。最省事的做法是让编码器输出与 OBS 一致的 H.264 AAC 流中心侧就完全不用为采集端差异操心。参数配好之后推流地址填rtmp://你的服务器IP/live/main串流密钥 main 可以理解成这条流的频道名后面分发模块就要靠这个名字去拉流。就这一步推流端的准备工作就结束了。3.2 中心服务安装与配置 Nginx RTMP中心服务我用的方案是 Nginx 加 nginx-rtmp-module。这个组合成熟得不能再成熟社区资料多、问题少、性能也够用。安装方式有两种一是直接编译把 nginx-rtmp-module 编进去二是直接用现成的 Docker 镜像我后来偷懒选了 Docker维护起来还方便。配置文件里最核心的一段是 RTMP 模块的配置rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; meta copy; wait_key on; } } }先解释几个关键项。chunk_size 4096是 RTMP 分块大小默认值与某些推流端配合时可能触发兼容性问题4096 是比较稳妥的通用值。meta copy表示把推流端带的元数据复制给下游比如分辨率、帧率这些信息如果不复制有些平台在拉流时拿不到参数会直接拒绝。wait_key on是让服务器等到下一个关键帧才正式对外输出这样可以避免拉流端拿到一个不完整的开头导致花屏。配好之后记得检查防火墙把 1935 端口放开其余端口保持关闭。这个细节我吃过亏第一次部署时 RTMP 服务明明起来了但服务器外网就是推不进去最后排查半天发现是安全组只放行了 80 和 443。服务启动后可以用一个最笨也最有效的方法验证本地用 ffplay 直接拉rtmp://IP/live/main能看到画面就说明入站链路通了。3.3 分发模块FFmpeg 的推流命令与参数计算中心服务器收到流之后真正干活的其实是 ffmpeg。OneLive 的分发脚本本质上就是一组 ffmpeg 进程每个进程负责一条出站链路。先给一个最常见的拷贝分发示例ffmpeg -i rtmp://127.0.0.1:1935/live/main \ -c copy -f flv rtmp://platform-a.com/live/stream-key-a \ -c copy -f flv rtmp://platform-b.com/live/stream-key-b这个命令把同一路输入复制推给两个平台视频音频都不重新编码服务器 CPU 占用率很低。但要注意一个参数细节-c copy必须在每个输出参数组里分别声明一次因为 ffmpeg 不保证默认会按拷贝处理每个输出。漏掉一个就可能导致 ffmpeg 对那一路执行完整重编码CPU 直接飙升我当时就是没注意这个第一版脚本发现 CPU 一直满载排查半天才发现有一路输出没加-c copy。如果某平台需要降码率转码再加一个专门的转码输出即可ffmpeg -i rtmp://127.0.0.1:1935/live/main \ -c copy -f flv rtmp://platform-high.com/live/key \ -c:v libx264 -preset veryfast -tune zerolatency \ -b:v 3000k -maxrate 3000k -bufsize 6000k \ -g 60 -keyint_min 60 -sc_threshold 0 \ -c:a aac -b:a 128k -ar 48000 \ -f flv rtmp://platform-limit.com/live/key这里面的-g 60是 GOP 大小配合 30fps 帧率正好是 2 秒一个关键帧-keyint_min 60保证关键帧间隔不会因为场景切换被强制缩短-sc_threshold 0禁止场景检测自动插入关键帧这样关键帧分布才能严格对齐 2 秒平台切片和转码都会更稳定。-tune zerolatency则是压低编码器的缓冲延迟特别适合直播这种低延迟场景。分发脚本还需要解决一个问题断线重连。平台侧的推流地址偶尔会主动断开会话尤其遇到网络抖动的时候。我的做法是给每个 ffmpeg 进程套一个循环脚本检测到进程退出就用同样的命令再拉起一次中间留 3 秒间隔连续重启超过 5 次就发告警不无限重试。这个逻辑很朴素但在我的实际运行里效果稳定比复杂的状态机靠谱得多。3.4 控制面板与监控OneLive 做久了之后我发现一个问题分发脚本本身再稳一旦出问题我可能是在观众刷屏怎么黑屏了之后才知道。于是后来补了一个非常轻量的监控模块原理就是定时用 ffprobe 去拉中心服务器上的流检查关键信息是否正常ffprobe -v error -select_streams v:0 -show_entries streamcodec_name,width,height,bit_rate \ -of defaultnoprint_wrappers1 rtmp://127.0.0.1:1935/live/main这条命令会在 1 到 2 秒内返回视频流的基本信息。只要它成功返回就说明入站流是活的。在此基础上每个出站 ffmpeg 进程是否有异常退出也可以通过检查进程表或者读取日志来判定。我最终把状态汇总到一个简单的网页面板上每一行显示一条链路的名字、入站流是否正常、出站进程是否存活、最后一次拉流校验的时间。告警走的是 Webhook 通知出问题 10 秒内就能收到消息。如果连这些都不想写还有更省事的替代Zabbix 或者 Prometheus 加 blackbox exporter都能做类似的存活探测。区别只是配置成本高一点但功能更通用。我自己的体会是OneLive 的监控先追求能看到状态再追求状态好看先有数据再谈可视化不要一上来就堆图表那是给自己增加维护负担。4. 常见问题与排查技巧实录4.1 推流频繁断线这是用得最多也最容易让人崩溃的一类问题。现象是中心服务器上的出站进程每隔十几分钟或者几小时就会退出然后被重连脚本拉起来但观众端已经黑屏了。我踩过的坑可以列成一个速查清单可能原因判断方法解决办法服务器到平台之间的网络抖动出站进程报超时或断开前有大量重传换一条更稳定的中转线路或用 SRT 替代 RTMP 出站平台主动断开空闲连接断开时间点很规律缩短重连间隔并在重连时尽快推入关键帧恢复画面ffmpeg 输出端流量瞬时突增报错里有 buffer overflow 字样调整-bufsize一般设为码率的两倍平台侧系统维护只在特定时段断开监控到规律后错峰或自动换备用地址重连脚本有一个容易被忽视的点重连时如果直接重新拉原输入流ffmpeg 需要等到下一个关键帧才能输出画面的起点观众端会先看到雪花或者黑屏一段时间。我后来在脚本里加了一步重连前先用 ffprobe 检查输入流是否已经恢复了关键帧确认后再拉起 ffmpeg这个操作能让恢复时间从十几秒压缩到两三秒。4.2 音画不同步音画不同步是最隐蔽的坑。画面和声音明明各自都正常但放在一起就是对不上延迟差甚至能到一两秒。我遇到的最典型原因出在转码环节。用-c:v libx264重新编码视频的同时用-c:a copy保留原音频会导致音频时间戳和视频时间戳的参考基准不一致。解决方法是音频也走一次重编码同时在命令里加上时间戳修正参数-c:a aac -ar 48000 -ac 2 -af aresampleasync1:first_pts0aresample的async1会自动补偿音频的微小偏移first_pts0强制音频从零时间戳开始这样音画就能对齐到同一个时钟基准上。另外如果源流本身就是音画不同步的那这个问题的根源在推流端不能在中心服务器彻底解决。排查时可以先用 ffplay 直接播放入站流亲手确认源流正常再去查转码参数能省很多时间。4.3 画面模糊或码率假高另一个高频问题码率明明设了 4500kbps观众端看还是糊的大片动态场景全是马赛克。我一开始以为是平台压画质后来发现是我自己的转码参数不对。这里有个概念要分清-b:v设的是目标码率但如果不同时配-maxrate和-bufsize编码器会在某些场景瞬间突破目标码率然后因为网络缓冲被强制丢弃数据结果动态画面反而崩得更厉害。正确做法是把三件套一起配-b:v 3000k -maxrate 3000k -bufsize 6000k让编码器始终在可控码率范围内工作。码率预算的计算方式是分辨率 × 帧率 ÷ 压缩因子1080p30 用 4500kbps720p30 用 3000kbps这组经验值在绝大多数内容类型下表现都不错。另外一个常见误操作是把-preset设成ultrafast。这虽然让 CPU 占用大幅下降但编码效率也大幅下降同码率下画质肉眼可见地变差。除非机器性能实在不够否则我建议最低用veryfast这是画质、码率、CPU 三者平衡得最好的档位。4.4 平台特有的兼容性陷阱不同平台对直播流的挑剔程度不一样这些平台脾气不是看文档就能全部发现的很多是要实际推流试出来的。我整理几个踩过的有些平台对分辨率要求严格必须是偶数且分辨率不能低于某个门槛704×576 这种非标准分辨率会直接被拒有些平台只接受 44100 或 48000 的音频采样率其他采样率会导致声音能出但花屏或者持续卡顿还有一些平台要求推流链接里必须带特定的串流密钥格式填错一个字符可能被网关静默丢弃而不是直接报错表现就是推流进程显示连接成功但平台端一直黑屏。针对这些情况我的做法是维护一张平台兼容性参数表每个平台一行记录它的推流地址格式、码率上限、关键帧要求、音频规格、分辨率规则。每接入一个新平台先在测试直播间完整跑一遍全链路并主动检查推流进程存活 ffprobe 出站流参数 测试平台端画面正常三件事全对了才切到正式直播。这张表现在是我们团队的标准化文档新成员接平台时照着做就不会踩低级坑。5. 成本估算与后续还能怎么扩展5.1 带宽、转码开销到底怎么算自建 OneLive 绕不开一个问题服务器要多大带宽很多人一开始低估了出站带宽的消耗。假设源流是 4500kbps分发给 3 个平台那么中心服务器的出站流量大约等于 4500kbps × 3也就是 13.5Mbps加上监控拉流和其他开销按 15Mbps 来规划比较稳妥。按流量计费的话可以算一笔账15Mbps 每小时产生的流量大约是 15 × 3600 ÷ 8 6750MB约 6.75GB。如果每月直播 100 小时就是 675GB 的出站流量。国内主流云厂商的按流量计费大约在 0.8 元/GB 左右这笔费用会在 540 元左右浮动如果长期高频使用不如直接上固定带宽或按带宽峰值计费的方案成本能压到更低。我的建议是直播频率不高的按流量计费更灵活每天都播的固定带宽更划算。别只看单价要结合自己的月播量算总账。服务器规格其实不用追求高配。如果走纯拷贝分发2 核 4G 内存的机器就能稳定跑三五路输出一旦需要实时转码建议至少翻倍到 4 核 8G并且优先选主频高的 CPU因为转码吃的是单核性能不是多核数量的机械叠加。5.2 OneLive 还能怎么玩录像、多码率与更多协议OneLive 把单路进多路出跑通之后很多事情会变得顺理成章。第一个是我最近在做的扩展把入站流同时录制一份到服务器本地直播结束后自动剪辑存档。做法非常简单在 Nginx RTMP 配置里把record off改成record all设置录音目录即可事后用 ffmpeg 做转封装就能得到回放文件。第二个方向是多码率输出。如果目标是服务不同网速的观众只给一个平台传一路 4500kbps 是不够的可以同时生成 1080p 和 720p 两路信号分别推给平台的多个直播线路观众端就能按自己的网速选清晰度。代价是转码开销翻倍但体验提升非常明显适合知识付费或者大型公开课场景。第三个方向是接入 SRT 协议做机房之间的灾备链路。我之前提过RTMP 跨长距离传输时稳定性不太够但 SRT 自带丢包重传专线或跨地域场景下表现好很多。OneLive 的中心服务器之间可以用 SRT 互通某个节点故障时自动切换主播端和观众端都不需要任何感知。最后再分享一个我自己坚持到现在的小习惯每次正式开播前先推一条测试流跑 30 秒用 ffprobe 检查完音视频参数再放行。这 30 秒的投入帮我挡下了至少三次因为平台接口临时变更导致的开播即黑屏事故。做直播技术这件事很多问题不是靠聪明解决的是靠提前多验证一步解决的。OneLive 走到现在最大的心得就是把这个多验证一步的原则落到了每一个环节里。
