webrtc-streamer实战：基于WebRTC的RTSP低延迟播放方案-平芜编程栈

简介：webrtc-streamer-v0.8.1-dirty-Windows-AMD64-Release是WebRTC流媒体服务器的Windows 64位预编译版，旨在解决实时音视频服务部署繁琐的问题，适合需要快速搭建WebRTC网关的开发者、运维人员，以及想通过实际项目学习WebRTC的零基础体验者和中级进阶开发者。压缩包共94个文件，仅7.29MB，核心可执行程序可直接运行；23个html页面、29个js脚本和5个css文件构成前端控制台与演示界面，6个woff和6个svg等字体图标资源支撑页面样式；json配置便于调整流媒体参数，wasm和tfjs模型（如posenet、coco-ssd）自带AI视觉示例，md和license文档说明使用与授权。目前已有846人学习下载。解压后通过浏览器访问管理页面即可查看实时视频流，无需手动编译和复杂依赖，既适合在Windows环境验证摄像头/屏幕推流、多端低延迟通信，也有助于理解信令交换、ICE候选收集及STUN/TURN协调机制。项目目录分层清晰，能帮助使用者快速定位前端、后端与模型资源，便于在此基础上做二次开发。

1. 为什么需要 webrtc-streamer：低延迟播放的痛点

做监控摄像头或者 IP Camera 接入的时候，大家应该都遇到过同一个尴尬场景：摄像头明明支持 RTSP 协议，浏览器却没法直接播放。Chrome 和 Firefox 早就放弃了原生 RTSP 支持，Safari 虽然有点特殊，但实战中基本指望不上。于是传统的方案就是推 RTMP 流，再用 Flash 播放——但 Flash 已经彻底退场了，这条路直接焊死。

剩下的选择就是 HLS。把 RTSP 转成 HLS，用 hls.js 或者原生 video 标签播放。这个方案兼容性确实好，什么浏览器都能跑，但延迟让人抓狂。我曾经测过一台海康摄像头，从画面实际发生的事情到浏览器里面看到，延迟轻松超过 5 秒钟，甚至 8 秒以上都算正常。对于门铃呼叫、安防告警这种场景，你总不能让用户在门口站 5 秒钟等视频出来。而 WebRTC 在这种场景下几乎是唯一合理的答案，端到端延迟可以做到 300 毫秒以内。

webrtc-streamer 就是干这个的。它是一个轻量级的 WebRTC 网关，运行在服务器上，从摄像头拉取 RTSP 流，然后通过 WebRTC 协议推送给浏览器。浏览器端只需要写很短的 JavaScript 代码，不需要安装任何插件，也不用 Flash，就能看到实时画面。这个项目是开源的，用 C++ 写成，底层基于 GStreamer 做媒体处理，在 GitHub 上常年保持活跃，是国内外做低延迟 Web 监控方案时经常被拿来做标杆的开源项目。

这篇文章我会从原理、部署到前端集成，完整跑一遍 webrtc-streamer 的实战流程，包括我在部署过程中踩过的坑和调优参数。想做低延迟直播、IPC 接入、可视门铃或者 Home Assistant 智能家居集成的朋友，这份内容应该能帮你省下不少时间。

2. 核心架构与工作原理

2.1 webrtc-streamer 在链路中扮演什么角色

先搞清楚整个数据流的走向。摄像头是 RTSP 服务端，浏览器是 WebRTC 客户端，webrtc-streamer 夹在中间，扮演的是一个“翻译官”的角色。

浏览器和 webrtc-streamer 之间通过 WebSocket 交换信令信息，比如 SDP 和 ICE candidate。协商完成之后，媒体数据直接通过 UDP 或者 TCP 传输，走的是标准的 SRTP 协议，所以画面是加密传输的，不用担心局域网内被劫持的问题。webrtc-streamer 内部用 GStreamer 把 RTSP 流解封装、解码（如果需要的话）、重新编码成 VP8 或者 H.264，再封装进 WebRTC 的 RTP 包里。

这个架构最 nice 的一点是：WebRTC 会话是点对点直连的。webrtc-streamer 只负责“撬开”摄像头和浏览器之间的通路，真正传数据的路径上，它只是一个中继，不参与媒体数据的深度加工。相比把所有流量都拉回服务器再转发的传统方案，这种模式对服务器的带宽和 CPU 压力都小得多。

2.2 为什么选择 GStreamer 而不是 FFmpeg

webrtc-streamer 底层用的是 GStreamer 而不是大家更熟悉的 FFmpeg，这一点很多人会好奇。我的理解是，GStreamer 的优势在于它的 pipeline 架构非常灵活，可以像搭积木一样把解码、编码、封装、传输各个模块组合起来，而且对 WebRTC 协议栈的支持是原生级别的，不需要自己再去封装一层 RTP 推流逻辑。

