Go2rtc 模块体系详解：协议、格式与编解码能力矩阵

Go2rtc 模块体系详解：协议、格式与编解码能力矩阵

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

本篇基于 go2rtc 仓库中的 internal/README.md 文档展开，系统讲解 go2rtc 的“模块（module）/ 格式（format）/ 协议（protocol）”三层概念模型、FFmpeg 对齐的命名规范，以及覆盖全部 50+ 个模块的完整能力矩阵。读完后，你将能够准确判断任意一个 go2rtc 模块能否作为流输入（input）、流输出（output）、流 ingest 或双向音频（two-way），并结合 pkg/core 中的核心接口理解这些能力的源码级实现。

一、三层概念模型：Modules、Formats、Protocols

go2rtc 内部把“接入一路视频/音频流”这件事拆成了三个正交的层次，这也是 internal/README.md 的核心主张：

• Modules（模块）：实现具体通信 API——授权方式（authorization）、加密（encryption）、命令集（command set）、媒体报文结构（structure of media packets）。比如 RTSP 模块实现了 RTSP 信令握手与鉴权，ONVIF 模块实现了 SOAP 命令集，Wyze 模块实现了 tutk 私有协议的登录与取流。
• Formats（格式）：描述被传输数据本身的结构，即容器与编码层。比如mpegts、mp4、flv、adts、mjpeg、srtp。
• Protocols（协议）：负责数据传输的承载方式，比如rtsp、http、tcp、udp、ws、webrtc、ioctl。

一个典型的接入路径是：模块按协议建连 → 按格式解析数据 → 交给内部核心按 RTP 化的节点树分发。三层解耦正是 go2rtc 能用同一套核心处理几十种设备私有协议的基础。

命名规范：对齐 FFmpeg

internal/README.md 开篇就声明了命名原则：

go2rtc 尽量用 FFmpeg 中的命名方式来称呼格式、协议和编解码器。部分格式和协议是 go2rtc 独占支持的，在 FFmpeg 中没有对应物。

这意味着如果你熟悉 FFmpeg 的-f、-c参数体系，可以直接把矩阵表中的 format（如mpegts、yuv4mpegpipe、adts）与 FFmpeg 的 muxer/demuxer 名称对上号，无需二次学习。go2rtc 独有的部分（如tutk、cs2这类设备私有协议，或hap这类 HomeKit 协议）则按其自身实现命名。

二、四类特殊模块

矩阵表之外的几段文字，internal/README.md 对若干“不属于常规协议模块”的模块做了单独说明，这里完整继承并逐条解释：

1. 接收流链接的模块：echo、expr、hass、onvif

echo、expr、hass、onvif四个模块接收的是一个流链接（link to a stream）而非固定协议的直连地址，它们在解析前并不知道最终会用什么协议取流。以 echo 模块 为例，它执行一段 shell/python 脚本，把脚本打印出来的字符串当作真正的源地址：

streams: apple_hls: echo:python3 hls.py https://developer.apple.com/streaming/examples/basic-stream-osx-ios5.html

脚本内部可以先请求 HTML 页面、正则提取出 m3u8 地址，再打印ffmpeg:https://...#video=copy交给 ffmpeg 模块转接——也就是说 echo/expr 是“动态寻址层”，最终协议由被解析出的链接前缀决定。expr模块同理，用表达式语言做地址拼装与条件选择；hass模块从 Home Assistant 实体中查出流地址；onvif通过 SOAP 协议向设备动态查询 RTSP 取流 URL（如ProfileToken换 URL），因此矩阵中它们的 formats/protocols 一栏标注为*（任意/取决于被解析链接）。

2. 多格式模块：exec 与 ffmpeg

exec与ffmpeg模块支持多种格式，能力上与http模块完全对等（矩阵中 formats 列同样标*）。ffmpeg 模块通过子进程调用本机 FFmpeg，把其输出（pipe 或回推 RTSP）交给 go2rtc；exec 模块则执行任意命令并把其 stdout 当作数据流。两者的 protocols 列标注为pipe、rtsp，即数据要么走管道回传，要么由 FFmpeg 以 RTSP 形式推回 go2rtc 的 ingest 端口。

3. 支撑模块（supporting modules）

api、app、debug、ngrok、pinggy、srtp、streams属于支撑性模块，不直接出现在流地址前缀中，但构成整个系统的运行骨架：

• app 模块：解析命令行参数（-c/--config配置文件、-d/--daemon守护模式、-v/--version版本查询），加载 YAML/JSON 配置并输出启动日志，见 internal/app/app.go；
• streams 模块：流命名空间管理，负责解析streams:配置、创建 Stream 对象、调度 publish/preload，见 internal/streams/streams.go；
• api 模块：对外暴露 HTTP/WebSocket API 与 WebUI；
• ngrok/pinggy：把本地流以隧道方式暴露到公网；
• srtp：SRTP 加密传输的底层支撑；
• debug：日志级别调整等运行时诊断。

三、完整模块能力矩阵

下表完整继承自 internal/README.md，列含义：

• formats：模块内部解析/生成的数据格式（-表示模块只做信令取流，数据格式随设备而定）；
• protocols：模块使用的传输协议（*表示取决于被解析出的链接）；
• input：可否作为流的输入源（取流）；
• output：可否作为流的输出端（对外提供流）；
• ingest：可否接收外部推流（如 ffmpeg 推 RTSP）；
• two-way：是否支持双向音频（backchannel）。

注：原文档中wyoming模块的引用链接误写为 wyze 目录，此处已按仓库实际目录修正为 internal/wyoming/README.md。

