企业官网建设流程全解析

RTMP转 WebRTC 这个组合，放在几年前还属于“能用但折腾”的方案，现在已经是低延迟直播测试的标配路径。推流侧继续用 RTMP——OBS、硬件编码器、现有推流 SDK 都支持；播放侧换成 WebRTC——浏览器原生能力，不需要装 Flash，也不需要额外 App，延迟可以做到秒级以内。关键在中间那一层：流媒体服务把 RTMP 拉进来的流转成 WebRTC 可播放的会话。

这次我们完整过一遍 rtmp2webrtc 测试环境的搭建过程：从环境准备、服务启动，到 FFmpeg 模拟推流、浏览器 WebRTC 拉流，最后用直接方法对比延迟、排查链路问题。整套流程在不同 Linux 发行版上通用，麒麟操作系统等国产化环境我会单独标出需要注意的点。不涉及复杂的集群和商业化调度，目标是让你有一台机器就能把“RTMP 进、WebRTC 出”的链路跑通，并且知道每一步怎么验证、出了问题从哪里查。

如果你负责直播平台的低延迟改造、在线课堂或者远程协作类项目，或者刚接触 WebRTC 网关但不想直接跳到源码级别，这篇文章可以先收藏起来照着做。

1. RTMP 转 WebRTC 核心链路速览

RTMP 和 WebRTC 是两套差异很大的协议。RTMP 基于 TCP 长连接，推流简单稳定，几乎所有推流端都支持，但播放延迟通常在 3 到 10 秒；WebRTC 基于 UDP 和 ICE/DTLS/SRTP 一套组合，播放端只需要浏览器支持，延迟有机会压到 1 秒以内。Rtmp2webrtc 测试环境的核心，就是在服务端同时处理这两种协议：一端接收 RTMP 推流，另一端把媒体数据转成 WebRTC 拉流会话。

从测试环境的角度看，整套链路可以拆成三块：

如果用 SRS 作为参考方案，它自身带 HTTP 管理和播放测试页，部署最简单的方式是 Docker 跑一个容器，把 RTMP、HTTP API、WebRTC 几个端口映射出来。也可以用源码编译，适合需要二次修改或者跑在特殊 CPU 架构上的场景。

1.1 参考开源项目的选择

SRS、ZLMediaKit、MediaMTX 都能做 RTMP 到 WebRTC 的转换，但侧重点不同。

本文以 SRS 为例展开，因为它在 rtmp2webrtc 这块的配置最直观，官方文档也齐全。但下面的验证思路和排查方法对另外两个项目同样适用。

2. 适用场景与使用边界

rtmp2webrtc 测试环境首先是一条验证链路，不是一个生产直播平台。它真正解决的问题是：你手上已经有 RTMP 推流端（比如 OBS、无人机图传、硬件编码器），但播放端需要低延迟体验，不能容忍 HLS 那种 5 到 10 秒的延迟。测试环境先把这条链路从 0 到 1 跑通，验证延迟是否达标、长时间运行是否稳定、网络波动下是否会出现花屏和卡顿。

比较适合的场景包括：

• 在线课堂和互动教学，老师端用 OBS 推 RTMP，学生端在浏览器里低延迟观看。
• 活动直播的导播台到播放页的传输，导播台输出 RTMP，网页播放器用 WebRTC 拉流。
• 企业内部远程巡检、设备画面回传，推流设备支持 RTMP 但监控大屏需要秒级延迟。

不意味着适用所有场景。如果是要做大规模公网分发，WebRTC 对 NAT 穿越和服务端 ICE 配置的要求比 HTTP-FLV 高，CDN 覆盖成本也更高，这类场景用 WebRTC 网关的成本要重新评估。如果只是简单的录播回放，HLS 仍然是更稳定的方案，不需要引入 WebRTC。

使用边界必须明确：测试环境涉及到的视频画面、音频内容、人物肖像都需要有合法授权，推流素材不要使用未经授权的影视剧、音乐、他人肖像。如果测试环境部署在可公网访问的服务器上，一定要加推流鉴权和播放页访问控制，避免被恶意推流或劫持资源。直播相关内容如果对外公开，还需要符合内容平台和监管要求，这些在搭建环境时就应该同步考虑，而不是等出现问题再补。

3. 测试环境准备

这个测试环境对硬件要求不高，核心是能跑 Linux 服务、能跑 FFmpeg 推流、能打开浏览器。下面是通用检查清单，具体版本号以你选用的项目官方文档为准。

3.1 硬件与网络

如果你的机器是 Windows，也可以用 WSL 或虚拟机跑 Linux 服务，播放端浏览器仍用 Windows 下的 Chrome 访问。这样推流端在 Linux，播放端在 Windows，环境更接近真实局域网链路。

如果部署环境是麒麟操作系统，注意先确认系统架构是 x86_64 还是 aarch64，下载对应架构的二进制或自行编译。麒麟的包管理器可能是 apt 系也可能是 yum 系，依赖库名称会有差异。部署前先执行uname -m看架构，再用系统自带的包管理器搜索依赖包名，不要直接照搬 Ubuntu 的命令。

3.2 软件依赖

如果不用 Docker，源码编译方式需要额外准备 gcc、make、cmake、libssl-dev、libsrtp-dev 等编译依赖。这个列表在不同系统上名字不完全一样，漏掉依赖会在 configure 阶段报错，到时候按提示补装即可。

4. 安装部署与启动方式

以下是通用部署步骤，以 SRS 为例。实际使用时，请以对应项目的官方 README 为准。

4.1 Docker 方式启动

这是最快的方式。先确保 Docker 已安装，然后执行：

# 拉取并启动 SRS，端口需要根据官方镜像文档确认 docker run --rm -p 1935:1935 -p 1985:1985 -p 8080:8080 \ -p 8000:8000/udp \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5

各端口作用如下：

启动后终端会输出日志，看到类似start server或者listen on 1935的日志，基本说明服务起来了。然后用curl验证 HTTP API：

curl http://127.0.0.1:1985/api/v1/versions

返回 JSON 里有版本号，说明 HTTP API 可用。

4.2 源码编译方式

如果需要改代码或跑在特殊架构上，可以走编译方式：

git clone https://github.com/ossrs/srs.git cd srs/trunk ./configure --full make ./objs/srs -c conf/rtmp2rtc.conf

编译时间取决于机器性能，通常在 10 到 30 分钟。编译完成后，关键是检查配置文件。SRS 需要用以下配置同时开启 RTMP 和 WebRTC：

# rtmp2rtc.conf 核心片段，实际参数以项目版本为准 listen 1935; max_connections 100; srs_log_tank console; rtc_server { enabled on; listen 8000; # 如果本机测试，candidate 可以直接用 127.0.0.1 candidate 127.0.0.1; } vhost __defaultVhost__ { rtc { enabled on; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } }

注意candidate这个参数。如果播放端和推流端都在本机回环地址，可以写 127.0.0.1；如果要跨设备测试，需要改成服务器实际 IP 或公网 IP，否则 WebRTC 协商阶段会拿到错误地址，播放端连接失败。

4.3 启动脚本与端口占用检查

每次测试环境重启后，端口占用最常见的错误是先启动了旧进程，或者端口被其他服务占用。启动前检查：

# 查看相关端口是否被占用 ss -tulpn | grep -E "1935|1985|8080|8000"

如果端口被占用，要么杀掉旧进程，要么改配置换端口。推荐测试环境固定使用一套端口，避免排查问题时记混。

5. 功能测试与效果验证

服务启动后，开始验证完整链路。顺序是：先确认推流能进来，再确认 WebRTC 能播放，最后做延迟对比。

5.1 FFmpeg 推流测试

用 FFmpeg 生成一段测试视频推流，不需要提前准备素材文件：

# 生成测试画面：1280x720，30fps，H.264 + AAC，推送到 SRS ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ -f lavfi -i sine=frequency=440:sample_rate=44100 \ -c:v libx264 -preset veryfast -tune zerolatency -g 30 \ -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1/live/livestream

参数里-tune zerolatency是低延迟编码关键，-g 30表示每 30 帧一个关键帧，便于 WebRTC 快速追帧。

推流命令保持运行，然后打开 API 查看流状态：

curl http://127.0.0.1:1985/api/v1/streams/

如果返回的流列表里有livestream，说明 RTMP 推流已经成功进入服务。这一步没通过就先不要往后走，重点排查推流地址、端口、防火墙。

5.2 WebRTC 播放验证

浏览器打开http://127.0.0.1:8080/players/rtc_player.html，填入 WebRTC 播放地址。SRS 的 WebRTC 地址格式一般是：

webrtc://127.0.0.1/live/livestream

也可以直接在网页里选WebRTC模式，点播放。如果页面出现测试画面并且音频能听到，说明协议转换链路是通的。

注意 Chrome 需要允许自动播放音频，否则页面会静音。浏览器控制台如果有getUserMedia或 ICE 报错，重点看 F12 有没有红色跨域错误。直接用 IP 访问一般没有跨域问题，但如果你用了自定义域名，需要在服务端配置 CORS 或改用同源部署。

5.3 RTMP 播放与 WebRTC 播放延迟对比

要验证 rtmp2webrtc 的价值，最直接的方式是同一个推流，分别用 RTMP 播放和 WebRTC 播放，对比延迟。

用 VLC 播放 RTMP 流：

vlc rtmp://127.0.0.1/live/livestream

VLC 上右键播放器，选择“媒体信息”或者统计信息，可以看到网络缓存和缓冲设置。默认 VLC 缓冲较大，延迟会被放大，这不是服务端的问题。用 SRS 自带的播放器页面选择HTTP-FLV播放，再和WebRTC播放对比，数据更有参考价值。

一个简单的手动测延迟方法：

1. 推流画面里放一个秒表或计时器（用 OBS 添加文本源显示当前时间）。
2. 同一台电脑上同时打开 FLV 播放页和 WebRTC 播放页。
3. 手机拍照或截图，对比两个播放器显示的时间差。

这种方法误差有点大，但足够验证 WebRTC 是否明显比 FLV 更低延迟。正式压测时可以用摄像头拍摄秒表画面，再用视频分析软件对比帧号。

WebRTC 播放页如果已经出画面，说明数据通路是通的。注意如果 WebRTC 播放页黑屏，但后台没有报错，先检查浏览器是否支持 H.264。部分系统自带浏览器只有 OpenH264 或 VP8 支持，而 SRS 默认推的是 H.264，需要编解码协商成功才会出画面。

5.4 连续推流稳定性测试

测试环境不止要验证“能不能通”，还要验证“能不能稳”。建议做一次至少 30 分钟的连续推流：

# 持续推流 30 分钟，观察服务端日志和播放端是否有断流 ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ -c:v libx264 -preset veryfast -g 30 \ -f flv rtmp://127.0.0.1/live/livestream

同时开一个脚本周期请求 API，记录流状态：

for i in $(seq 1 60); do curl -s http://127.0.0.1:1985/api/v1/streams/ | grep -q livestream \ && echo "$(date) streaming ok" || echo "$(date) stream lost" sleep 30 done

如果出现stream lost，说明推流中断或服务异常，结合服务端日志和推流端日志分段排查。

5.5 多路流测试

生产环境往往不止一路流。测试环境中至少要验证几路流并发推流和播放不互相影响：

# 同时推多路不同 stream 名的流 ffmpeg -re -f lavfi -i testsrc=size=640x360:rate=25 \ -c:v libx264 -preset veryfast -g 25 \ -f flv rtmp://127.0.0.1/live/stream1 ffmpeg -re -f lavfi -i testsrc=size=640x360:rate=25 \ -c:v libx264 -preset veryfast -g 25 \ -f flv rtmp://127.0.0.1/live/stream2

多路流的重点不是“服务不会崩”，而是“一路流出问题是否会拖垮其他流”。可以在测试中故意停掉一路推流，观察另外一路是否正常。如果一路流异常导致全局卡顿，说明服务配置或资源隔离还需要调整。

6. 接口能力与接入方式

