go2rtc 完整指南：多协议摄像头流统一输出 WebRTC，一条 Docker 命令跑起来

go2rtc 完整指南：多协议摄像头流统一输出 WebRTC，一条 Docker 命令跑起来

【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtc

门口铃是 Tapo 私有协议，客厅摄像头走 RTSP，家里还有台 HomeKit 摄像头——三部手机要开三个 App 才能看全。go2rtc 把这些来源统一收进一个流媒体服务器，再以 WebRTC、RTSP、HLS 等形式分发给浏览器、Home Assistant 或 NVR。

一句话定位：零依赖的单一流媒体服务器

• 一个用 Go 写成的单文件应用，无任何运行时依赖，Windows、macOS、Linux、FreeBSD 都能跑，树莓派级别的设备也带得动。
• 适合需要把多品牌摄像头统一接进浏览器、Home Assistant、Frigate 的人。
• 与大多数协议网关的本质区别：它不是简单转发。go2rtc 会把"客户端能解的编解码器"和"源里携带的编解码器"自动匹配，只有匹配不上时才拉起 FFmpeg 转码，且只转码需要的轨道。

工作原理一句话：在配置里给每路流定义一个或多个来源，有人播放时它拉流，再从 RTSP 服务器、WebRTC 服务器、HTTP 端点等出口按需分发。

最快部署：一条 Docker 命令

官方推荐 Docker 部署，镜像预装 FFmpeg，覆盖 amd64、386、arm/v6 到 arm64 各架构：

docker run -d \ --name go2rtc \ --network host \ --privileged \ --restart unless-stopped \ -v ~/go2rtc:/config \ alexxit/go2rtc

--network host对 WebRTC 和 UDP 摄像头是必需的；--privileged只在需要 FFmpeg 硬件转码时才用。启动后打开http://localhost:1984就是 Web 管理界面。其他途径一句话带过：也可从 release 下载对应平台的二进制直接运行（Linux/macOS 记得chmod +x），Home Assistant 有官方 add-on；想改源码就git clone https://gitcode.com/GitHub_Trending/go/go2rtc后go build。

最小可运行配置：一行 streams 就够

streams: front_door: rtsp://admin:password@192.168.1.123/cam/realmonitor?channel=1&subtype=0

• streams:下面每一项就是"流名: 来源"，流名会出现在 WebUI 和所有输出 URL 里；
• 值就是视频源，这里是海康/大华风格的 RTSP 地址；
• 不写其他任何配置时，默认 api 监听1984（WebUI 和 HTTP API）、RTSP 服务器监听8554、WebRTC 使用8555（TCP/UDP）。

也就是说这一行写完，VLC 或 FFmpeg 就能拉rtsp://localhost:8554/front_door，浏览器能打开 WebUI 播放。密码不想明文写，可用环境变量替换，如${CAMERA_PASSWORD}。配置随时能在 WebUI 里直接编辑，自带语法高亮和 schema 校验：

从输入到输出：流怎么进、又怎么出

结论先行：所有流都是"来源进、协议出"，输入和输出互相独立。

数据源怎么接进来（写在 streams 的值里）：

能以什么形式输出到哪里：

• WebRTC 服务器 :8555—— 浏览器延迟最低，支持双向音频；
• RTSP 服务器 :8554—— 供 NVR、Frigate、Home Assistant 拉取；
• HTTP 端点 :1984——stream.mp4（MSE/渐进式）、stream.m3u8（HLS，iPhone 唯一选择）、stream.flv、stream.mjpg、frame.jpeg抓拍；
• ONVIF 服务器、HomeKit（接入苹果家庭）、WebTorrent、JPEG 快照；
• Ingest 反向推流—— 外部程序可把 rtmp/rtsp/webrtc/mjpeg 等流推进 go2rtc。

一个细节值得知道：WebRTC 和 MSE 会自动探测浏览器支持的编码；RTSP、HLS 做不到，需要在 URL 上加过滤参数，如rtsp://localhost:8554/front_door?video=h264&audio=aac，或加?mp4输出 H264/H265+AAC 的 MP4 兼容流（适合录像）。每条连接的 IP、协议、字节数都能在 WebUI 的实时连接图上看到：

三个最实用的配置组合

1. 摄像头音频编码和浏览器不匹配，加一路 FFmpeg 源

比如摄像头音频是 AAC，浏览器 WebRTC 只收 OPUS/PCMU/PCMA，加上转码源后 go2rtc 会为每个客户端在多路来源里自动挑兼容轨道：

streams: doorbell: - rtsp://admin:password@192.168.1.123/cam/realmonitor?channel=1&subtype=0 - ffmpeg:rtsp://admin:password@192.168.1.123/cam/realmonitor?channel=1&subtype=0#audio=opus

这种"多来源多编码协商"是它区别于转发器的核心能力。

2. NAS 上做硬件加速转码：给 ffmpeg 源追加#video=h264#hardware即可走 GPU（Intel iGPU、树莓派用标准镜像，NVIDIA/AMD 换latest-hardware镜像，Docker 需--privileged）。硬件加速默认关闭，不显式写#hardware不会生效。效果：CPU 占用明显下降，输出统一为到处可播的 H264。

3. 推流到 Telegram / YouTube：在配置里声明 publish 目标，要求流为 H264+AAC（通常先经ffmpeg:…#video=h264#audio=aac转码）：

publish: mystream: rtmps://xxx-x.rtmp.t.me/s/你的推流密钥

顺带一提，支持双向音频的摄像头还能通过 API 反向播放本地音频文件或电台流，详见 internal/streams/README.md。

实用要点：调优、安全与弱设备

1. 延迟：RTSP 播放卡顿大半是播放器缓冲造成的，用ffplay -fflags nobuffer -flags low_delay "rtsp://localhost:8554/front_door"验证服务器端延迟（适用于支持该参数的客户端）。
2. 安全：默认 1984、8554 端口对局域网无鉴权开放，内网有不可信设备时，把api和rtsp的listen改成127.0.0.1:端口，WebUI 交给 Nginx 等反向代理加认证；WebRTC 的 8555 保持外可达但媒体是加密的。
3. 硬件加速只在视频转码时才有意义：只转发（无 ffmpeg 源，或#video=copy）时开启反而徒增风险，按需加#hardware。
4. 弱设备（树莓派、低端 NAS）：预览和 AI 检测源用子码流（subtype=1），录像用主码流；同时处理的流数量保持克制。
5. 排障：log:下可按模块设级别，如rtsp: trace，单独追踪一个模块而不刷屏。

出问题时的速查表

适合谁，以及第一步

家里有多品牌摄像头、又不想为每装一台就多开一个 App 的人，它都值得装一个。建议按顺序做三件事：

1. 用上面的 Docker 命令部署，把一台 RTSP 摄像头写进go2rtc.yaml；
2. 打开http://localhost:1984，确认 WebRTC 播放正常；
3. 遇到播不出来的摄像头，先查 WebUI 信息页的编码列表，再对照速查表处理。

【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtc