只用3个配置文件，把家里7台摄像头统一到浏览器里看：go2rtc实战部署

只用3个配置文件把家里7台摄像头统一到浏览器里看go2rtc实战部署【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtc家里陆续添了不同品牌的摄像头大华的、TP-Link Tapo的、还有一台只支持ONVIF的杂牌以及一个连接着Home Assistant的监控环境。每一台都要装各自的App在手机和电脑上分别登录查看延迟还特别高——点开预览要等两秒画面才出来。如果你也有类似的烦恼那么 go2rtc 值得花一个下午折腾一下。这是一个开源的终极摄像头流媒体网关用 Go 编写零依赖单文件能同时兼容 RTSP、ONVIF、WebRTC、HomeKit 等几十种协议把不同品牌摄像头统一成一个浏览器页面就能看的流服务。这篇文章我不打算写成一个功能清单式的介绍而是按我实际的调试过程从一个最小可用的配置开始一步一步加功能先让画面能看再解决多设备兼容和延迟最后加上语音对讲和推流到直播平台。每一层我都会告诉你为什么要这么加以及踩过哪些坑。先花5分钟把最小可用跑起来go2rtc 的部署门槛比我预想的低很多。它连依赖都不用装——不需要 Python、不需要 Node甚至不需要 FFmpeg只有需要转码时才用到。你只需要到项目 releases 页下载对应平台的单文件二进制Linux 选go2rtc_linux_amd64树莓派选go2rtc_linux_arm64Windows 选go2rtc_win64.zip给它执行权限并运行chmod x go2rtc_linux_amd64 ./go2rtc_linux_amd64预期结果终端出现api、rtsp、webrtc等模块启动日志然后保持前台运行。此时打开浏览器访问http://localhost:1984你会看到一个简洁的 Web 界面这就是 go2rtc 的配置和播放入口。要点默认端口有三个——1984是 Web 界面和 HTTP API8554是 RTSP 服务8555是 WebRTC 连接TCP/UDP。如果你要远程访问路由器上要放行这些端口。go2rtc 启动时会自动在当前目录寻找go2rtc.yaml作为配置文件。如果没有这个文件它也能空跑起来。接下来就是往配置里塞第一个摄像头。从零开始写第一份 go2rtc.yaml接入一个 RTSP 摄像头我的第一台摄像头是大华的RTSP 地址是rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype0。新建go2rtc.yamlstreams: dahua_gate: rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype0保存后重启 go2rtc或直接在 Web 界面里改配置它会热加载。然后在浏览器打开http://localhost:1984/stream.html?srcdahua_gate。预期结果页面上出现摄像头实时画面。注意看go2rtc 会自动选择 WebRTC 作为传输方式——这也是它最大的卖点之一WebRTC 在局域网内能把延迟压到几百毫秒以内。避坑不同品牌 RTSP 路径差异很大。海康一般是.../Streaming/Channels/101TP-Link 是.../stream1Reolink 是.../h264Preview_01_main。如果连不上先在 Web 界面的对应流上查看报错日志再用 VLC 验证一下原始 RTSP 地址是否本身可用。这里有个非常实用的知识点?subtype0是主码流高清subtype1是子码流低分辨率。如果你只是想快速预览用子码流加载更快需要看细节时才切主码流。go2rtc 允许你在同一个流名下配置多个源它会在其中自动选择、匹配。把第二层加上多源多协议让一个流名承载所有设备当第二台、第三台摄像头陆续进场问题就来了一台只支持 ONVIF一台是 TP-Link Tapo不支持标准 RTSP 直连还有一台接在 Home Assistant 里。我不想在配置文件里维护三套 URL更不想在浏览器里开三个页面。这时候可以给同一个流配置多个来源streams: courtyard: - rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype0 - rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype1 - onvif://admin:密码192.168.1.101:80 tapo_door: - ffmpeg:tapo://admin:密码192.168.1.102courtyard这个流名下挂了主码流、子码流和一台 ONVIF 摄像头go2rtc 会按需从合适的源取流。tapo_door里那个ffmpeg:前缀值得特别说明Tapo 这类封闭协议的摄像头go2rtc 已经内置了原生支持tapo://是它专有的源类型会自动调用 FFmpeg 帮你做必要的封装转换。go2rtc 的设计可以概括为输入层任意协议输出层任意格式中间的协议转换对使用者透明要点go2rtc 支持几十种摄像头专有协议——TP-Link Tapo/Kasa、Wyze、小米、Tuya、Ring、GoPro、Nest 等都有内置支持这在同类工具里非常罕见。如果你的摄像头不支持 RTSP先查一下 go2rtc 的模块列表很可能直接写品牌名://就行。现在浏览器打开stream.html?srccourtyard能看到庭院画面srctapo_door能看到门铃画面。但还有一个现实问题家里的电视、客厅的 Home Assistant、偶尔用手机 4G 网络在外面看这些场景用的播放技术完全不同。这正是 go2rtc 最值钱的能力——自动编解码协商。让每个设备都能看编解码协商与 HLS/MSE 自动适配go2rtc 的 Web 前端会检测当前浏览器的能力自动在 WebRTC、MSEMedia Source Extensions、HLS、MP4 这些传输方式之间做选择。背后的逻辑可以概括成三条优先级优先选音视频都齐全的优先选更清晰的编码H265 H264传输方式上 WebRTC MSE HLS MJPEG这个顺序背后是有原因的。举个例子如果你的摄像头输出 H265 编码但你的旧笔记本浏览器不支持硬解 H265go2rtc 会自动回退到 H264 的源或者在必要时调用 FFmpeg 做转码。它不会傻乎乎地把 H265 原样推给你。对于苹果设备iPhone 和 iPad 不支持 HTTP 渐进式流媒体必须用 HLS。go2rtc 会自动感知到这一点给 iPhone 走 HLS给桌面 Chrome 走 WebRTC——同一套配置不同设备看到的是不同的传输链路但体验都是即开即播。streams: courtyard: - rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype0 - rtsp://admin:密码192.168.1.100:554/cam/realmonitor?channel1subtype1 - onvif://admin:密码192.168.1.101:80 - ffmpeg:${input}#videoh264#audioaac注意最后一行${input}表示引用本流已有的源#videoh264#audioaac表示如果需要把它转码成 H264 AAC。这条规则保证了任何不支持原始编码的设备都能兜底。${input}这个变量语法我在别的流媒体软件里很少见到写起来非常顺手。预期结果手机4G 网络访问http://你的公网IP:1984/stream.html?srccourtyard画面在 1~2 秒内出来且能正常出声。避坑如果你只配置了 H265 源又没加 FFmpeg 转码兜底桌面 Chrome 一般没问题新版已支持但 Firefox 会黑屏。判断方法是看 Web 界面里流的编解码信息——这是 go2rtc 排查为什么没画面的第一入口。双向语音对讲WebRTC 的隐藏福利我一直以为语音对讲是要靠各家厂商 App 的直到在 go2rtc 里试了一次才发现这个功能被很多教程忽略了。go2rtc 对支持双向音频的摄像头提供了backchannel能力——RTSP、ONVIF、Tapo、Dahua、TP-Link 甚至小米都在支持列表里。配置只需要一行streams: doorbell: - rtsp://admin:密码192.168.1.102:554/stream1 - backchannel:rtsp然后在浏览器打开http://localhost:1984/webrtc.html?srcdoorbellmediavideoaudiomicrophone授权浏览器使用麦克风后就能对着摄像头喊话了。提醒浏览器只有 HTTPS 页面下才会允许调用麦克风这是浏览器的安全限制。如果你是通过 IP 直连访问的 HTTP 页面对讲功能会被浏览器拦截。解决方案是给 go2rtc 套一层反向代理Nginx/Caddy加 HTTPS 证书。预期结果打开带microphone参数的页面后画面下方出现麦克风按钮点击说话摄像头扬声器出声。我第一次配置时踩过一个坑摄像头默认把音频设成了 AAC 编码但部分老款摄像头对讲只支持 PCMA/PCMU 低码率编码。这时候需要在 RTSP 源上补一条 FFmpeg 转码规则把音频转成摄像头能接收的编码doorbell: - rtsp://admin:密码192.168.1.102:554/stream1 - ffmpeg:${input}#audiopcma - backchannel:rtsp如果你不知道怎么判断摄像头支持哪种编码go2rtc 的 Web 界面在流启动后会直接显示可用的音频编码对着抄就行。看效果、查问题用好 Web 界面的两块透视镜到了这一步你的 go2rtc 应该已经能同时服务好几路流了。接下来我强烈建议你打开两个页面它们相当于流媒体服务的仪表盘和体检报告。第一个是配置页。在http://localhost:1984/config可以直接编辑go2rtc.yaml带语法高亮和校验改完即生效比在服务器上 vim 改文件直观得多。配置界面支持热更新这也是我调试多路流时效率最高的方式第二个是网络拓扑页http://localhost:1984/net。它会以节点图的形式展示当前所有活跃连接哪台设备在看哪路流、走的什么协议、传输了多少数据、延迟多少一目了然。当某一路流卡住时这张图能帮你快速定位是源端问题还是客户端问题避坑如果某路流在 net 页里显示异常断连先检查摄像头固件本身是否稳定。README 里其实有一段很诚恳的厂商体验表Reolink 某些型号的 RTSP 实现惨不忍睹TP-Link 有掉包问题杂牌摄像头普遍勉强能用。这些问题不是 go2rtc 的锅但 go2rtc 能做的是让你在同一个界面里看到这些异常而不是被各家 App 的模糊报错糊弄过去。最后一块拼图转码资源控制与安全收口当摄像头多到 7 台、同时还要给 Home Assistant 和手机端供流时有两件事必须处理转码开销和访问安全。关于转码go2rtc 的设计原则是能 copy 就不转码只有必要时才转——因为每次转码都意味着 CPU 开销。我家的树莓派扛不住太多路 H265 转码所以我的做法是支持硬解的源直接传原码流只有老设备访问时才走 FFmpeg 转码。如果你有 Intel 核显或 NVIDIA 显卡还可以启用硬件加速ffmpeg: hwaccel: vaapi vaapi_device: /dev/dri/renderD128要点FFmpeg 的#videocopy#audiocopy表示完全不解码直接封装转发几乎零 CPU 占用。能用 copy 的地方绝不要为了好看去转码。关于安全这一点很容易被忽略但必须提醒你go2rtc 默认把 Web 界面、RTSP、WebRTC 三个端口都暴露在局域网里也就是说你局域网里的任何设备都能无密码看你的摄像头画面。如果只是家里用风险可控但如果你的局域网里有不可信的设备或者端口映射到了公网就一定要收口api: listen: 127.0.0.1:1984 # 只允许本机访问 Web 界面 local_auth: true username: admin password: 你的强密码 rtsp: listen: 127.0.0.1:8554 # RTSP 也只绑定本机 webrtc: listen: :8555 # WebRTC 端口保持对外开放媒体传输本身是加密的其中local_auth: true配合账号密码即使本机访问也要认证。外部访问统一走反向代理加 HTTPS这样既安全又不破坏 WebRTC 的加密传输链路。注意不要把 API 暴露到公网——通过 API 可以调用exec这类模块等于给攻击者开了一扇直达服务器的门。做完这一步这套系统就可以长期稳定跑了。我目前的使用形态是Home Assistant 通过 go2rtc 的集成把 7 路摄像头全部纳管手机端用浏览器看实时画面需要回看时通过 FFmpeg 源录像到 NAS。当初折腾它花了差不多一个周末但现在新增一台摄像头只需要在配置里加一行——这个收益比省下那几台摄像头的品牌 App 要划算得多。如果你想更进一步可以试试这几条路把一路摄像头流推送到 YouTube 或 Telegram 直播配置里publish段直接写 RTMP 地址用preload让常开的摄像头在 go2rtc 启动时就预取流缩短首次打开的画面延迟或者直接读一读www/README.md用官方提供的 JavaScript API 给自家项目定制一个播放器。【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考