前一阵把家里和工作室的几路摄像头全部迁到了自建的流媒体平台陆陆续续折腾了大概一周最后沉淀下来的核心组件就是 go2rtc。这个东西在智能家居圈子里其实挺出名但很多人只知道它能配 Home Assistant不知道它本身就是一个非常能打的摄像头多协议流媒体服务器。这篇文章就把我从 Docker 部署、摄像头接入、WebRTC 低延迟播放到跟 Frigate、Home Assistant 联动这一整套过程完整写出来包括踩过的坑和排查思路希望能给正在折腾摄像头的朋友省点时间。go2rtc 最打动我的点是它把摄像头接入和多协议输出这两件事做得极其干净。你不需要理解 RTSP 的底层细节也不用操心 HLS 分片、WebRTC 信令这些复杂概念装好之后打开浏览器就能看。配合 Docker 部署从零到跑通基本十分钟以内。1. 为什么是 go2rtc多协议汇聚的选型思考1.1 流媒体平台的核心矛盾协议不通、延迟太高先说我遇到的真实场景。家里有两个海康摄像头一个杂牌 RTSP 摄像头车库里还放了一台树莓派接的是 OV5647 摄像头模块。问题来了海康用海康自己的 App 看杂牌摄像头要看它的云平台树莓派要自己写代码拉流。手机上要装四五个 App家里人根本没法用。很多人第一反应是把所有摄像头接到一个 NVR 里。但 NVR 解决的是录像存储问题不是播放体验问题。我要的是打开一个页面所有摄像头都在这点一下就能看最好延迟还低。这时候就需要一个能做协议汇聚的中间层。另一个痛点就是延迟。RTSP 协议本身很优秀但浏览器原生不支持 RTSP。传统的解决方式是转成 HLS 或 RTMP 再播放HLS 延迟通常在 3 到 10 秒RTMP 也需要 Flash 或者额外插件。对于看摄像头这种场景3 秒延迟其实勉强能忍但如果你在门口装个摄像头有人按门铃你都看不到人这就很尴尬了。1.2 go2rtc 的核心设计一个二进制解决协议转换go2rtc 是一个用 Go 语言写的流媒体服务器作者是 Home Assistant 社区的知名开发者 AlexxIT。它最核心的能力是把 RTSP、RTMP、HLS、WebRTC、MJPEG 这些协议全部打通。我理解的 go2rtc 工作方式是这样的摄像头提供 RTSP 流go2rtc 作为一个中转层接入这个流然后对外统一输出多种协议。你在浏览器里看它走 WebRTC你用 VLC 看它走 RTSP 或者 HLS你在手机 App 里看可以走 HLS 或者 RTSP。它最牛逼的地方在 WebRTC 的支持。大家知道WebRTC 是浏览器原生支持的低延迟音视频通信协议端到端延迟能做到 500 毫秒以内。但 WebRTC 和 RTSP 完全是两个世界的协议普通开发者根本不可能自己写一个 RTSP 转 WebRTC 的网关。go2rtc 把这个能力内置了你只需要给摄像头配一个 RTSP 地址浏览器就能以接近实时的延迟看到画面。这背后的原理其实不复杂go2rtc 从摄像头拉取 RTSP 流提取 RTP 包然后重新封装成 WebRTC 可以处理的格式再通过 WebRTC 的 DTLS-SRTP 加密通道发给浏览器。因为中间没有转码步骤所以延迟非常低。当然go2rtc 也支持通过 FFmpeg 做转码但一般用不上。1.3 横向对比为什么不是 Nginx-RTMP 或 mediamtx这里要聊一下选型对比因为很多人会问我直接用 Nginx-RTMP 行不行mediamtx 不是也能做 RTSP 转 HLS 吗。我自己实际上都试过。Nginx-RTMP 模块的问题是它主要是为 RTMP 直播设计的对 RTSP 的支持很弱你需要先把摄像头的 RTSP 流推成 RTMP再分发成 HLS链路长且配置繁琐。mediamtx前身是 RTSP-Simple-Server是个不错的轻量级方案支持 RTSP 输入输出和 HLS 输出但它对 WebRTC 的支持相对弱而且没有 go2rtc 那种一体化的配置体验。我用一个表格总结这几个方案的差异方案RTSP 输入WebRTC 输出HLS 输出配置复杂度摄像头自动发现Nginx-RTMP弱不支持需要额外模块高无mediamtx支持弱支持中等无go2rtc支持原生支持支持低支持 ONVIF所以我的结论是如果你想搭建一个纯粹的、以摄像头为核心的流媒体平台go2rtc 是目前综合成本最低的方案。它不是万能的但它在摄像头接入这个领域做得足够专精。2. 部署前的网络与 Docker 环境规划2.1 端口清单与网络模式选择go2rtc 默认使用的端口有这几个1984Web 管理界面和 API 接口TCP8554RTSP 服务端口TCP8555WebRTC 媒体传输端口TCP UDPDocker 部署时有两种网络模式可以选。第一种是 bridge 模式这也是大家最熟悉的模式通过-p参数把容器端口映射到宿主机。这种模式下容器是一个独立的网络栈所有端口都需要显式映射。第二种是 host 网络模式容器直接使用宿主机的网络栈不做端口隔离。go2rtc 官方文档实际上更推荐 host 模式原因有两点WebRTC 传输涉及多个 UDP 端口的动态协商bridge 模式下端口映射容易漏摄像头自动发现功能依赖网络广播和多播host 模式才能确保这些包正常收发我个人的建议是如果你在 Linux 服务器上部署直接用 host 模式省心。如果你在 Windows/macOS 上用 Docker Desktophost 模式的支持不完美那就老老实实用 bridge 模式并映射所有端口。2.2 Windows/Linux 下 Docker 环境最容易踩的坑先说 Windows。很多人在装 Docker Desktop 的时候会卡在启动阶段报错信息是 virtualization support not detected大意是检测不到虚拟化支持。这个问题的根源通常是 BIOS 里的虚拟化开关没开Intel 的 CPU 要开 VT-xAMD 的 CPU 要开 SVM。我遇到过不止一次新手在 Windows 上装 Docker Desktop装完发现起不来然后各种折腾最后发现只是 BIOS 里一个开关的事。步骤很简单重启进 BIOS → 找到 Intel Virtualization Technology 或者 SVM Mode → 设置为 Enabled → 保存退出。另外 Windows 的 Hyper-V 和 Windows Hypervisor Platform 这两个功能也要在启用或关闭 Windows 功能里打开。还有一个比较容易忽略的点go2rtc 是 Linux 容器不要用 Windows 容器模式跑。Docker Desktop 安装的时候默认是 Linux 容器但如果你之前切换过记得切回来。Linux 服务器上主要注意 Docker 版本尽量装比较新的版本。老版本 Docker 对 Compose V2 的支持不完善而后面的 docker compose 命令注意中间没有空格依赖 Compose V2。2.3 目录规划与 config.yaml 初始结构go2rtc 的配置存在/config目录下的 go2rtc.yaml 文件里。第一次启动时go2rtc 会自动生成一个默认的配置文件你也可以提前手动创建好再启动。我习惯这样的目录结构/path/to/go2rtc/ ├── config/ │ └── go2rtc.yaml └── recordings/ # 如果后续接录制功能可以用这个目录初始的 go2rtc.yaml 实际上可以非常简洁。这是我最开始用的配置log: level: info api: listen: :1984 webrtc: listen: :8555 ice_servers: - urls: [stun:stun.l.google.com:19302] rtsp: listen: :8554 streams: cam_test: rtsp://192.168.1.100:554/live这段配置里api、webrtc、rtsp分别定义了三个服务的监听地址streams是摄像头流的核心配置。cam_test是我给摄像头起的名字后面的 RTSP 地址是它的源。ice_servers这个配置很多人搞不明白。WebRTC 在建立连接的时候需要知道自己的公网 IP 和端口这个过程叫 ICE 协商。STUN 服务器的作用是帮浏览器和 go2rtc 发现彼此的可达地址。如果是纯局域网使用不配置 STUN 也能跑通因为双方都在同一个网段互相广播就能找到对方。但如果要从外网访问就必须配置 STUN 服务器否则 WebRTC 连接大概率失败。3. Docker 部署 go2rtc 的完整过程3.1 用 docker run 快速验证如果你只想先看看 go2rtc 长什么样一条 docker run 命令就够了。我用 host 模式演示docker run -d \ --name go2rtc \ --network host \ --restart unless-stopped \ -v /path/to/go2rtc/config:/config \ alexxit/go2rtc:latest注意几个参数-d表示后台运行--network host使用宿主机网络容器内的 1984、8554、8555 端口直接暴露-v把本机的配置目录挂载到容器的/config这样以后改配置不需要进入容器--restart unless-stopped让 Docker 在宿主机重启后自动拉起容器如果你是 bridge 模式对应命令是这样的docker run -d \ --name go2rtc \ -p 1984:1984 \ -p 8554:8554 \ -p 8555:8555/tcp \ -p 8555:8555/udp \ -v /path/to/go2rtc/config:/config \ alexxit/go2rtc:latest启动之后浏览器打开http://服务器IP:1984你就能看到 go2rtc 的 Web 管理界面。这个界面自带一个播放器还有一个摄像头添加入口。3.2 用 docker compose 落地生产配置docker run 适合验证但真正长期使用的项目我会用 docker compose 管理。好处是配置可以版本控制而且可以一次性定义所有服务。这是我的 docker-compose.ymlservices: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc network_mode: host restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/config注意我用了network_mode: host原因前面已经解释过。如果用 bridge 模式需要把端口映射也写进去。启动命令docker compose up -d停止并删除docker compose down查看日志docker logs -f go2rtc把这些命令记熟日常维护基本够用了。3.3 验证服务状态服务起来之后我会做三件事来确认一切正常。第一打开 Web UI。如果页面能正常加载说明 API 服务在跑。第二检查日志。执行docker logs go2rtc看有没有报错。正常情况下日志里会出现这样几行INFO go2rtc/rtsp: rtsp://:8554 INFO go2rtc/api: api://:1984 INFO go2rtc/webrtc: webrtc://:8555第三用 curl 访问 API 接口确认流列表是否有数据curl http://127.0.0.1:1984/api/streams这个接口返回的是 JSON 格式的流列表。如果没有配任何流会返回空数组这很正常。配置好摄像头之后再来看这里就能看到摄像头的信息。4. 摄像头接入实战手动地址与自动发现4.1 RTSP 地址的构成逻辑接入摄像头之前你必须先搞明白 RTSP 地址长什么样。RTSP 地址其实就是摄像头向外提供视频流的网络位置格式一般是这样rtsp://用户名:密码摄像头IP:554/路径你可能会说这不就是个 URL 吗确实但这里有几个隐藏的坑。第一个坑是密码里的特殊字符。如果摄像头密码里有、:、/这些字符直接拼在 URL 里会导致解析错误。比如密码是abc123那这个地址就废了。解决办法是把密码做 URL 编码编码成%40。所以abc123要写成abc%40123。第二个坑是主码流和子码流的问题。现在几乎所有的 IP 摄像头都有两路流主码流分辨率高、码率高子码流分辨率低、码率低。直播观看一般用子码流就够了因为省带宽、解码快需要录像或者看细节的时候才切主码流。go2rtc 支持把主码流和子码流配成两个不同的流名。第三个坑是 H.265 编码。很多新出的摄像头默认用 H.265 编码这种编码在摄像头本地 MJPEG 预览是没问题的但浏览器播放 H.265 的能力参差不齐。如果你发现浏览器里黑屏大概率是编码格式的问题这个我后面会详细讲。4.2 常见厂商摄像头 URL 模板不同厂商、不同型号的摄像头RTSP 路径差别很大。我整理了自己实测过的一些模板给大家参考品牌主码流 RTSP 地址海康威视rtsp://user:passip:554/Streaming/Channels/101大华rtsp://user:passip:554/cam/realmonitor?channel1subtype0TP-LINKrtsp://user:passip:554/stream1杂牌/工控机不固定一般在设备文档里找海康的地址里101表示通道 1 主码流102表示通道 1 子码流。大华的地址里subtype0是主码流subtype1是子码流。很多杂牌摄像头不着调RTSP 路径五花八门。遇到这种情况我的经验是先在电脑上用 VLC 打开rtsp://ip:554/看返回什么。VLC 有时候能自动探测到路径。如果探测不到就去摄像头 App 的后台界面找技术参数页那里通常会写 RTSP 地址。4.3 用 ONVIF 自动发现降低接入成本如果你有不少摄像头要接手动一个个填 RTSP 地址也挺累的。go2rtc 的 Web UI 里有一个添加摄像头的入口它支持通过 ONVIF 协议自动发现局域网里的摄像头。ONVIF 是一个安防设备的标准化协议说白了就是摄像头之间、摄像头和软件之间的通用握手语言。go2rtc 通过 ONVIF 可以做到发现设备、读取设备能力、根据账号密码自动列出可用的视频流。用 ONVIF 添加摄像头的步骤大概是这样在 go2rtc Web UI 的添加页面里选择摄像头类型输入摄像头的 IP 地址以及摄像头的管理员账号密码go2rtc 发起 ONVIF 探测自动识别 RTSP 地址并填入配置确认保存流就被加进来了这个功能对海康、大华这些主流品牌支持的还不错。不过要提醒一点ONVIF 需要摄像头开启对应功能。海康的摄像机有些批次默认不开 ONVIF需要在摄像头网页后台的网络 → 高级设置 → 集成协议里把 ONVIF 打开并设置独立的 ONVIF 用户。这个用户和摄像头管理员账号不一定是同一个别搞混了。4.4 接入失败的常见原因定位摄像头接入不成功90% 是这几个原因按可能性从高到低排账号密码错误或者权限不足RTSP 地址错误尤其是路径写错摄像头和 go2rtc 不在同一个网段防火墙挡了 554 端口摄像头编码格式特殊go2rtc 无法解析摄像头 IP 摄像头有连接数限制已经被别的 App 占满了排查的时候我的建议是先绕过 go2rtc直接用 VLC 拉流测试。VLC 能打开说明源没问题问题在 go2rtc 配置。VLC 打不开先查网络和凭证。还有一个值得注意的点有些厂商的摄像头在开启 H.265 的同时还会开启动态码率或者智能编码之类的功能。这些功能会导致码率波动很大影响播放稳定性。接入 go2rtc 的时候如果画面频繁卡顿可以考虑在摄像头后台把这些功能关掉。5. 多协议输出与低延迟调优5.1 一个源同时输出多个协议go2rtc 的魅力在配置好一个源之后能自动输出多种协议。我这里用一个完整的配置示例来讲。假设我配置文件里有这样的内容streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102那么driveway这一个流就会自动拥有以下这些访问地址WebRTC 播放打开 Web UI 找到driveway点播放走的就是 WebRTCRTSP 取流rtsp://127.0.0.1:8554/driveway供 VLC、Frigate、NVR 使用HLS 播放http://127.0.0.1:1984/api/stream.m3u8?srcdriveway供手机浏览器、网页播放器使用MJPEG 输出http://127.0.0.1:1984/api/frame.jpg?srcdriveway可以做成简单的定时抓图这种一个源多协议输出的设计让 go2rtc 变成了一个非常灵活的中间层。我不用为每个场景单独搭一条流。5.2 局域网 WebRTC 观看的延迟表现我实测过局域网环境下 WebRTC 的延迟。当时我用手机秒表对着摄像头画面同时盯着屏幕上的直播画面两者做差。结果是从画面真实发生到屏幕上显示延迟大概在 300 到 500 毫秒之间。相比 HLS 动辄 3 到 5 秒的延迟这个体验完全是两个级别。这个低延迟主要来自 WebRTC 的 UDP 传输机制。它不像 HLS 那样需要把视频先切成一个个小块再让播放器下载播放而是直接用 UDP 包实时推送。UDP 的缺点是丢包不重传但在局域网这种高可靠网络环境下丢包率极低这个缺点几乎可以被忽略。需要注意的是低延迟的前提是 go2rtc 和浏览器之间的网络质量不错。如果你走的是 WIFI 且信号特别差WebRTC 会频繁丢包画面可能会出现花屏或卡顿。5.3 远程访问时的 STUN/TURN 配置大多数人的需求不止于局域网人在外面也想看家里摄像头。这里就涉及到 WebRTC 的 NAT 穿越问题。NAT 简单理解就是你路由器对外的那层转换机制。家里的摄像头 IP 是 192.168.x.x这是内网地址从公网是访问不到这个地址的。WebRTC 为了建立连接需要跨越这个 NAT于是就有了 STUN 和 TURN。STUN 的作用是让你发现自己的公网 IP 和端口。对于大多数家庭网络路由器自动做了端口映射STUN 就能打通。这也是 go2rtc 默认配置里带 Google 公共 STUN 服务器的原因。但有些场景下 NAT 类型是对称型 NATSymmetric NAT这种 NAT 下 STUN 无法直接打洞必须借助 TURN 转发。TURN 服务器就是一个中继负责把媒体数据从一端转发到另一端。go2rtc 的 webrtc 配置里可以同时配置 STUN 和 TURNwebrtc: listen: :8555 ice_servers: - urls: - stun:stun.l.google.com:19302 - urls: - turn:你的TURN服务器地址:3478 username: 用户名 credential: 密码说实话自建 TURN 服务器有点复杂一般家庭用户不需要。如果你确实需要远程访问更简单的方式是用 HLS 而不是 WebRTC。HLS 走的是普通 HTTP 协议不存在 NAT 穿越问题你只需要把 1984 端口暴露出去或者通过反向代理暴露一条 HTTP 路径就行。5.4 浏览器播放 H.265 的限制与绕过思路前面提到 H.265 的问题这里详细展开一下。H.265HEVC是一种高压缩率的视频编码同等画质下码率只有 H.264 的一半所以现在的摄像头出厂默认基本都开 H.265。问题是主流浏览器对 H.265 的解码支持非常差。Chrome 在桌面端支持要看硬件和系统Firefox 直接就不支持Safari 倒是支持但也看版本。这就导致一个很尴尬的局面你明明成功接入了摄像头的流go2rtc 这边一切正常但浏览器里就是黑屏。解决思路有三个第一在摄像头后台把编码改成 H.264。这是最简单的办法缺点是同样的清晰度下码率会高一点存储压力变大。第二在 go2rtc 里配置 FFmpeg 转码把 H.265 实时转成 H.264。go2rtc 支持在流的配置里指定 FFmpeg 参数类似这样streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102 - ffmpeg:driveway#videoh264#audioopus这条配置的意思是同时维护两个版本的流一个是原始流一个是经过 FFmpeg 转码成 H.264 的流。浏览器播放时优先选转码后的流。第三使用 go2rtc 的 WebRTC 播放能力因为 WebRTC 的编码协商机制会尽量选择浏览器支持的编码格式。但最终能不能播还是取决于浏览器底层的解码能力并没有完全绕开 H.265 的限制。我的选择是能改 H.264 就改 H.264。实在不能改的摄像头才上 FFmpeg 转码。6. 与 Frigate、Home Assistant 的联动扩展6.1 Frigate 接入 go2rtc 作为直播源如果你做智能家居大概率知道 Frigate——一个开源的 NVR 和物体检测方案。Frigate 现在也内置了自己的流媒体模块能直接拉取 RTSP但它的流媒体模块在 WebRTC 低延迟播放这块实现得比较弱。Frigate 官方文档实际上就推荐用 go2rtc 作为直播源Frigate 只负责录像和人物检测。这样分工的好处是go2rtc 负责把摄像头的流收拾干净以低延迟方式分发给浏览器Frigate 从 go2rtc 这里拉 RTSP 流做检测和录像互相不干扰。Frigate 的配置里把摄像头源指到 go2rtccameras: driveway: ffmpeg: inputs: - path: rtsp://127.0.0.1:8554/driveway roles: - detect - record而在 go2rtc 这边我仍然只保留摄像头的直接 RTSP 配置。这样链路是摄像头 → go2rtc → Frigate中途没有多余的转码。6.2 Home Assistant 的摄像头集成Home Assistant 的官方集成里有一个 Camera 平台可以直接连接 go2rtc。具体配置是在 Home Assistant 的configuration.yaml里添加camera平台camera: - platform: generic name: driveway_live stream_source: rtsp://127.0.0.1:8554/driveway still_image_url: http://127.0.0.1:1984/api/frame.jpg?srcdriveway这里我用stream_source指定了 go2rtc 的 RTSP 地址用still_image_url指定了 go2rtc 的截图 API。这样在 Home Assistant 的界面上你不仅能看实时画面还能看到缩略图而且缩略图是 go2rtc 帮你抓好的不用 Home Assistant 自己去折腾。另外Home Assistant 的官方集成还支持直接添加 go2rtc 的 Web UI 面板作为 dashboards 里的一个 iframe 嵌入。这种玩法适合喜欢把所有设备管理集中到一个界面的用户。6.3 OBS、VLC、手机 App 拉流到其他终端go2rtc 的输出能力不局限于浏览器。我经常用到的场景是OBS 直播或录屏时把摄像头画面作为素材源。OBS 不支持 RTSP但支持媒体源通过 URL 播放。我在 OBS 里添加媒体源填入 go2rtc 的 RTSP 地址rtsp://127.0.0.1:8554/driveway画面直接进来延时还低。VLC 播放器直接打开 HLS 地址用来在电脑上快速验证某个流是否正常。手机上的第三方播放器 App 也可以直接填 go2rtc 的 RTSP 地址播放。不过注意手机上如果用 4G 网络访问公网视频走 RTSP 时不时会被运营商或者防火墙限制。这时候用 HLS 更稳。所有这些消费端的接入本质上都是在消费 go2rtc 暴露的多协议出口。这也是我把它作为整个流媒体平台核心的原因。7. 实际运行中遇到的坑与处理记录7.1 WebRTC 建连失败排查链路我最初在远程访问场景下遇到一个典型问题局域网内 WebRTC 播放正常但从外网连的时候一直转圈画面出不来。排查了一圈最后发现是 STUN 服务器不可达。排查链路是这样的第一步看 go2rtc 日志。执行docker logs go2rtc如果 WebRTC 连接相关条目显示ICE failed说明 NAT 穿越没成功。第二步测试 STUN 服务器连通性。用 curl 或者 nc 测试 UDP 端口是否通。很多网络环境下UDP 的 19302 端口是被防火墙屏蔽的。第三步换一个可用的 STUN 服务器。国内网络环境下Google 的 STUN 服务器有时候不稳定可以换成国内的 STUN 或者自建一个简单的 STUN 服务。这里要提醒STUN 服务器只需要在协商过程中被访问一旦连接建立媒体数据就直通了。所以临时换一个能用的 STUN 就行不用太纠结长期稳定性。7.2 升级版本后配置不兼容的现场go2rtc 迭代很快有一次我从一个比较旧的版本升级到最新版配置文件直接无法加载启动失败。日志显示配置解析错误。当时的处理办法是把配置逐项检查发现旧版本里一些streams下直接写rtsp://地址的简短语法在新版本里需要用数组形式也就是加一个短横线。类似这样旧写法streams: driveway: rtsp://admin:password192.168.1.100:554/Streaming/Channels/102新写法streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102虽然两者在很多时候都能解析但升级大版本后建议去看一眼官方文档的 changelog避免踩这种低级的兼容性坑。7.3 多路摄像头高负载下的资源占用观察我接入 8 路摄像头之后专门盯过 go2rtc 的资源占用。在我的实测里go2rtc 进程的内存占用大概在 100 到 150 MBCPU 占用非常低基本可以忽略不计。这得益于 Go 语言高效的并发模型还有它不做默认转码的设计。但如果你开了 FFmpeg 转码情况就完全不同了。一路 1080P H.265 转 H.264 的转码任务大约占满一个 CPU 核心多路转码的话对 CPU 的压力会成倍增加。如果你确实需要大量转码建议要么控制路数要么考虑用带 Intel Quick Sync 或 NVIDIA NVENC 的硬件。我实际操作中还有个体会摄像头如果真的长时间不重启RTSP 连接会偶尔出现假死。go2rtc 本身有重连机制但为了更稳妥我在 Docker 层面配置了--restart unless-stopped同时在摄像头侧也设置定期重启这样能极大减少断流风险。8. 最后再分享几个实测中的小技巧前面把整个部署和调试过程写得差不多了最后再补充几个我觉得很有价值的小经验。第一个是关于日志的。go2rtc 的日志里会显示每个流的接入耗时和状态如果你发现某个流接入特别慢大概率是摄像头侧的响应出了问题。这时候去摄像头后台看看是不是固件版本太老或者 IP 有冲突。第二个是关于 API 的。go2rtc 的 API 接口特别丰富可以用来做很多自动化操作。比如我想在特定时间截图存档就用一个定时任务去请求http://127.0.0.1:1984/api/frame.jpg?src摄像头名把返回的图片存下来。这个接口轻量可靠比我自己去折腾 FFmpeg 抓帧方便太多。第三个是关于安全的。go2rtc 的 Web UI 默认是没有鉴权的也就是说任何能访问到你 1984 端口的人都能看到你所有摄像头的画面。如果你打算通过公网访问这个端口一定要在前面加一层反向代理做认证。我自己用 Nginx 做了一层 HTTP Basic Auth 或者用 Cloudflare 做 Access 控制确保不是裸奔状态。第四个是关于备份的。go2rtc 的配置就一个go2rtc.yaml文件我会定期备份它。因为摄像头一旦配置好换设备重装系统之后只要把这个文件放回去所有配置就回来了不用一个个重新添加。go2rtc 这个项目值不值得长期用我的判断是只要你的核心需求是把各种协议、各种品牌的摄像头统一到一套流媒体体系里它就一定值得。它可能不完美但它在做一个好用的摄像头流媒体中间层这件事上确实做到了同级别方案里最顺手的那一个。我实际用了大半年最满意的是它把复杂的技术细节藏得干干净净同时又保留了足够多的配置项让高级用户去折腾。希望这篇文章能帮你把第一套 go2rtc 平台顺利跑起来少走我之前走过的弯路。
前一阵把家里和工作室的几路摄像头全部迁到了自建的流媒体平台陆陆续续折腾了大概一周最后沉淀下来的核心组件就是 go2rtc。这个东西在智能家居圈子里其实挺出名但很多人只知道它能配 Home Assistant不知道它本身就是一个非常能打的摄像头多协议流媒体服务器。这篇文章就把我从 Docker 部署、摄像头接入、WebRTC 低延迟播放到跟 Frigate、Home Assistant 联动这一整套过程完整写出来包括踩过的坑和排查思路希望能给正在折腾摄像头的朋友省点时间。go2rtc 最打动我的点是它把摄像头接入和多协议输出这两件事做得极其干净。你不需要理解 RTSP 的底层细节也不用操心 HLS 分片、WebRTC 信令这些复杂概念装好之后打开浏览器就能看。配合 Docker 部署从零到跑通基本十分钟以内。1. 为什么是 go2rtc多协议汇聚的选型思考1.1 流媒体平台的核心矛盾协议不通、延迟太高先说我遇到的真实场景。家里有两个海康摄像头一个杂牌 RTSP 摄像头车库里还放了一台树莓派接的是 OV5647 摄像头模块。问题来了海康用海康自己的 App 看杂牌摄像头要看它的云平台树莓派要自己写代码拉流。手机上要装四五个 App家里人根本没法用。很多人第一反应是把所有摄像头接到一个 NVR 里。但 NVR 解决的是录像存储问题不是播放体验问题。我要的是打开一个页面所有摄像头都在这点一下就能看最好延迟还低。这时候就需要一个能做协议汇聚的中间层。另一个痛点就是延迟。RTSP 协议本身很优秀但浏览器原生不支持 RTSP。传统的解决方式是转成 HLS 或 RTMP 再播放HLS 延迟通常在 3 到 10 秒RTMP 也需要 Flash 或者额外插件。对于看摄像头这种场景3 秒延迟其实勉强能忍但如果你在门口装个摄像头有人按门铃你都看不到人这就很尴尬了。1.2 go2rtc 的核心设计一个二进制解决协议转换go2rtc 是一个用 Go 语言写的流媒体服务器作者是 Home Assistant 社区的知名开发者 AlexxIT。它最核心的能力是把 RTSP、RTMP、HLS、WebRTC、MJPEG 这些协议全部打通。我理解的 go2rtc 工作方式是这样的摄像头提供 RTSP 流go2rtc 作为一个中转层接入这个流然后对外统一输出多种协议。你在浏览器里看它走 WebRTC你用 VLC 看它走 RTSP 或者 HLS你在手机 App 里看可以走 HLS 或者 RTSP。它最牛逼的地方在 WebRTC 的支持。大家知道WebRTC 是浏览器原生支持的低延迟音视频通信协议端到端延迟能做到 500 毫秒以内。但 WebRTC 和 RTSP 完全是两个世界的协议普通开发者根本不可能自己写一个 RTSP 转 WebRTC 的网关。go2rtc 把这个能力内置了你只需要给摄像头配一个 RTSP 地址浏览器就能以接近实时的延迟看到画面。这背后的原理其实不复杂go2rtc 从摄像头拉取 RTSP 流提取 RTP 包然后重新封装成 WebRTC 可以处理的格式再通过 WebRTC 的 DTLS-SRTP 加密通道发给浏览器。因为中间没有转码步骤所以延迟非常低。当然go2rtc 也支持通过 FFmpeg 做转码但一般用不上。1.3 横向对比为什么不是 Nginx-RTMP 或 mediamtx这里要聊一下选型对比因为很多人会问我直接用 Nginx-RTMP 行不行mediamtx 不是也能做 RTSP 转 HLS 吗。我自己实际上都试过。Nginx-RTMP 模块的问题是它主要是为 RTMP 直播设计的对 RTSP 的支持很弱你需要先把摄像头的 RTSP 流推成 RTMP再分发成 HLS链路长且配置繁琐。mediamtx前身是 RTSP-Simple-Server是个不错的轻量级方案支持 RTSP 输入输出和 HLS 输出但它对 WebRTC 的支持相对弱而且没有 go2rtc 那种一体化的配置体验。我用一个表格总结这几个方案的差异方案RTSP 输入WebRTC 输出HLS 输出配置复杂度摄像头自动发现Nginx-RTMP弱不支持需要额外模块高无mediamtx支持弱支持中等无go2rtc支持原生支持支持低支持 ONVIF所以我的结论是如果你想搭建一个纯粹的、以摄像头为核心的流媒体平台go2rtc 是目前综合成本最低的方案。它不是万能的但它在摄像头接入这个领域做得足够专精。2. 部署前的网络与 Docker 环境规划2.1 端口清单与网络模式选择go2rtc 默认使用的端口有这几个1984Web 管理界面和 API 接口TCP8554RTSP 服务端口TCP8555WebRTC 媒体传输端口TCP UDPDocker 部署时有两种网络模式可以选。第一种是 bridge 模式这也是大家最熟悉的模式通过-p参数把容器端口映射到宿主机。这种模式下容器是一个独立的网络栈所有端口都需要显式映射。第二种是 host 网络模式容器直接使用宿主机的网络栈不做端口隔离。go2rtc 官方文档实际上更推荐 host 模式原因有两点WebRTC 传输涉及多个 UDP 端口的动态协商bridge 模式下端口映射容易漏摄像头自动发现功能依赖网络广播和多播host 模式才能确保这些包正常收发我个人的建议是如果你在 Linux 服务器上部署直接用 host 模式省心。如果你在 Windows/macOS 上用 Docker Desktophost 模式的支持不完美那就老老实实用 bridge 模式并映射所有端口。2.2 Windows/Linux 下 Docker 环境最容易踩的坑先说 Windows。很多人在装 Docker Desktop 的时候会卡在启动阶段报错信息是 virtualization support not detected大意是检测不到虚拟化支持。这个问题的根源通常是 BIOS 里的虚拟化开关没开Intel 的 CPU 要开 VT-xAMD 的 CPU 要开 SVM。我遇到过不止一次新手在 Windows 上装 Docker Desktop装完发现起不来然后各种折腾最后发现只是 BIOS 里一个开关的事。步骤很简单重启进 BIOS → 找到 Intel Virtualization Technology 或者 SVM Mode → 设置为 Enabled → 保存退出。另外 Windows 的 Hyper-V 和 Windows Hypervisor Platform 这两个功能也要在启用或关闭 Windows 功能里打开。还有一个比较容易忽略的点go2rtc 是 Linux 容器不要用 Windows 容器模式跑。Docker Desktop 安装的时候默认是 Linux 容器但如果你之前切换过记得切回来。Linux 服务器上主要注意 Docker 版本尽量装比较新的版本。老版本 Docker 对 Compose V2 的支持不完善而后面的 docker compose 命令注意中间没有空格依赖 Compose V2。2.3 目录规划与 config.yaml 初始结构go2rtc 的配置存在/config目录下的 go2rtc.yaml 文件里。第一次启动时go2rtc 会自动生成一个默认的配置文件你也可以提前手动创建好再启动。我习惯这样的目录结构/path/to/go2rtc/ ├── config/ │ └── go2rtc.yaml └── recordings/ # 如果后续接录制功能可以用这个目录初始的 go2rtc.yaml 实际上可以非常简洁。这是我最开始用的配置log: level: info api: listen: :1984 webrtc: listen: :8555 ice_servers: - urls: [stun:stun.l.google.com:19302] rtsp: listen: :8554 streams: cam_test: rtsp://192.168.1.100:554/live这段配置里api、webrtc、rtsp分别定义了三个服务的监听地址streams是摄像头流的核心配置。cam_test是我给摄像头起的名字后面的 RTSP 地址是它的源。ice_servers这个配置很多人搞不明白。WebRTC 在建立连接的时候需要知道自己的公网 IP 和端口这个过程叫 ICE 协商。STUN 服务器的作用是帮浏览器和 go2rtc 发现彼此的可达地址。如果是纯局域网使用不配置 STUN 也能跑通因为双方都在同一个网段互相广播就能找到对方。但如果要从外网访问就必须配置 STUN 服务器否则 WebRTC 连接大概率失败。3. Docker 部署 go2rtc 的完整过程3.1 用 docker run 快速验证如果你只想先看看 go2rtc 长什么样一条 docker run 命令就够了。我用 host 模式演示docker run -d \ --name go2rtc \ --network host \ --restart unless-stopped \ -v /path/to/go2rtc/config:/config \ alexxit/go2rtc:latest注意几个参数-d表示后台运行--network host使用宿主机网络容器内的 1984、8554、8555 端口直接暴露-v把本机的配置目录挂载到容器的/config这样以后改配置不需要进入容器--restart unless-stopped让 Docker 在宿主机重启后自动拉起容器如果你是 bridge 模式对应命令是这样的docker run -d \ --name go2rtc \ -p 1984:1984 \ -p 8554:8554 \ -p 8555:8555/tcp \ -p 8555:8555/udp \ -v /path/to/go2rtc/config:/config \ alexxit/go2rtc:latest启动之后浏览器打开http://服务器IP:1984你就能看到 go2rtc 的 Web 管理界面。这个界面自带一个播放器还有一个摄像头添加入口。3.2 用 docker compose 落地生产配置docker run 适合验证但真正长期使用的项目我会用 docker compose 管理。好处是配置可以版本控制而且可以一次性定义所有服务。这是我的 docker-compose.ymlservices: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc network_mode: host restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/config注意我用了network_mode: host原因前面已经解释过。如果用 bridge 模式需要把端口映射也写进去。启动命令docker compose up -d停止并删除docker compose down查看日志docker logs -f go2rtc把这些命令记熟日常维护基本够用了。3.3 验证服务状态服务起来之后我会做三件事来确认一切正常。第一打开 Web UI。如果页面能正常加载说明 API 服务在跑。第二检查日志。执行docker logs go2rtc看有没有报错。正常情况下日志里会出现这样几行INFO go2rtc/rtsp: rtsp://:8554 INFO go2rtc/api: api://:1984 INFO go2rtc/webrtc: webrtc://:8555第三用 curl 访问 API 接口确认流列表是否有数据curl http://127.0.0.1:1984/api/streams这个接口返回的是 JSON 格式的流列表。如果没有配任何流会返回空数组这很正常。配置好摄像头之后再来看这里就能看到摄像头的信息。4. 摄像头接入实战手动地址与自动发现4.1 RTSP 地址的构成逻辑接入摄像头之前你必须先搞明白 RTSP 地址长什么样。RTSP 地址其实就是摄像头向外提供视频流的网络位置格式一般是这样rtsp://用户名:密码摄像头IP:554/路径你可能会说这不就是个 URL 吗确实但这里有几个隐藏的坑。第一个坑是密码里的特殊字符。如果摄像头密码里有、:、/这些字符直接拼在 URL 里会导致解析错误。比如密码是abc123那这个地址就废了。解决办法是把密码做 URL 编码编码成%40。所以abc123要写成abc%40123。第二个坑是主码流和子码流的问题。现在几乎所有的 IP 摄像头都有两路流主码流分辨率高、码率高子码流分辨率低、码率低。直播观看一般用子码流就够了因为省带宽、解码快需要录像或者看细节的时候才切主码流。go2rtc 支持把主码流和子码流配成两个不同的流名。第三个坑是 H.265 编码。很多新出的摄像头默认用 H.265 编码这种编码在摄像头本地 MJPEG 预览是没问题的但浏览器播放 H.265 的能力参差不齐。如果你发现浏览器里黑屏大概率是编码格式的问题这个我后面会详细讲。4.2 常见厂商摄像头 URL 模板不同厂商、不同型号的摄像头RTSP 路径差别很大。我整理了自己实测过的一些模板给大家参考品牌主码流 RTSP 地址海康威视rtsp://user:passip:554/Streaming/Channels/101大华rtsp://user:passip:554/cam/realmonitor?channel1subtype0TP-LINKrtsp://user:passip:554/stream1杂牌/工控机不固定一般在设备文档里找海康的地址里101表示通道 1 主码流102表示通道 1 子码流。大华的地址里subtype0是主码流subtype1是子码流。很多杂牌摄像头不着调RTSP 路径五花八门。遇到这种情况我的经验是先在电脑上用 VLC 打开rtsp://ip:554/看返回什么。VLC 有时候能自动探测到路径。如果探测不到就去摄像头 App 的后台界面找技术参数页那里通常会写 RTSP 地址。4.3 用 ONVIF 自动发现降低接入成本如果你有不少摄像头要接手动一个个填 RTSP 地址也挺累的。go2rtc 的 Web UI 里有一个添加摄像头的入口它支持通过 ONVIF 协议自动发现局域网里的摄像头。ONVIF 是一个安防设备的标准化协议说白了就是摄像头之间、摄像头和软件之间的通用握手语言。go2rtc 通过 ONVIF 可以做到发现设备、读取设备能力、根据账号密码自动列出可用的视频流。用 ONVIF 添加摄像头的步骤大概是这样在 go2rtc Web UI 的添加页面里选择摄像头类型输入摄像头的 IP 地址以及摄像头的管理员账号密码go2rtc 发起 ONVIF 探测自动识别 RTSP 地址并填入配置确认保存流就被加进来了这个功能对海康、大华这些主流品牌支持的还不错。不过要提醒一点ONVIF 需要摄像头开启对应功能。海康的摄像机有些批次默认不开 ONVIF需要在摄像头网页后台的网络 → 高级设置 → 集成协议里把 ONVIF 打开并设置独立的 ONVIF 用户。这个用户和摄像头管理员账号不一定是同一个别搞混了。4.4 接入失败的常见原因定位摄像头接入不成功90% 是这几个原因按可能性从高到低排账号密码错误或者权限不足RTSP 地址错误尤其是路径写错摄像头和 go2rtc 不在同一个网段防火墙挡了 554 端口摄像头编码格式特殊go2rtc 无法解析摄像头 IP 摄像头有连接数限制已经被别的 App 占满了排查的时候我的建议是先绕过 go2rtc直接用 VLC 拉流测试。VLC 能打开说明源没问题问题在 go2rtc 配置。VLC 打不开先查网络和凭证。还有一个值得注意的点有些厂商的摄像头在开启 H.265 的同时还会开启动态码率或者智能编码之类的功能。这些功能会导致码率波动很大影响播放稳定性。接入 go2rtc 的时候如果画面频繁卡顿可以考虑在摄像头后台把这些功能关掉。5. 多协议输出与低延迟调优5.1 一个源同时输出多个协议go2rtc 的魅力在配置好一个源之后能自动输出多种协议。我这里用一个完整的配置示例来讲。假设我配置文件里有这样的内容streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102那么driveway这一个流就会自动拥有以下这些访问地址WebRTC 播放打开 Web UI 找到driveway点播放走的就是 WebRTCRTSP 取流rtsp://127.0.0.1:8554/driveway供 VLC、Frigate、NVR 使用HLS 播放http://127.0.0.1:1984/api/stream.m3u8?srcdriveway供手机浏览器、网页播放器使用MJPEG 输出http://127.0.0.1:1984/api/frame.jpg?srcdriveway可以做成简单的定时抓图这种一个源多协议输出的设计让 go2rtc 变成了一个非常灵活的中间层。我不用为每个场景单独搭一条流。5.2 局域网 WebRTC 观看的延迟表现我实测过局域网环境下 WebRTC 的延迟。当时我用手机秒表对着摄像头画面同时盯着屏幕上的直播画面两者做差。结果是从画面真实发生到屏幕上显示延迟大概在 300 到 500 毫秒之间。相比 HLS 动辄 3 到 5 秒的延迟这个体验完全是两个级别。这个低延迟主要来自 WebRTC 的 UDP 传输机制。它不像 HLS 那样需要把视频先切成一个个小块再让播放器下载播放而是直接用 UDP 包实时推送。UDP 的缺点是丢包不重传但在局域网这种高可靠网络环境下丢包率极低这个缺点几乎可以被忽略。需要注意的是低延迟的前提是 go2rtc 和浏览器之间的网络质量不错。如果你走的是 WIFI 且信号特别差WebRTC 会频繁丢包画面可能会出现花屏或卡顿。5.3 远程访问时的 STUN/TURN 配置大多数人的需求不止于局域网人在外面也想看家里摄像头。这里就涉及到 WebRTC 的 NAT 穿越问题。NAT 简单理解就是你路由器对外的那层转换机制。家里的摄像头 IP 是 192.168.x.x这是内网地址从公网是访问不到这个地址的。WebRTC 为了建立连接需要跨越这个 NAT于是就有了 STUN 和 TURN。STUN 的作用是让你发现自己的公网 IP 和端口。对于大多数家庭网络路由器自动做了端口映射STUN 就能打通。这也是 go2rtc 默认配置里带 Google 公共 STUN 服务器的原因。但有些场景下 NAT 类型是对称型 NATSymmetric NAT这种 NAT 下 STUN 无法直接打洞必须借助 TURN 转发。TURN 服务器就是一个中继负责把媒体数据从一端转发到另一端。go2rtc 的 webrtc 配置里可以同时配置 STUN 和 TURNwebrtc: listen: :8555 ice_servers: - urls: - stun:stun.l.google.com:19302 - urls: - turn:你的TURN服务器地址:3478 username: 用户名 credential: 密码说实话自建 TURN 服务器有点复杂一般家庭用户不需要。如果你确实需要远程访问更简单的方式是用 HLS 而不是 WebRTC。HLS 走的是普通 HTTP 协议不存在 NAT 穿越问题你只需要把 1984 端口暴露出去或者通过反向代理暴露一条 HTTP 路径就行。5.4 浏览器播放 H.265 的限制与绕过思路前面提到 H.265 的问题这里详细展开一下。H.265HEVC是一种高压缩率的视频编码同等画质下码率只有 H.264 的一半所以现在的摄像头出厂默认基本都开 H.265。问题是主流浏览器对 H.265 的解码支持非常差。Chrome 在桌面端支持要看硬件和系统Firefox 直接就不支持Safari 倒是支持但也看版本。这就导致一个很尴尬的局面你明明成功接入了摄像头的流go2rtc 这边一切正常但浏览器里就是黑屏。解决思路有三个第一在摄像头后台把编码改成 H.264。这是最简单的办法缺点是同样的清晰度下码率会高一点存储压力变大。第二在 go2rtc 里配置 FFmpeg 转码把 H.265 实时转成 H.264。go2rtc 支持在流的配置里指定 FFmpeg 参数类似这样streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102 - ffmpeg:driveway#videoh264#audioopus这条配置的意思是同时维护两个版本的流一个是原始流一个是经过 FFmpeg 转码成 H.264 的流。浏览器播放时优先选转码后的流。第三使用 go2rtc 的 WebRTC 播放能力因为 WebRTC 的编码协商机制会尽量选择浏览器支持的编码格式。但最终能不能播还是取决于浏览器底层的解码能力并没有完全绕开 H.265 的限制。我的选择是能改 H.264 就改 H.264。实在不能改的摄像头才上 FFmpeg 转码。6. 与 Frigate、Home Assistant 的联动扩展6.1 Frigate 接入 go2rtc 作为直播源如果你做智能家居大概率知道 Frigate——一个开源的 NVR 和物体检测方案。Frigate 现在也内置了自己的流媒体模块能直接拉取 RTSP但它的流媒体模块在 WebRTC 低延迟播放这块实现得比较弱。Frigate 官方文档实际上就推荐用 go2rtc 作为直播源Frigate 只负责录像和人物检测。这样分工的好处是go2rtc 负责把摄像头的流收拾干净以低延迟方式分发给浏览器Frigate 从 go2rtc 这里拉 RTSP 流做检测和录像互相不干扰。Frigate 的配置里把摄像头源指到 go2rtccameras: driveway: ffmpeg: inputs: - path: rtsp://127.0.0.1:8554/driveway roles: - detect - record而在 go2rtc 这边我仍然只保留摄像头的直接 RTSP 配置。这样链路是摄像头 → go2rtc → Frigate中途没有多余的转码。6.2 Home Assistant 的摄像头集成Home Assistant 的官方集成里有一个 Camera 平台可以直接连接 go2rtc。具体配置是在 Home Assistant 的configuration.yaml里添加camera平台camera: - platform: generic name: driveway_live stream_source: rtsp://127.0.0.1:8554/driveway still_image_url: http://127.0.0.1:1984/api/frame.jpg?srcdriveway这里我用stream_source指定了 go2rtc 的 RTSP 地址用still_image_url指定了 go2rtc 的截图 API。这样在 Home Assistant 的界面上你不仅能看实时画面还能看到缩略图而且缩略图是 go2rtc 帮你抓好的不用 Home Assistant 自己去折腾。另外Home Assistant 的官方集成还支持直接添加 go2rtc 的 Web UI 面板作为 dashboards 里的一个 iframe 嵌入。这种玩法适合喜欢把所有设备管理集中到一个界面的用户。6.3 OBS、VLC、手机 App 拉流到其他终端go2rtc 的输出能力不局限于浏览器。我经常用到的场景是OBS 直播或录屏时把摄像头画面作为素材源。OBS 不支持 RTSP但支持媒体源通过 URL 播放。我在 OBS 里添加媒体源填入 go2rtc 的 RTSP 地址rtsp://127.0.0.1:8554/driveway画面直接进来延时还低。VLC 播放器直接打开 HLS 地址用来在电脑上快速验证某个流是否正常。手机上的第三方播放器 App 也可以直接填 go2rtc 的 RTSP 地址播放。不过注意手机上如果用 4G 网络访问公网视频走 RTSP 时不时会被运营商或者防火墙限制。这时候用 HLS 更稳。所有这些消费端的接入本质上都是在消费 go2rtc 暴露的多协议出口。这也是我把它作为整个流媒体平台核心的原因。7. 实际运行中遇到的坑与处理记录7.1 WebRTC 建连失败排查链路我最初在远程访问场景下遇到一个典型问题局域网内 WebRTC 播放正常但从外网连的时候一直转圈画面出不来。排查了一圈最后发现是 STUN 服务器不可达。排查链路是这样的第一步看 go2rtc 日志。执行docker logs go2rtc如果 WebRTC 连接相关条目显示ICE failed说明 NAT 穿越没成功。第二步测试 STUN 服务器连通性。用 curl 或者 nc 测试 UDP 端口是否通。很多网络环境下UDP 的 19302 端口是被防火墙屏蔽的。第三步换一个可用的 STUN 服务器。国内网络环境下Google 的 STUN 服务器有时候不稳定可以换成国内的 STUN 或者自建一个简单的 STUN 服务。这里要提醒STUN 服务器只需要在协商过程中被访问一旦连接建立媒体数据就直通了。所以临时换一个能用的 STUN 就行不用太纠结长期稳定性。7.2 升级版本后配置不兼容的现场go2rtc 迭代很快有一次我从一个比较旧的版本升级到最新版配置文件直接无法加载启动失败。日志显示配置解析错误。当时的处理办法是把配置逐项检查发现旧版本里一些streams下直接写rtsp://地址的简短语法在新版本里需要用数组形式也就是加一个短横线。类似这样旧写法streams: driveway: rtsp://admin:password192.168.1.100:554/Streaming/Channels/102新写法streams: driveway: - rtsp://admin:password192.168.1.100:554/Streaming/Channels/102虽然两者在很多时候都能解析但升级大版本后建议去看一眼官方文档的 changelog避免踩这种低级的兼容性坑。7.3 多路摄像头高负载下的资源占用观察我接入 8 路摄像头之后专门盯过 go2rtc 的资源占用。在我的实测里go2rtc 进程的内存占用大概在 100 到 150 MBCPU 占用非常低基本可以忽略不计。这得益于 Go 语言高效的并发模型还有它不做默认转码的设计。但如果你开了 FFmpeg 转码情况就完全不同了。一路 1080P H.265 转 H.264 的转码任务大约占满一个 CPU 核心多路转码的话对 CPU 的压力会成倍增加。如果你确实需要大量转码建议要么控制路数要么考虑用带 Intel Quick Sync 或 NVIDIA NVENC 的硬件。我实际操作中还有个体会摄像头如果真的长时间不重启RTSP 连接会偶尔出现假死。go2rtc 本身有重连机制但为了更稳妥我在 Docker 层面配置了--restart unless-stopped同时在摄像头侧也设置定期重启这样能极大减少断流风险。8. 最后再分享几个实测中的小技巧前面把整个部署和调试过程写得差不多了最后再补充几个我觉得很有价值的小经验。第一个是关于日志的。go2rtc 的日志里会显示每个流的接入耗时和状态如果你发现某个流接入特别慢大概率是摄像头侧的响应出了问题。这时候去摄像头后台看看是不是固件版本太老或者 IP 有冲突。第二个是关于 API 的。go2rtc 的 API 接口特别丰富可以用来做很多自动化操作。比如我想在特定时间截图存档就用一个定时任务去请求http://127.0.0.1:1984/api/frame.jpg?src摄像头名把返回的图片存下来。这个接口轻量可靠比我自己去折腾 FFmpeg 抓帧方便太多。第三个是关于安全的。go2rtc 的 Web UI 默认是没有鉴权的也就是说任何能访问到你 1984 端口的人都能看到你所有摄像头的画面。如果你打算通过公网访问这个端口一定要在前面加一层反向代理做认证。我自己用 Nginx 做了一层 HTTP Basic Auth 或者用 Cloudflare 做 Access 控制确保不是裸奔状态。第四个是关于备份的。go2rtc 的配置就一个go2rtc.yaml文件我会定期备份它。因为摄像头一旦配置好换设备重装系统之后只要把这个文件放回去所有配置就回来了不用一个个重新添加。go2rtc 这个项目值不值得长期用我的判断是只要你的核心需求是把各种协议、各种品牌的摄像头统一到一套流媒体体系里它就一定值得。它可能不完美但它在做一个好用的摄像头流媒体中间层这件事上确实做到了同级别方案里最顺手的那一个。我实际用了大半年最满意的是它把复杂的技术细节藏得干干净净同时又保留了足够多的配置项让高级用户去折腾。希望这篇文章能帮你把第一套 go2rtc 平台顺利跑起来少走我之前走过的弯路。
)
