企业官网建设流程全解析

很多做内容的人第一次听到“JRS免费直播平台”这个项目代号，第一反应是“又一个直播软件”。实际上它并不是某个现成的App，而是一套低成本、可自行部署的直播系统方案的项目代号。核心思路很直接：用开源推流工具加轻量转发服务，把采集、编码、分发、播放四个环节串起来，在没有商业直播平台“入场费”和“抽成”的前提下，跑通一条完整直播链路。这篇文章，我会把这条链路的每一个环节拆开，从选型到落地，从参数配置到踩坑排查，完整过一遍，给想做个人直播、在线教学、小规模分享会的人一个可以直接抄作业的参考。

1. 先看本质：一套“免费”直播系统的链路到底由什么组成

1.1 核心需求拆解：你要的其实不是“免费”，是“可控”

很多人一听到免费直播平台，脑子里出现的是“不花钱”。但我在实际做这套方案的时候发现，真正驱动大家去自建系统的诉求，远远不只是省钱。更核心的两个词是“可控”和“可定制”。

商业直播平台几十块钱一个月的基础套餐看起来不贵，但问题出在细节：观众进来要注册、直播间有平台Logo和水印、直播内容审核规则不透明、数据接口封闭、回放功能要另外加钱。对于一场内部培训、一场产品发布演练、或者一次小圈子技术分享，这些限制非常致命。你自己搭一套系统，推流地址是你自己的，播放器是你自己的，观众进来不用登录，视频画质和延迟自己调，数据自己统计。这不只是钱的问题，是整个直播体验和品牌展示的自主权。

另外一个很现实的需求是“流量隔离”。自建方案可以只服务特定的用户群体，比如公司内部员工、付费社群成员、线下合作机构的学员，做一个独立的观看入口。这个场景下，通用直播平台反而是累赘。

所以，这套系统的目标不是“替代所有直播平台”，而是“在特定场景下，提供比通用平台更贴身的直播服务”。理解这个定位，后面选型才不会走偏。

1.2 一条直播链路的四个不可省略环节

任何直播系统，无论商业还是自建，本质上都是四个环节的串联：

直播画面从摄像头、采集卡或屏幕捕获而来，这是信号的源头。然后是编码环节，把原始视频信号压缩成适合网络传输的H.264或H.265码流。编码后的数据需要依赖一个分发服务，即推流和转发的服务器端，把一路输入复制成多路输出，推给各个观看端。最后是播放环节，观众通过浏览器、小程序或播放器App解码并实时呈现画面。

只要把这四个环节理解透，所谓的“自建直播平台”其实没那么神秘。你只需要在每个环节选一个工具，把它们拼起来。真正决定项目难度的，是各个环节之间是否兼容、协议是否统一、参数是否匹配。我见过太多人一上来就折腾搭建服务器，最后发现瓶颈根本不在服务器，而是在推流端的编码参数没调对。所以我的建议是：先摸清链路，再动手。

2. 工具选型：四环节分别选什么，为什么这么选

2.1 推流端：OBS Studio依然是最稳的基石

推流端的任务是把画面采集并编码后推给服务器。这个环节我非常推荐直接用OBS Studio，免费开源，Windows、macOS、Linux全平台支持，硬件加速编码和软件编码都做得很成熟。

为什么不用它自带的“简易推流”模式？我见过很多小白用户直接填服务器地址就开推，结果画面模糊、音画不同步，然后跑来问我怎么回事。问题几乎都出在默认参数上。OBS的安装很简单，真正影响直播质量的，是推流前你必须手动确认的四个参数：

分辨率、帧率、视频码率、音频码率。我们在后面的实操部分会逐项讲清楚怎么配。

补充一点，如果你是纯手机直播场景，可以四环节里的推流端直接用带RTMP推流功能的App，比如摄像头类的专业推流应用。但在稳定性上，电脑端OBS依然是首选。手机端更适合户外突发场景，电脑端适合正式、长时间的内容输出。多数自建项目，我建议优先考虑电脑推流。

2.2 分发端：SRS比nginx-rtmp更适合新手和长期维护

分发端是整个系统的中枢，接收推流端的RTMP流，再转成不同协议分发给观看端。最常用的开源方案是nginx-rtmp-module和SRS（Simple Realtime Server）。

我的建议很明确：优先选SRS。原因不复杂，nginx-rtmp-module已经很多年没有大版本维护了，功能也相对单一，主要就是收RTMP推流、再吐RTMP或者HLS切片。而SRS对现代播放需求的支持更完整，可以同时对外提供RTMP、HTTP-FLV、HLS、WebRTC等多种协议，配置也更简单，还有清晰的中文文档和活跃社区。