rtmp2webrtc 测试环境虽然核心是验证链路，但如果不提前验证接口能力和接入方式，后面要接到自己的播放器或管理系统时容易反复返工。

6.1 服务端 HTTP API

以 SRS 为例，通过 HTTP API 可以查询、管理流，接口路径大致如下：

# 获取版本 curl http://127.0.0.1:1985/api/v1/versions # 获取全部流列表 curl http://127.0.0.1:1985/api/v1/streams/ # 踢掉指定流（示例，具体接口以项目文档为准） curl -X DELETE http://127.0.0.1:1985/api/v1/clients/{client_id}

这类接口适合接进自己的后台，用来展示直播列表、做流健康检查和自动踢流。测试环境阶段建议先把“获取流列表”这一个接口跑通，后面的管理逻辑可以慢慢加。实际项目里接口返回字段会随版本变化，调试时先看原始 JSON 结构，再写解析代码。

6.2 播放器接入方式

播放器接入有三种方式，测试环境建议都试一遍：

如果只是做技术验证，用官方播放器页面就足够。如果后续要嵌进业务系统，至少要完成一次“把播放器集成到你自己的网页里”的试验，重点验证：跨域配置、地址生成规则、自动播放策略。

6.3 录制备份

测试环境的录像不是必需的，但建议把推流源录制一份，方便回看和排查问题。可以用 FFmpeg 从 RTMP 流拉流录制：

ffmpeg -i rtmp://127.0.0.1/live/livestream -c copy output.flv

录制时注意磁盘空间，长时间测试录像可能增长很快。测试环境建议录制 5 到 10 分钟即可，没必要全部保留。

7. 资源占用与性能观察

rtmp2webrtc 测试环境的资源占用主要来自三部分：流媒体服务本身、FFmpeg 推流进程、浏览器播放渲染。重点观察前两者。

7.1 流媒体服务资源观察

在推流持续运行的情况下，用top或htop观察进程 CPU 和内存。SRS 这类事件驱动架构的服务在单路转流时 CPU 占用通常很低，内存占用也不会太高。但具体数字取决于：推流分辨率、码率、WebRTC 播放人数、GOP 大小、是否开启转码等，不要以别人的数字直接套用，以你本机测试为准。

如果 CPU 占用异常升高，优先检查是否误开了转码服务，或者推流分辨率/码率设置过高。测试环境建议先跑 720p 或 1080p，码率控制在 2 到 4 Mbps，先把正常基线摸清再说高负载。

7.2 网络与 UDP 端口

WebRTC 播放依赖 UDP，尤其是 8000 端口。跨网络测试时，服务端防火墙、安全组、NAT 规则都必须放行 UDP。TCP 端口通而 UDP 端口不通，是 WebRTC 测试中最常见的坑之一。

排查方法：推流正常，播放页面长时间处于连接中，优先看 UDP 端口是否可达。

# 用 nc 测试 UDP 端口，端口是否开放以实际输出为准 nc -uvz 127.0.0.1 8000

如果服务端部署在云主机或内网，需要注意 ICE candidate 配置。服务端拿到公网地址，客户端才能穿过 NAT 直连。测试环境如果仅在局域网内，candidate 配置成服务器内网 IP 即可。

7.3 推流端与播放端的相互影响

FFmpeg 推流进程本身也会占 CPU，尤其是在低配机器上。测试环境最好把推流端放在一台机器，流媒体服务和浏览器播放放另一台机器，避免 FFmpeg 和浏览器抢 CPU，导致结果偏差。

如果只能一台机器，至少观察一下 top 输出，确认 FFmpeg 和流媒体服务不会因为 CPU 竞争出现推流中断或播放卡顿。

7.4 降低资源占用的手段

几个通用调优方向：

8. 常见问题与排查方法

下面是这套测试环境最常见的问题和排查思路，汇总成表格方便检索：

最常用的排查手段就三个：看服务端日志、看浏览器控制台、curl 接口验证。这三个信息都拿到手，绝大多数问题都能定位到具体环节。

日志查看方式：

# SRS 日志默认打在前台，如果用 docker 运行用 docker logs docker logs --tail 100 <container_id>

如果发现日志里反复出现握手失败或协商失败，优先检查 candidate 配置和端口。如果是推流端报错，看 FFmpeg 输出是连接问题还是编码问题，通常它们会给出明确的错误码。

9. 最佳实践与使用建议

测试环境能跑通不等于生产环境能直接用。以下建议能帮你减少返工。

9.1 第一次测试先小参数跑通

先不要推 4K 高码率流，先用 640x360 或 1280x720 的低码率流跑通整个链路。延迟、稳定性、资源占用这些指标，在小参数下先拿到基线，再逐步增加复杂度。如果一开始就上高参数，出了问题很难分清是协议问题还是性能问题。小参数跑通后，再验证高分辨率会更安心。

9.2 保留一套最小可运行配置

把推流命令、服务启动命令、播放地址、验证命令整理成一个 README 或脚本目录，方便下次启动测试环境时直接照做。最小可运行配置包括：一份可启动的配置文件、一条 FFmpeg 推流命令、一条播放验证方法、一个 API 检查步骤。不要再靠记忆拼命令。

# 保存一个启动脚本示例 start_rtmp2webrtc_env.sh #!/bin/bash docker run --rm -d \ -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 8000:8000/udp \ --name rtmp2webrtc-test \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 sleep 5 curl -s http://127.0.0.1:1985/api/v1/versions

这个脚本只是一个雏形，实际删改以你选择的项目和环境为准。

9.3 输入素材、输出录像、服务端日志分目录管理

测试环境很容易产生一堆碎文件：测试视频、录像、日志、截图、配置备份。建议目录结构如下：

rtmp2webrtc-lab/ ├── configs/ # 服务配置和启动脚本 ├── inputs/ # 推流素材、测试图片 ├── outputs/ # 录像、截图 └── logs/ # 服务端日志

每次测试前把目录清空或按日期建子目录，避免把不同日期的测试结果搞混。

9.4 批量验证和自动化

需要做长时间稳定性测试时，不要手动盯页面。写一个简单的 shell 或 Python 脚本定期请求 API，记录流状态，上下行码率等指标，超过阈值就报警。API 接口返回的 JSON 结构可以先手动请求一次看清楚字段再写脚本。

9.5 安全与合规操作清单

• 推流鉴权一定要开启，哪怕是测试环境，防止被外部扫描到后恶意推流。
• WebRTC 播放页不要暴露到公网，至少加一层访问密码或 IP 白名单。
• 测试素材使用 FFmpeg 合成画面，不要使用有版权的视频、音乐、影视片段。
• 如果测试涉及真实人物画面，确认本人同意在测试环境中使用。
• 服务端日志可能包含 IP 和请求参数，日志文件要注意访问权限，及时清理。
• 截图和录像不要超过测试需要的时间，用完之后定期删除。

10. 总结与下一步

这次我们梳理了一条完整的 rtmp2webrtc 测试链路：推流端用 FFmpeg 生成 RTMP 流，流媒体服务负责协议转换，播放端用浏览器验证 WebRTC，再通过 API 和日志做状态和能力验证。整套测试环境跑下来，最值得关注的是四个点：链路是否能跑通、延迟是否符合预期、长时间运行是否稳定、接口是否能满足后续接入需求。

先从最小配置开始，启动服务后用 FFmpeg 推一条测试流，再打开 WebRTC 播放页验证画面和声音，最后对比 FLV 延迟和 WebRTC 延迟。这四步里面最容易踩坑的就是 WebRTC 播放器连不上服务，问题根源往往在 UDP 端口没放行或 candidate 配置不对，排查时优先看这两处，能节省不少时间。

下一步扩展方向可以从三段走：把推流端从 FFmpeg 换成 OBS 或硬件编码器，验证真实设备接入；在服务端增加鉴权和播放页控制，贴近业务使用方式；再往后可以评估 SRT 协议、WHIP 协议等其他低延迟接入方式，对比不同协议在延迟、稳定性和跨网能力上的差异。测试环境本身就是用来快速验证这些东西的，链路跑顺之后再往上叠加业务，心里就有底了。