go2rtc + Docker 统一管理多品牌摄像头，低延迟取流与播放实践

1. 项目概述一套服务统一所有摄像头的取流家里摄像头牌子一多最头疼的就是每个都要单独开App、单独看画面。我手头的情况是这样客厅一台海康威视、门口一台大华、窗台上还有一块树莓派OV5647摄像头模块。海康要用自己的客户端大华要装另一套软件树莓派那块小板子还得自己写程序推流三套平台三套逻辑折腾起来别提多别扭。后来我改用 Docker 部署 go2rtc才把这堆摄像头的多协议取流问题一次性捋顺了。go2rtc 不是传统意义上的全家桶NVR它更像一个流媒体的“协议翻译官”加“路由中心”。它既能主动拉取RTSP、RTMP、HTTP、V4L2这些来源的视频流也能对外输出WebRTC、HLS、MSE、RTSP等不同格式的流。摄像头原来是什么协议不用改go2rtc在中间负责转换和分发。用比较直白的话说把各种说不同“语言”的摄像头都接到一个中转站然后你用哪个播放器它就给你翻译成对应的“语言”送过来。关键是它整体非常轻量配置干净官方也推荐配合 Docker 运行一条命令就能起服务不用在宿主机里装一堆运行时依赖。这篇文章适合谁看如果你跟我一样手里有几个不同品牌的IP摄像头想在本地搭一套统一播放、统一管理的流媒体平台或者你刚接触 Docker想找一个小巧实用的项目练手甚至你正在折腾 Home Assistant 的摄像头接入——go2rtc 都能帮你省掉很多跨协议对接的繁琐工作。下面我就从方案选型、部署配置、摄像头接入、问题排查这几个层面把实际操作过程完整记录下来。1.1 为什么我不选 FFmpeg 硬堆方案在决定用 go2rtc 之前我其实试过直接用 FFmpeg 把每路 RTSP 流转成 HLS 或 RTMP 推到本地 Nginx 上。这条路能不能走通能走通但只要摄像头数量超过两路维护成本就上来了。你需要自己写一堆脚本去管理每个进程的生命周期还要处理推流中断后的重启逻辑相当于是重复造轮子。而且 FFmpeg 转码很吃CPU哪怕是 1080P 的流纯软转码一路就能吃掉一整个核心的不少算力。go2rtc 的定位恰好不同它默认情况下走的是“透传优先”路线尽量不做解码重编码直接把原始流按需转发和协议转换。只有在目标端不兼容源端编码格式的时候它才会按需调用 FFmpeg 做局部转码。这样 CPU 占用率通常能控制在很低的水平多路同时查看也不容易把机器跑满。这一点在多路监控场景下非常重要。1.2 Docker 部署带来的实际好处go2rtc 官方提供了多平台镜像我选择的镜像是alexxit/go2rtc或者你也可以用 ghcr 源里的镜像。选用 Docker 部署有几个很实际的好处宿主机不用装 Go 运行时和 FFmpeg 环境容器镜像里自带了可执行文件和必要的二进制依赖。升级、回滚都简单拉一个新镜像换掉旧容器就行不影响宿主机上其他服务。配置目录可以挂在宿主机上改完配置重启容器就能生效方便版本管理。网络模式可以直接用 host 模式或者映射端口对设备发现和 WebRTC 协商很友好。我自己在跑 go2rtc 的是一台闲置的小主机系统是 Ubuntu 22.04Docker 是标准安装的 CE 版本。如果你在 Windows 上用 Docker Desktop也一样能跑只是要注意摄像头设备映射和网络模式的部分后面会专门讲到。2. 工具选型与部署环境搭建go2rtc 这个名字拆开看“go”指的是用 Go 语言编写“rtc”指的是 WebRTC 技术栈。WebRTC 的低延迟能力是它的一大特色浏览器原生支持不需要装插件首帧延迟能做到几百毫秒级别。这和传统 HLS 那种几秒甚至十几秒的延迟相比体验差异非常明显。2.1 官方镜像和 Docker Compose 配置我建议直接用 Docker Compose 来管理 go2rtc 服务这样配置、重启、日志查看都比较顺手。先新建一个目录比如go2rtc在里面放一个docker-compose.ymlservices: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc restart: unless-stopped network_mode: host volumes: - ./config:/config - /etc/localtime:/etc/localtime:ro第一次启动时go2rtc 会默认在config目录下生成一个go2rtc.yaml配置文件。network_mode: host是我更推荐的方式因为 go2rtc 默认 WebRTC 需要在一段 UDP 端口上进行协商传输host 网络模式下端口分配和 NAT 穿透都更省心。如果你因为某些原因必须用 bridge 网络模式那至少要把 Web 界面端口 1984 映射出来同时还要给 WebRTC 单独映射 TCP/UDP 8555 端口并去配置文件里指定rtsp的端口范围。这样搞虽然也能跑但多了一层端口映射的排查成本。2.2 Windows 和 macOS 上的部署注意点Windows 用户如果使用 Docker Desktop建议先确认虚拟化功能已经开启。我遇到过一个典型问题Docker Desktop 启动时提示 “virtualization support not detected”很多时候是 BIOS 里的 VT-x 或 AMD-V 没开启或者是“虚拟机平台”功能没有在 Windows 功能列表里勾选。把 Hyper-V 或“适用于 Linux 的 Windows 子系统”相关组件打开重启后再启动 Docker Desktop 一般就能解决。跑起来之后记得在 Docker Desktop 的 Settings 里给 go2rtc 分配足够的内存不然多路流拉起来时容器容易 OOM。macOS 上用 Docker Desktop 基本没太多坑唯一要注意的是控制台端口占用。因为 macOS 上 AirPlay 等系统服务会占用部分端口如果 1984 被占用可以通过改成其他端口映射来解决。当然 host 网络模式在 macOS 和 Windows 上的行为和在 Linux 上不太一样所以这两个平台我建议老老实实做端口映射不要太追求 host 模式。2.3 初始化配置文件的目录结构启动后你会看到类似这样的目录结构go2rtc/ ├── docker-compose.yml └── config/ ├── go2rtc.yaml └── record/go2rtc.yaml是整个服务的核心配置。record目录是录制文件存储用的暂时不需要可以忽略。初次启动后配置文件内容很简短基本只有版本注释和空的 streams 字段。我们后面所有摄像头接入都在这个文件里完成。3. 摄像头接入实战与配置详解3.1 go2rtc.yaml 的配置结构go2rtc 的配置文件采用 YAML 格式最核心的段落是streams。每一路流有一个自定义名称名称下面是一个列表里面可以写多个来源地址。比如streams: living_room: - rtsp://admin:yourpassword192.168.1.64:554/Streaming/Channels/101 front_door: - rtsp://admin:yourpassword192.168.1.65:554/cam/realmonitor?channel1subtype0 pi_camera: - v4l2:///dev/video0每一路流配置好之后在浏览器里打开http://你的主机IP:1984就能看到对应名称的流点进去就能播放。go2rtc 的 Web 管理界面本身就是一个可用的播放器这点非常方便省得我们调试时再另起一个播放软件。3.2 海康、大华、宇视等常见摄像头取流地址不同品牌摄像头的 RTSP 取流地址格式差别不小我第一次接海康的时候也查了好半天。这里把常见的地址格式整理一下方便大家对照自己的摄像头来配置品牌RTSP 取流地址模板海康威视rtsp://用户名:密码IP:554/Streaming/Channels/101大华rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0宇视rtsp://用户名:密码IP:554/unicast/c1/s0/liveTP-Link 等rtsp://用户名:密码IP:554/stream1注意海康地址结尾的“101”代表通道1的主码流“102”代表通道1的子码流。主码流清晰度高、码率大适合回放和录像子码流分辨率低、码率小适合网络状态一般时的实时预览。如果多路同时查看卡顿我一般建议把其中几路改成子码流保流畅优先。大华地址里的channel1subtype0也是同样的逻辑subtype0是主码流subtype1是子码流。初次配置时先花两分钟确认一下登录账号是否有 RTSP 取流权限很多摄像头默认的 ONVIF 账号和 RTSP 账号不是同一个权限不足会导致连接被拒。3.3 树莓派 OV5647 摄像头模块的 V4L2 接入除了网络摄像头go2rtc 也支持直接采集本机的 V4L2 摄像头设备。我自己有一块树莓派的 OV5647 摄像头模块也就是常见的树莓派 Camera Module 接口摄像头。接在 Linux 小主机上时先用ls /dev/video*确认设备节点然后配置成streams: pi_ov5647: - v4l2:///dev/video0如果你在容器里跑 go2rtc需要把宿主机的摄像头设备映射进容器。在 docker-compose.yml 里加上services: go2rtc: ... devices: - /dev/video0:/dev/video0V4L2 来源的视频在 Web 端播放时如果浏览器不支持原始编码格式go2rtc 会自动调用内置的 FFmpeg 做转码。所以OV5647 的 H.264 输出如果遇到兼容问题配置里可以用?videoh264这样的参数去指定编码方式例如streams: pi_ov5647: - v4l2:///dev/video0?videoh264这里要说清楚go2rtc 的 FFmpeg 转码是按需启动的。只有当某个播放端要求特定编码或者源格式无法被目标端解析时它才会拉起 FFmpeg 进程。所以平时 CPU 占用很低只有实际有人观看时才会发生变化。3.4 多来源故障自动切换配置go2rtc 还有一个非常实用的特性一个流名称下可以配置多个来源它们按顺序排列当第一个来源不可用时会自动尝试下一个。比如一个大华摄像头可以同时配置 RTSP 地址和 RTMP 地址主备切换streams: front_door: - rtsp://admin:password192.168.1.101:554/cam/realmonitor?channel1subtype0 - rtsp://192.168.1.201:8554/live第二行相当于指向了另一个 RTSP 服务源。这个特性在摄像头跨网段场景下很好用。比如主摄像头在 A 网段无法直接访问你可以放一个小设备在同网段做转发go2rtc 这边配两个来源一旦直连不通就自动切到转发源。3.5 比如我在配置中的一个小技巧接入多路摄像头时我习惯在 sources 里给每个源加上#namexxx注释这样在 go2rtc Web 界面的“源信息”里能一眼看出当前生效的是哪一路。配置长这样streams: front_door: - rtsp://admin:password192.168.1.101:554/cam/realmonitor?channel1subtype0 # 主路 - rtsp://192.168.1.201:8554/live # 备用中转别小看这个注释习惯摄像头多了以后排查“为什么这路画面糊了”往往就是主备两个源之间的问题。有注释标记能节省很多时间。4. 播放端配置与 WebRTC 低延迟调优go2rtc 最具吸引力的部分就是 WebRTC 低延迟播放。日常用浏览器直接看 RTSP 流是很麻烦的因为浏览器不认识 RTSP 协议。HLS 方案虽然浏览器能播但延迟通常在 3~10 秒家里看个门口画面还能忍受要是想用来对准摄像头调角度延迟一大就觉得难受。WebRTC 能把端到端延迟压到几百毫秒打开页面几乎就是实时画面。4.1 浏览器播放与 MSE 方案go2rtc 的管理界面默认就能直接预览所有流它自动根据浏览器能力选择播放协议。在 Chrome、Edge 这类浏览器上WebRTC 优先其次是 MSE最后才退回 HLS。所以在 Web 界面上点开一路 RTSP 摄像头默认体验就是接近实时的。如果你想在自建 Web 页面里嵌入摄像头画面go2rtc 提供了简单的 iframe 嵌入方式。可以直接用iframe srchttp://你的主机IP:1984/stream.html?srcfront_doormodemse .../iframe也可以调用它暴露的 API 来做更复杂的集成。go2rtc 有一个/api/stream接口支持用 query 参数指定来源和播放协议对前端开发比较友好。4.2 网络拓扑对 WebRTC 延迟的影响WebRTC 低延迟有一个前提客户端和 go2rtc 之间的网络要能正常走通 UDP 传输。如果跨公网访问家里没有做端口映射或 NAT 穿透WebRTC 可能自动退化为 TCP 中继延迟优势就会打折。对于本地局域网使用这个影响基本不存在体验非常流畅。我实际测试中局域网内 Chrome 打开 WebRTC 预览从点击到画面出现大约 500ms 左右操作摄像头云台时的跟手程度和直接看摄像头自带客户端差不太多。如果你发现 WebRTC 迟迟连不上先检查防火墙是否放行了 UDP 8555 端口。用 bridge 网络部署的尤其要注意控制台是 1984 端口WebRTC 数据走的是另外一段端口两套端口都需要映射。4.3 音频问题的处理摄像头音频是另一个容易踩的坑。很多 IP 摄像头音频编码是 G.711PCMU/PCMA浏览器 WebRTC 原生支持 G.711所以播放没问题。但如果你把流转到其他平台或自建播放器有些端不支持 G.711 就听不到声音。go2rtc 的处理办法是在流配置上增加音频转码参数例如streams: living_room: - rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 - ffmpeg:living_room#audioaac这段配置的意思是在原始 RTSP 源不可直接播放音频时尝试用 FFmpeg 把音频转成 AAC。需要注意这种写法会启动一个转码进程CPU 会有些许上升但通常可以接受。4.4 用 OBS 抓流做虚拟摄像头我发现很多朋友关心“怎么把 go2rtc 的画面送进 OBS”。其实很简单OBS 里添加“媒体源”或“浏览器源”填 go2rtc 的播放地址就行。在 OBS 的媒体源里直接填浏览器源http://你的主机IP:1984/stream.html?srcfront_doormodemseVLC/媒体源go2rtc 对外提供的 RTSP 地址rtsp://你的主机IP:8554/front_door这个 RTSP 输出端口 8554 默认就是开着的任何支持 RTSP 的播放器都能连上来。我之前做直播推流的时候就把 go2rtc 接进来的大华摄像头画面转给 OBS然后 OBS 再推到直播平台整个过程链路短、延迟低。5. 长期运行的问题排查与性能优化5.1 Docker 容器时间、日志和 CPU 占用的日常检查go2rtc 跑起来之后日常维护其实很少。我一般隔一段时间看看容器状态和日志docker logs go2rtc --tail 100 docker stats go2rtc日志里如果出现大量error或timeout就要检查对应摄像头是否因为密码错误、网络波动、固件不稳定等原因频繁断连。这里有个小经验很多摄像头在 Wi-Fi 环境下 RTSP 连接不稳定经常出现 30 秒到几分钟就断一次的情况。海康和大华的摄像头都支持有线接入能用网线就尽量别用 Wi-Fi稳定性提升非常明显。5.2 多路连接导致掉线怎么办一次接入太多路流时某些摄像头会出现“最多 N 路连接”的限制。比如我之前接的一台海康默认只允许同时 4 个 RTSP 会话如果 go2rtc 里有多个来源引用同一台摄像头比如主码流加子码流同时拉取再加上手机 App 也在看很容易超限。遇到这个情况要么在摄像头后台把“最大连接数”调大部分型号支持要么在 go2rtc 的源配置里减少不必要的路数。另外要留意 RTSP 连接超时问题。如果 go2rtc 长时间不播放某路流它默认会保持连接或者按配置自动断开这正常。但如果你在配置里用了?timeout0这类参数表示不超时反而不建议对太多路源使用因为摄像头端资源有限长期挂着不释放连接可能影响其他人访问。5.3 树莓派兼任 go2rtc 服务端的体验如果你的环境是一台树莓派跑 go2rtc 完全够用。树莓派 4B 上同时接入 2~3 路 1080P 主码流做转发和 WebRTC 预览CPU 占用百分之二三十左右。但如果需要多路 FFmpeg 转码CPU 会迅速拉高。所以我的原则是能透传就透传避免不必要的转码。OV5647 这种本地摄像头接入也不例外尽量让源端输出 H.264而不是用 MJPEG 格式因为 MJPEG 转 H.264 的代价相当高。5.4 录制功能与存储增长go2rtc 也自带录制功能。在配置里给某路流加上record相关参数后它会把流写入磁盘streams: front_door: - rtsp://admin:password192.168.1.101:554/cam/realmonitor?channel1subtype0 - record:record/front_door/录制文件的体积取决于码率。1080P 主码流如果是 4Mbps一小时大约 1.8GB 左右这个增长速度还是很可观的。我之前没有做周期清理结果跑了一个多月发现磁盘快满了。后来在宿主机上配了个简单的 cron定期清理超过 7 天的录制文件就再没担心过存储问题。如果你希望长期保存录像建议还是把录制源设置为子码流码率低很多画面监控基本够用。5.5 常见问题速查表我整理了实际使用中最常遇见的几类问题和对应处理办法方便你对照排查现象可能原因处理方法画面一直加载不出来RTSP 地址格式错误或账号无权限先用 VLC 本地验证取流地址确认可用再填入配置WebRTC 连不上画面卡在连接中UDP 8555 端口未放行检查防火墙和安全组确认 UDP 端口可通播放有画面但没声音音频编码格式不兼容播放端在流配置里加 FFmpeg 音频转 AAC 参数多路同时播放时卡顿同一摄像头连接数超限或网络带宽不足改子码流检查摄像头最大连接数限制容器反复重启配置格式错误或磁盘权限问题查看日志确认错误信息修正 YAML 缩进画面延迟越来越大播放端走了 HLS 而非 WebRTC确认浏览器是否支持 WebRTC检查网络模式6. 扩展玩法与实际使用心得6.1 接入 Home Assistant秒变监控面板go2rtc 和 Home Assistant 的整合非常成熟。最新版 Home Assistant 本身就把 go2rtc 作为可选的流引擎之一。你在 Home Assistant 的 Lovelace 面板里用stream卡片可以直接填 go2rtc 生成的流地址实现低延迟的监控墙。如果一个摄像头已经被 go2rtc 管理起来了在 Home Assistant 里再配一个camera实体指向它就行的不需要重复拉流这比每个摄像头单独配置 ONVIF 或 RTSP 接入要省事得多。我在自己家里就把客厅、门口、院子三路摄像头全部接进了 Home Assistant 的面板平板上点开就能看到实时画面。因为走的是 WebRTC 或 MSE延迟低到可以当反向对讲使用——这在以前用 HLS 方案时很难做到。6.2 与 Frigate 类 NVR 配合使用如果你跑过 Frigate 这类 NVR 软件会发现 go2rtc 完全可以作为它的取流前置层。Frigate 专注于运动检测和事件记录go2rtc 更适合做实时流分发。把 go2rtc 放在 Frigate 前面统一管理摄像头再用 Frigate 只订阅需要的流结构上更清晰也方便多摄像头场景的管理。这种架构还有一个好处go2rtc 帮你把不同协议的摄像头统一成标准 RTSP 或 WebRTC 流后Frigate 就不需要关心摄像头具体的品牌和取流细节了接入新摄像头时只要在 go2rtc 里加一行配置就行。6.3 我用下来觉得最值得注意的三件事第一网络安全别忽视。go2rtc 默认没有认证机制Web 界面和管理接口是裸奔的只能在内网使用。如果一定要在公网访问必须在前面套带认证的反代或者其他访问控制方案不要把 1984 端口直接暴露到公网。第二docker-compose.yml 里的restart: unless-stopped一定要加。摄像头、智能家居这类 7x24 小时服务断电重启后自动恢复太重要了。我家里偶尔跳闸不加重启策略就得手动拉服务加了之后省心许多。第三配置文件的缩进要严格遵守。YAML 对缩进非常敏感一个空格不对整个 streams 段就解析失败。我第一次修改时不小心把某个源多缩进了两个空格结果页面里一直看不到那路流排查半天才发现是格式问题。改完配置记得先docker compose config验证一下语法再重启容器。6.4 还能往哪继续扩展go2rtc 的能力不止于摄像头。它支持 HTTP 串流、RTMP 拉流源也能往 WebRTC 推流给自定义前端。我曾经把一台旧手机当作外置摄像头通过 RTMP 推给 go2rtc然后统一接入监控面板效果也还不错。思路打开之后go2rtc 就是一个所有视频源的统一接入层。录制文件的管理、与 NVR 的深度整合、多台设备之间的流级联这些都是可以考虑的扩展方向。go2rtc 本身更新活跃文档也写得很清晰遇到问题多翻翻官方 README 和常见讨论大部分坑都能避过去。说到底摄像头系统的痛点从来不在单个摄像头而在多个设备、多种协议之间的统一管理。go2rtc 配合 Docker 提供了一个轻量、干净、低延迟的解决方案。我在实际使用中最深的体会是工具小不是问题关键是思路要清晰——把“取流”和“播放”分开中间用 go2rtc 做桥接整套系统就会好维护很多。如果你也被多品牌摄像头各搞各的 App 折磨过不妨照着上面的配置试一次大概率能省掉后面不少折腾。