几个值得注意的规律：

• 能力最全的是rtsp和webrtc：两者 input/output/ingest/two-way 四项全开。以 RTSP 模块 为例，它同时提供 RTSP client（取流）、RTSP server（对外rtsp://host:8554/{stream}提供流）、ingest（ffmpeg -f rtsp rtsp://localhost:8554/camera1推流）和双向音频，配置示例见 internal/rtsp/README.md：

  streams: sonoff_camera: rtsp://rtsp:12345678@192.168.1.123/av_stream/ch0 unifi_camera: rtspx://192.168.1.123:7441/fD6ouM72bWoFijxK

• 纯输出模块：hls、mjpeg、mp4、mpeg没有 input 列标记——它们是“把已有流转换成某种格式对外吐出”的服务端模块（如mjpeg输出mpjpeg，mp4输出 HTTP/WS 的 MP4 分片）。

• 双向音频模块：doorbird、dvrip、exec、isapi、multitrans、ring、roborock、rtsp、tapo、tuya、webrtc、wyze、xiaomi。其中homekit与nest明确标no，说明这两个私有协议栈在 go2rtc 中不支持 backchannel。

• 设备私有协议集中在 webrtc 家族：nest、ring、roborock、tuya、yandex全部走srtp+webrtc，而 Wyze/小米走更底层的tutk/cs2私有传输（formats 列为-，数据格式随设备而定）。

四、能力矩阵背后的源码结构

矩阵中 input/output 两列的差异，在源码中对应 pkg/core/core.go 定义的两个核心接口：

• Producer接口（input 侧）：实现GetMedias()返回媒体描述（视频/音频方向为recvonly）、GetTrack(media, codec)获取 RTP 接收器、Start()/Stop()生命周期管理；
• Consumer接口（output 侧）：实现GetMedias()（方向为sendonly）与AddTrack(media, codec, track)接收 RTP 包。

因此矩阵中 input=yes 的模块（如 internal/rtsp、internal/wyze）其pkg/层实现都实现了 Producer 接口；output=yes 的模块（如 internal/mjpeg、internal/mp4）实现 Consumer 接口；两侧都有的模块（rtsp、webrtc、rtmp、homekit、onvif）则在pkg/目录下同时存在 client 与 server 两个实现文件，例如 pkg/rtsp/client.go 与 pkg/rtsp/server.go、pkg/rtmp/client.go 与 pkg/rtmp/server.go。

internal/ 与 pkg/ 的分层

从目录结构看，internal/下每个模块是“面向用户的接入层”：解析 URL 参数、读写配置、注册 API 路由；pkg/下对应目录是“纯协议/格式实现层”：编解码、报文解析、状态机。以 RTSP 为例，internal/rtsp/rtsp.go 负责把rtsp://...#transport=ws这类带选项的 URL 交给 pkg/rtsp 完成建连；再以 wyze 为例，internal/wyze 负责设备发现与凭据处理，pkg/wyze 实现 tutk 协议会话。

流与模块的装配发生在 internal/streams/streams.go：Init()读取streams:配置段为每个名字创建 Stream，并在 1 秒后按配置执行publish（把流发布到输出端）与preload（预取流）。当 internal/streams/streams.go 的New()校验源地址时，会调用HasProducer(source)判断该 URL 前缀是否有模块认领——这就是“矩阵 input 列”在运行时的体现：只有注册了 Producer 的模块前缀才能作为源。

媒体流的内部表示

无论外层模块用什么协议/格式，进入核心后都归一为 RTP 化的节点树：pkg/core/node.go 中Node即 Receiver/Sender/Filter 三种角色之一，通过AppendChild/RemoveChild组成树，Close()时自下而上级联关闭。编解码器常量统一定义在 pkg/core/core.go（CodecH264、CodecJPEG、CodecOpus、CodecPCMU等），payload type 以注释标明（如 JPEG=26、PCMU=0），这与矩阵中 formats 列的取值（srtp、pcm、mulaw…）一一呼应。

五、如何按矩阵选型

结合 internal/README.md 的矩阵与实际配置，常见决策路径：

1. 已知设备/协议：直接查矩阵对应行确认输入输出能力。例如 Tapo 摄像头用tapo:前缀（mpegtsoverhttp，支持双向音频）；小米设备用xiaomi:（cs2/tutk私有协议，支持双向音频）。
2. 动态/脚本化地址：用echo:或expr:先解析出真实链接，被解析结果可以带ffmpeg:、rtsp:等任意已支持前缀。
3. 需要转换格式或转码：用ffmpeg:源接入（pipe/rtsp回传，格式任意），ffmpeg 模块文档 中有完整参数说明。
4. 对外提供流：确认目标格式的 output 模块存在（rtsp、rtmp、webrtc、hls、mjpeg、mp4、mpeg、hls等），在publish:配置段声明即可，见 internal/streams/README.md。
5. 推流给 go2rtc：只挑 ingest=yes 的端点，实践中主要是 RTSP 服务（rtsp://localhost:8554/{stream}）、RTMP 与mjpeg:mpjpeg。

六、小结

internal/README.md 用一张能力矩阵把 go2rtc 的几十个模块收敛到统一的分析框架中：模块负责“怎么连上设备”，格式描述“数据长什么样”，协议决定“数据走哪条路”，而 input/output/ingest/two-way 四列则精确界定了每个模块在流媒体管道中的位置。配合 pkg/core 的 Producer/Consumer 接口与 Node 树实现，这张矩阵不仅是文档，更是对代码结构的直接映射——读懂它，就拿到了 go2rtc 扩展与选型能力的总地图。

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