SRS部署起来也并不重。用官方Docker镜像方式，一条命令就能起一个服务实例：

docker run -d -p 1935:1935 -p 1985:1985 -p 8080:8080 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5

这里容器里的1935端口是RTMP入口，1985是SRS的HTTP API端口，8080用于对外提供HTTP-FLV和HLS文件流。命令跑起来之后，SRS就会在默认配置下运行。生产环境你需要改改配置，这个我们在实操部分细说。

2.3 播放端：按延迟需求决定用HTTP-FLV还是HLS

播放端是观众直接接触的环节，也是坑最多的地方。最底层的逻辑是：延迟目标和分发协议强相关。想低延迟，就得在播放端用能实时拉流的协议；想要极致的兼容性，就得接受几秒钟以上的延迟。

三种主流协议的取舍可以参考这个对比：

我在实际项目里的默认组合是：播放端优先用HTTP-FLV方案，配套flv.js收流，延迟能压到三秒内，画质损失也小。如果某些播放端浏览器兼容性实在解决不了，或要做回放，就直接切HLS。后者的延迟虽然高一些，但胜在开箱即用，几乎不用写额外代码。

2.4 为什么我不建议一开始就上“高可用”架构

很多刚接触自建直播平台的人，上来就问“要不要搞负载均衡、多节点分发”。我得泼一盆冷水：绝大多数场景根本不需要。

如果你的观众规模在几百人到几千人这个级别，一台带宽够用的SRS服务器已经能撑住。你真正的瓶颈往往不是软件，而是上行带宽。比如一台服务器按H.264 1080P直播用4.5Mbps码率算，一小时约2GB流量。单台云服务器按每月500GB流量套餐算，足够支撑两百多个小时的直播观看，这对绝大多数个人创作者和中小企业来说绰绰有余。

真正需要上多节点、做CDN、做边缘转发的，是那种同时几千人在线、跨地域大规模实时互动的场景。起步阶段就上这种架构，只会把简单问题复杂化。能用单机解决的问题，先不要用集群来解决。

3. 实操部分：从0到1跑通一条直播链路的完整过程

3.1 推流端编码参数的计算逻辑

在OBS里，推流参数绝对不是拍脑袋填的，它由你的“源头画质”和“上传带宽”共同决定。

我建议的基准配置是：视频分辨率按你内容源的原始分辨率来，常见的1080P居多；帧率设定在30fps；视频码率区间则为4500~6000Kbps。如果你上传带宽不够，比如只有8Mbps上行，那么码率建议降到3000Kbps以下，别硬顶1080P，改720P（2500~3500Kbps）更现实。

音频这块，讲话类内容（一个人对着麦克风说话）128Kbps就够，双声道的音乐类内容建议拉到192Kbps，更高的音频码率对直播体感和成本提升都有限，不必追求极值。

还有两个容易被忽略的进阶参数：关键帧间隔和编码档位。关键帧间隔，我称为直播延迟的“隐形开关”：OBS里设置的“关键帧间隔（秒）”直接影响播放端的起播速度。建议设置为2秒，这样播放器能快速找到关键帧并开始解码，延迟体验明显更好。编码档位则是在OBS的“输出—输出模式—高级”里选，软件编码选x264，设定为“medium”，画质和CPU负载均衡。硬件编码（如NVENC）在同码率下画质略逊，但CPU占用低，你可以按需选择。

注意：不要用“无损”或者高码率的录制参数直接直播。直播和录制的码率模型不同，过高的码率会让观众端缓冲卡顿，而你自己的长传带宽也容易打满，反而丢帧。

3.2 分发端配置：SRS接收推流并输出多协议

SRS的默认配置已经能接收RTMP流，但我建议按实际需要改一下配置再上线。一个典型的SRS配置大概长这样：

listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_server { enabled on; listen 8080; dir ./objs/nginx/html; } vhost __defaultVhost__ { hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 2; hls_window 12; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } }

这个文件里几个关键项解释一下：http_remux 就是用来开启HTTP-FLV拉流转发的，开启后观众端可以直接用HTTP地址拉流；hls_fragment设置为2秒，意思是每个TS切片时长为2秒，切片时长直接影响HLS播放的延迟和兼容性，太短了会让播放器频繁请求切片导致卡顿，太长了则延迟明显，2秒是经实测比较平衡的值。

配置改好之后，重启容器让配置生效。用文件挂载的方式启动SRS，确保配置变更不会因为容器重建而丢失：