另外一个实际的好处是，GStreamer 的插件生态对硬件解码有很好的支持。在某些嵌入式的设备上，比如 Jetson Nano 或者树莓派，如果你用的是 GStreamer 的硬件加速插件，可以把 CPU 占用压得非常低。这一点在跑多路摄像头的时候会非常有用，我在第 5 节会专门讲 CPU 调优。

2.3 H264 与 VP8 编码的取舍

webrtc-streamer 在把 RTSP 流推给浏览器之前，可以选择保持原来的 H.264 编码直接透传，也可以转成 VP8。我强烈建议优先保持 H.264，原因有两个：

大部分现代摄像头出厂就是 H.264 或者 H.265 编码，直接透传意味着 webrtc-streamer 不需要做转码，CPU 开销几乎可以忽略。
浏览器端的 WebRTC 对 H.264 的支持已经非常成熟，Chrome、Firefox、Safari 都能硬件解码 H.264，又省了一层软解的开销。

转码成 VP8 只在一种情况下有意义：当源摄像头是 H.265（HEVC）编码的时候。因为目前主流浏览器对 WebRTC 传输 H.265 的支持还不够好，所以这时候需要 webrtc-streamer 把 H.265 软解出来，再重新编码成 H.264 或 VP8。这个场景要多留意 CPU 占用，尤其是 4K 摄像头，软解加软编码能把服务器的 CPU 直接打满。我建议直接把摄像头改成 H.264 输出，省心得多。

3. 部署与启动：从二进制到 Docker

3.1 获取编译好的二进制包

webrtc-streamer 的 GitHub Releases 页面提供了 Windows、Linux、macOS 的预编译二进制包。如果你只是想快速验证，直接下载对应平台的文件解压就能跑。

Linux 环境下要注意动态库依赖。我在一台 CentOS 7 服务器上遇到过启动时报错libwebrtc.so找不到的情况，这是因为发布包依赖的系统库版本和系统自带的版本对不上。我的建议是直接用源码编译，过程中让 CMake 自己把依赖拉全，这样兼容性是最好的。

# 编译依赖安装（Ubuntu/Debian） sudo apt-get install -y cmake libglib2.0-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgstreamer-plugins-bad1.0-dev libjsoncpp-dev libwebsockets-dev # 下载源码并编译 git clone https://github.com/ThingSpeak/webrtc-streamer.git cd webrtc-streamer cmake -DCMAKE_BUILD_TYPE=Release . make -j$(nproc)

编译过程会比较长，主要是 webrtc 库本身就很庞大，耐心等即可。如果你不想等，也可以尝试用 Docker 镜像，只需要一条命令：

docker run -d --network host \ --name webrtc-streamer \ registry:8000/webrtc-streamer:latest \ -s 127.0.0.1:80

提示：Docker 模式建议加--network host启用主机网络。因为 WebRTC 需要大量的 UDP 端口转发，容器网络模式下端口映射配置比较繁琐，直接用 host 模式最省事。

3.2 启动参数详解

webrtc-streamer 的启动参数不算多，但每个都很关键。下面是我的常用启动命令：

./webrtc-streamer -s 0.0.0.0:8000 -p 20000-20100

参数说明：

参数	含义	我的建议
`-s`	指定 HTTP/WebSocket 监听地址和端口	默认是 8000，局域网用`0.0.0.0`，公网部署务必用 HTTPS
`-p`	WebRTC 媒体传输的 UDP 端口范围	默认全是随机端口，手动指定便于防火墙放行
`-f`	同时允许的最大会话数	默认 16，多路摄像头按需调大
`-q`	启动时自动连接的 RTSP 地址列表	可预先配置，免去前端传 URL
`-o`	允许的跨域来源（CORS）	多前端部署时很有用

补充一个细节：-s参数指定的端口，前面是 HTTP 服务，同时也是 WebSocket 服务的入口。浏览器脚本里用的是ws://或者wss://连接到这个端口。

3.3 HTTPS 与 WebRTC 的硬性要求

这是我部署时踩过最大的坑之一。Chrome 从某个老版本开始，强制要求 WebRTC 只在安全上下文（Secure Context）中可用。所谓安全上下文，要么是localhost，要么是 HTTPS 页面。如果你是通过http://访问的页面，WebRTC 的getUserMedia和RTCPeerConnection都会被浏览器直接禁用，控制台会报错，然后视频区域一片黑。

所以公网部署时，务必在前面加一层 Nginx/Caddy 反代，把 HTTP 升级成 HTTPS。如果你只是为了局域网测试，可以临时在 Chrome 里输入chrome://flags/#unsafely-treat-insecure-origin-as-secure，把http://你的IP:8000加入白名单，这样才能跑通。

证书我用的是 Caddy 自动申请的 Let's Encrypt 证书，配置非常简单。Nginx 反代的时候需要把 WebSocket 的升级头也一并代理过去：

location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1; }

4. 前端接入：三种典型模式的实战

4.1 WebRTC 模式：真正的低延迟

webrtc-streamer 在前端暴露的 API 非常简单，核心就是一个webRtcStreamer类。下面是我在项目里实际用过的完整示例：

// 引入核心库 require('./assets/webrtcstreamer.js'); // 创建实例，参数是 WebSocket 地址 const webRtcStreamer = new webRtcStreamer('ws://' + window.location.hostname + ':8000'); // 开始播放指定 RTSP 流 webRtcStreamer.connect( 'rtsp://admin:password@192.168.1.100:554/Streaming/Channels/101', null, null, 'video' ); // 页面卸载时断开连接 window.onbeforeunload = () => { webRtcStreamer.disconnect(); };

HTML 部分也非常简单：

<div style="background:#000;width:640px;height:360px;"> <video id="video" autoplay muted playsinline></video> </div>

connect方法的第一个参数是 RTSP URL，第二个参数是音频开关，第三个是视频参数，第四个是 video 元素的 id。实际跑起来，画面延迟体感上几乎就是实时的，我家门口有人按门铃，手机屏幕上能看到对方抬头看摄像头的瞬间，这在以前用 HLS 的方案里是根本不敢想的。

4.2 MSE 模式：兼容性的兜底方案

有时候你会遇到一些环境不支持 WebRTC，或者摄像头本身的带宽不足以支撑 WebRTC 的码率要求。webrtc-streamer 也提供了一个基于 MSE（Media Source Extensions）的 HLS 模拟播放模式。前端改成调用webRtcStreamer的mseConnect方法即可：

webRtcStreamer.mseConnect( 'rtsp://admin:password@192.168.1.100:554/Streaming/Channels/101', 'video' );

这个模式走的是 WebSocket 拉流，webrtc-streamer 把媒体数据封装成 Fragment 推给浏览器，浏览器的<video>元素通过 MSE 解码播放。它的延迟会比 WebRTC 模式高一些，但胜在兼容性极好，而且服务器压力更小。我一般把它作为微信内置浏览器等 WebRTC 支持不佳场景的降级方案。

4.3 录制视频和抓帧

webrtc-streamer 还提供了一些额外的 HTTP API，可以当作简单的录像方案来用。比如请求：

# 抓取当前视频帧 curl -X POST "http://127.0.0.1:8000/api/takePicture" \ -H "Content-Type: application/json" \ -d '{"url":"rtsp://admin:password@192.168.1.100:554/Streaming/Channels/101","file":"/tmp/snapshot.jpg"}'

这个能力在安防告警时非常实用。比如探测到移动侦测事件后，后台自动抓一帧图，再推送通知用户，整个过程不到 1 秒。WebRTC 模式因为建立连接本身有一定开销，用 HTTP API 抓帧反而是最快的，实测 RTSP 源 200 毫秒左右就能返回一张 JPG。

5. 常见问题速查与排障心得

5.1 视频黑屏但 WebSocket 连接正常

这个是最常见的现象，现象是页面能连上 WebSocket，但 video 元素一直黑屏。大概率是 STUN/TURN 配置问题。WebRTC 协商时，浏览器和 webrtc-streamer 需要交换 ICE candidate。如果两边处于不同网段，或者有 NAT，就需要 STUN 服务器帮忙获取公网地址；极端情况下还要 TURN 服务器中继流量。

webrtc-streamer 的信令阶段你可以在浏览器控制台观察candidate的输出。如果发现 candidate 全部是host类型，没有srflx或relay类型，那就是 NAT 穿透没成功。解决方法是在启动时加-t stun:stun.l.google.com:19302指定 STUN 服务器：

./webrtc-streamer -s 0.0.0.0:8000 -p 20000-20100 -t stun:stun.l.google.com:19302

注意：局域网内部署一般不需要 STUN，直接在控制台看 candidate 里有没有内网 IP 即可。公网部署才需要重点关注穿透问题。

5.2 CPU 占用居高不下

如果你发现 webrtc-streamer 进程 CPU 超过 100%，先排除是不是在转码。用top -H -p <PID>看线程占用，如果v4l2或x264enc相关线程特别吃资源，那基本可以断定是 H.265 转 H.264 导致的。解决方案是去摄像头管理后台，把视频编码改成 H.264，子码流也一并改掉。

另外一个优化点是把子码流当作视频源。很多 IPC 摄像头有主码流和子码流两个通道，主码流是 4K/1080P 高清，子码流是 640x360 流畅。如果你的业务场景不需要极高清画面，直接用子码流地址，CPU 占用会直线下降。

5.3 延迟突然变大，而且不稳定

WebRTC 的延迟优势依赖的是实时传输，但网络拥塞时 webrtc-streamer 内置的拥塞控制算法会根据丢包率调整编码码率，画面会降到马赛克级别，延迟也会上升。这时候最优先检查的是 Wi-Fi 信号强度和网线链路质量。

我实测过，在一条丢包率 5% 的 Wi-Fi 链路上，WebRTC 延迟从 200 毫秒飙到 1.5 秒，而且发烫。排查的时候用ping -f连续打几百个包，看丢包率，这个比什么工具都直观。

5.4 摄像头兼容性清单

webrtc-streamer 对海康威视、大华、宇视、TP-LINK 摄像头的支持都挺不错，但有个细节要注意：老款摄像头默认开启的是“私有协议优先”，RTSP 可能没启用。请务必确认摄像头支持标准的 RTSP 协议，并且防火墙放行了 554 端口。如果 RTSP 地址测试不通过，可以用 VLC 播放器先验证一下地址是否正确，排除摄像头端的问题再找 webrtc-streamer 的原因。

6. 进阶玩法：多路并发与智能家居集成

6.1 同时播放多路摄像头

webrtc-streamer 支持一个页面里同时拉起多路流。前端创建多个webRtcStreamer实例，每个实例对应一个 video 元素即可。实测单路 1080P H.264 硬解的情况下，webrtc-streamer 的 CPU 占用大约是 10% 到 15%，一台 4 核 8G 的服务器跑 8 路并发没什么压力。

带宽方面要注意，一路 1080P H.264 的 WebRTC 码率通常在 2Mbps 到 4Mbps 之间，8 路就意味着 32Mbps 的上行带宽。如果服务器带宽不够，可以把摄像头的子码流作为播放源，码率能压到 500Kbps 以下。

6.2 接入 Home Assistant

如果你在玩 Home Assistant，webrtc-streamer 是一个非常好用的摄像头接入方案。在configuration.yaml里配置 FFmpeg 摄像头源，用 webrtc-streamer 作为流代理，就能在 HA 的 Lovelace 卡片里实时预览摄像头画面。

我的个人方案是用 Docker 启动 webrtc-streamer，然后 HA 通过rtsp_to_webrtc组件进行关联。实际体验下来延迟在 300 毫秒左右，按门铃的时候手机 App 推送，点开就能看到实时画面，再也不怕外卖小哥在门口傻等了。

6.3 和其他流媒体服务配合使用

webrtc-streamer 并不只能接 RTSP，只要 GStreamer 支持的网络流协议，它都能尝试接入。比如 RTMP、HTTP-FLV、甚至是 HLS 源，都可以当作输入。这意味着你可以把直播服务器（如 SRS、MediaMTX）上的流，再通过 webrtc-streamer 转成 WebRTC 分发。这种“RTMP 收流 + WebRTC 分发”的组合模式，在低延迟直播场景下非常有价值，能够兼顾推流端的兼容性和播放端的低延迟体验。

举个例子，我用 MediaMTX 接收无人机通过 RTMP 推上来的画面，再用 webrtc-streamer 转成 WebRTC 给地面站看，延迟比原来的 HLS 方案低了整整一个量级。

写在最后的几点经验

跑了这么久的 webrtc-streamer，我最想强调的一点是：先确定你的延迟目标，再决定要不要上 WebRTC。如果 2 到 3 秒的延迟可以接受，HLS 方案更简单、兼容性更好；但如果你的场景是通话、安防告警、体育直播，WebRTC 的体验完全不是传统方案能比的。

另外，webrtc-streamer 这个项目本身维护节奏不算特别快，遇到问题优先去看它仓库的 issue，很多坑别人早就踩过了。如果你的摄像头型号比较少见，建议先在 VLC 里把 RTSP 流跑通，再上 webrtc-streamer，能省掉一半的排查时间。

最后再分享一个小技巧：-f参数控制最大会话数，默认 16 在大多数场景够用，但如果你在页面上反复刷新、频繁重连，老会话可能没有及时释放，等到会话数打满时新连接会被直接拒绝。遇到这种情况，先等几秒再刷新，或者调大-f的值，就不会有体验上的割裂感了。

本文还有配套的精品资源，点击获取

webrtc-streamer实战：基于WebRTC的RTSP低延迟播放方案