docker run -d \ -p 1935:1935 \ -p 1985:1985 \ -p 8080:8080 \ -v /data/srs.conf:/usr/local/srs/conf/srs.conf \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 \ ./objs/srs -c conf/srs.conf

启动完成后，用下面这个地址测试推流（推流地址里的app和stream的名字可以自己起，但要和后续拉流地址保持一致）：

rtmp://你的服务器IP:1935/live/room1

3.3 播放端接入：flv.js实现低延迟播放

播放端这一环，我们直接在HTML页面里引入flv.js，从SRS拉HTTP-FLV流。flv.js是一个通过Media Source Extensions来播放FLV格式的JavaScript库，核心思路是在前端把FLV数据流无损转成浏览器能识别播放的片段，从而实现“纯浏览器看低延迟流”的能力。

一个最小可用的播放器页面如下：

<script src="https://cdn.jsdelivr.net/npm/flv.js@1.6.2/dist/flv.min.js"></script> <video id="player" controls autoplay muted></video> <script> if (flvjs.isSupported()) { var video = document.getElementById('player'); var flvPlayer = flvjs.createPlayer({ type: 'flv', url: 'http://你的服务器IP:8080/live/room1.flv' }); flvPlayer.attachMediaElement(video); flvPlayer.load(); flvPlayer.play(); } </script>

这个地址里的“你的服务器IP:8080”就是SRS里http_server监听的端口。注意这里用的是HTTP而非RTMP，因为浏览器原生不支持RTMP，必须通过FLV协议经过去延迟转发。flv.js在桌面端Chrome、Edge、Firefox上表现都很好，移动端iOS上的Safari因为不支持MSE，所以无法播放HTTP-FLV，这种情况下需要降级到HLS。

我通常推荐的做法是：页面里同时放两个播放器逻辑，一个是flv.js，一个是原生video标签拉HLS地址。通过简单的浏览器能力检测，自动选择走哪种协议。这样你在观看端的体验能维持一个相对稳定的水平，不会因为某个用户用iPhone就直接卡死。

3.4 完整链路联调与延迟实测

配置完所有环节，别急着关掉OBS，先做三轮完整的链路验证。

第一轮是“本地验证”：OBS推流后，在同一个内网的手机或另一台电脑上拉流播放，重点看画面是否连贯、音画是否同步。内网环境不受外网带宽影响，如果这里都卡顿，说明推流端参数或服务器端口配置有问题。

第二轮是“公网验证”：把播放地址发给一个外网环境的朋友，让他实际打开观看。这能暴露你的服务器带宽是否够用、防火墙是否挡了不必要的端口。RTMP需要放通1935端口，HTTP-FLV和HLS需要放通8080端口。云服务商的安全组和服务器防火墙都要检查，缺一不可。

第三轮是“持续稳定性验证”：运行一场超过30分钟的直播，观察CPU占用、内存变化、网络流量曲线。SRS在长连接场景下偶尔会触发文件句柄数限制，可以提前调大系统限制，避免直播到一半服务挂掉。

我实测下来，全链路用HTTP-FLV，延迟普遍能稳定在2~3秒左右。这里的延迟指的是从主播说话到观众听到的延迟。配合2秒关键帧间隔，观众端的起播速度也很快，基本是点开播放器后1秒内出画面。

3.5 一个完整案例：一场1小时技术分享的直播

用一个真实跑过的场景来做全流程复盘：当时我以一个几十人规模的技术社群身份，做一场“Web性能优化入门”的公开分享，观众通过一个网页看直播，不要求登录，也不要求注册。

我的完整执行清单是：主讲人电脑装OBS，分辨率1080P，帧率30fps，视频码率5000Kbps，音频码率128Kbps，关键帧间隔2秒，编码用x264的medium档位。画面采集用的是显示器捕获加摄像头小窗。分发端用一台2核4G的云服务器，系统为Ubuntu，带宽出口是5Mbps，部署SRS单机服务。观看端网页用flv.js为主、HLS兜底。直播结束后，额外用ffmpeg把录制好的FLV文件转成MP4回放文件：

ffmpeg -i record.flv -c copy record.mp4

整场直播1小时，服务器流量消耗约2.4GB，全程无卡顿，观众端延迟稳定在2.5秒左右，后台看到的在线峰值人数约60人，服务器CPU占用长期低于30%。这个结果很能说明问题：一个几百人规模的自建直播场景，对资源的要求完全在个人可控范围内。

4. 常见问题与排查技巧实录

4.1 推流失败或反复断流

这种问题最常见的原因是地址拼写错误。注意区分推流地址和串流密钥（Stream Key），OBS里填的是“rtmp://服务器IP:1935/live/”，二者不能搞混。其次要检查端口是否放通：云服务器安全组、ECS防火墙、本机防火墙三层都要检查。你可以在本地用telnet做端口测试：

telnet 服务器IP 1935

如果端口不通，先查安全组放行情况。还有一个容易忽略的点：串流密钥不要包含特殊字符。有些播放器或服务器对接时对特殊字符处理不规范，直接导致推流地址解析失败，密钥用数字加字母最稳妥。

4.2 播放端延迟过大，从3秒涨到15秒

延迟突然飙升，最常见的原因是播放端走了HLS而不是HTTP-FLV。排查方法很简单：用浏览器的开发者工具看网络请求，如果发现大量TS切片文件的请求，说明播放器被降级到HLS了。这时候优先检查flv.js是否能正常加载、浏览器是否支持MSE。

次要原因是OBS里关键帧间隔配置过大。如果关键帧间隔被设成了5秒甚至10秒，播放端就要等下一个关键帧才能起播，感知上的延迟就会成倍增加。记得关键帧间隔按2秒配。

4.3 画面清晰度不足，观众反馈“糊”

我先提一个概念：直播清晰度和码率强相关，分辨率高不代表画质好。如果码率只有1500Kbps却硬压1080P的画面，画面会出现严重的马赛克和噪点。判断标准很简单，用直播画面截图对比原始画面截图，查看细节损失情况。

解决办法有两个方向：一是降低分辨率到720P，同时把码率稳定在2500~3500Kbps；二是保持1080P并把码率提到6000Kbps。前者适合内容源清晰度有限的场景，后者适合屏幕共享、演示文稿这类细节丰富的画面。注意，屏幕共享时建议把OBS的“色彩范围”设为“完整”，避免画面发灰。

4.4 观众数量增多后出现卡顿

单机SRS不加CDN的情况下，卡顿一般不是服务器性能问题，而是带宽瓶颈。假设每路观看端以HTTP-FLV方式拉流，码率5000Kbps意味着一个观众要占用约0.6MB/s带宽。如果你的服务器带宽只有5Mbps（约0.6MB/s），那么超过8个观众在线就开始卡了，这是一个很简单的乘法问题。

这种情况下最直接的方案是升级服务器带宽。如果已知在线规模固定，那么就把码率适当降下来。更复杂的方案是接入CDN做分发，但那属于扩展话题了。起步阶段，明确你的容灾能力边界就好。

4.5 移动端H5无法播放的兼容性问题

iOS Safari对MSE支持不足，导致flv.js在iPhone上无法工作。这个问题没有银弹，只能做协议降级。我建议在页面加载时做UA判断和特性检测——如果浏览器支持MSE就走HTTP-FLV，如果不支持就换原生video标签直接拉HLS地址。SRS已配置HLS，所以移动端降级后的体验是有保障的：延迟约5~8秒，但画面流畅稳定。这是现阶段在纯前端方案里最可靠的处理方式。

4.6 直播中途服务器突然自动断开

这个坑我踩过不止一次。默认的Linux系统对每个进程能打开的文件数有上限，长时间运行的SRS进程可能触碰到这个上限，服务直接停摆或拒绝新连接。解决办法是修改全局文件句柄限制，在启动SRS前执行：

ulimit -n 65535

为了系统重启后仍然生效，建议把这条写到SRS的启动脚本或systemd服务文件里。此外，云服务器上的OOM Killer也可能在内存不足时杀掉SRS进程，建议给SRS的systemd服务加上自动重启参数。一个默认宕机自愈的配置，能省去你半夜爬起来手动拉服务的麻烦。

5. 这套方案还能怎么延伸

最后分享一个我实际用得比较多的小扩展：给这套系统加一个“安全房间号”机制。SRS本身支持通过HTTP回调接口做鉴权验证，推流前或播放前，服务器会向你的业务接口询问“这个流是否允许访问”。我在一个付费社群场景里，就是把观众端和火箭验证绑定，用户购买后获得一个有时效性的播放token，播放器拉流时带上token，SRS回调你的接口校验。整体实现并不复杂，但对一个运营性质的直播项目来说，这种可控性非常宝贵。

如果你只是个人用来做内容试播或小众分享，建议从最小配置起步：一台云服务器加一套SRS加OBS，也就两三个小时能跑通。踩过几次坑之后，你会发现直播的核心难点不在工具，而在于你对“采集、编码、分发、播放”这条链路里每一个环节的掌控能力。工具是死的，链路是通的，真正让你项目稳定跑下去的，是对这些细节的持续打磨。