go2rtc 媒体格式 / 协议 / 编解码器全览Producers、Consumers 与 Snapshots 支持矩阵【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtcgo2rtcUltimate camera streaming application是一个以 Go 编写的流媒体应用其pkg/目录承载着全部媒体格式与协议的编解码实现。本文基于 pkg/README.md 的核心命名约定与三张支持矩阵输入 Producers、输出 Consumers、快照 Snapshots结合main.go、internal/README.md、pkg/core/core.go等源码系统梳理 go2rtc 对音视频格式、传输协议与编解码器的完整支持面帮助你快速判断某一路流应该用什么格式接入、用哪个 API 输出以及如何在 go2rtc 中新增一种自定义格式。命名约定向 FFmpeg 看齐兼容其术语体系go2rtc 在设计上刻意让格式format、协议protocol与编解码器codec的命名方式与 FFmpeg 保持一致go2rtc tries to name formats, protocols and codecs the same way they are named in FFmpeg. Some formats and protocols go2rtc supports exclusively. They have no equivalent in FFmpeg.这一约定带来的直接收益是熟悉 FFmpeg 的用户几乎不需要学习成本就能读懂 go2rtc 的配置与 API。例如rtsp:、rtmp:、hls、adts、mpegts、pcm_alaw、pcm_mulaw等术语在 FFmpeg 生态中含义相同。同时 go2rtc 也有一些 FFmpeg 没有的独占格式与协议如bubble:、doorbird:、eseecloud:等私有云/私有设备协议它们会在下文各矩阵中体现。Producers输入四大角色与全量支持矩阵在 go2rtc 的输入侧连接发起方与数据流向决定了模块的角色Source protocols源协议连接由 go2rtc 主动发起即 go2rtc 作为客户端去拉取远端流Ingress protocols入站协议连接由外部程序发起go2rtc 作为服务端接收外部推流对应内部架构中的 ingest 能力Receiver codecs接收编解码器编解码器是进来的即 go2rtc 接收并解码该编码的媒体Sender codecs发送编解码器编解码器是出去的即 go2rtc 向外发送该编码的媒体用于双向音频two-way audio等场景。Producers 完整矩阵GroupFormatProtocolsIngressReceiver codecsSender codecsExampleDevicesalsapipepcmalsa:Devicesv4l2pipev4l2:Filesadtshttp, tcp, pipehttpaachttp:Filesflvhttp, tcp, pipehttph264, aachttp:Filesh264http, tcp, pipehttph264http:Fileshevchttp, tcp, pipehttphevchttp:Fileshlshttph264, h265, aac, opushttp:Filesmjpeghttp, tcp, pipehttpmjpeghttp:Filesmpegtshttp, tcp, pipehttph264, hevc, aac, opushttp:Fileswavhttp, tcp, pipehttppcm_alaw, pcm_mulawhttp:Net (pub)mpjpeghttp, tcp, pipehttpmjpeghttp:Net (pub)onvifrtsponvif:Net (pub)rtmprtmprtmph264, aacrtmp:Net (pub)rtsprtsp, wsrtsph264, hevc, aac, pcm*, opuspcm*, opusrtsp:Net (pub)webrtc*webrtcwebrtch264, pcm_alaw, pcm_mulaw, opuspcm_alaw, pcm_mulawwebrtc:Net (pub)yuv4mpegpipehttp, tcp, pipehttprawvideohttp:Net (priv)bubblehttph264, hevc, pcm_alawbubble:Net (priv)doorbirdhttpdoorbird:Net (priv)dvriptcph264, hevc, pcm_alaw, pcm_mulawpcm_alawdvrip:Net (priv)eseecloudhttpeseecloud:Net (priv)goproudpTODOgopro:Net (priv)hasswebrtcTODOhass:Net (priv)homekithaph264, eld*homekit:Net (priv)isapihttppcm_alaw, pcm_mulawisapi:Net (priv)kasahttph264, pcm_mulawkasa:Net (priv)nestrtsp, webrtcTODOnest:Net (priv)ringwebrtcring:Net (priv)roborockwebrtch264, opusopusroborock:Net (priv)tapohttph264, pcmapcm_alawtapo:Net (priv)tuyawebrtctuya:Net (priv)vigihttpvigi:Net (priv)webtorrentwebrtcTODOTODOTODOwebtorrent:Net (priv)xiaomi*cs2, tutkxiaomi:Servicesflussonicwsflussonic:Servicesivideonwsh264ivideon:Servicesyandexwebrtcyandex:Otherecho*echo:Otherexecpipe, rtspexec:Otherexpr*expr:Otherffmpegpipe, rtspffmpeg:Otherstdinpipepcm_alaw, pcm_mulawstdin:矩阵注释Codec 组定义eldaac 编解码器的罕见变体AAC-ELD常见于 HomeKit 视频门铃/对讲场景见 pkg/core/core.go 中的CodecELD ELD定义pcm指pcm_alaw、pcm_mulaw、pcm_s16be、pcm_s16le四种 PCM 变体webrtc指 WebRTC 在 go2rtc 中的一系列专有客户端变体webrtc/kinesis、webrtc/openipc、webrtc/milestone、webrtc/wyze、webrtc/whep。从源码看 Producers 的角色划分矩阵中四类角色的划分并非文档发明而是直接体现在核心接口上。pkg/core/core.go 定义了Producer接口type Producer interface { // GetMedias - return Media(s) with local Media.Direction: // - recvonly for Producer Video/Audio // - sendonly for Producer backchannel GetMedias() []*Media // GetTrack - return Receiver, that can only produce rtp.Packet(s) GetTrack(media *Media, codec *Codec) (*Receiver, error) // Deprecated: rename to Run() Start() error // Deprecated: rename to Close() Stop() error }注释清楚地说明了双向音频backchannel在实现上的落点普通 Producer 的 Media 方向是recvonly接收远端视频/音频而回传通道Sender codecs的 Media 方向是sendonly。以 RTSP 为例pkg/rtsp/producer.go 中的GetTrack在core.ModeActiveProducergo2rtc 主动拉流与core.ModePassiveConsumerbackchannel 回传两种模式下分别分配 RTP 通道正是矩阵中rtsp同时具备 Receiver codecsh264、hevc、aac、pcm*、opus与 Sender codecspcm*、opus的实现依据。另外注意 Devices 分组alsa与v4l2都使用pipe协议本地设备走管道其中alsa同时具备pcm的 Sender codecs说明 go2rtc 支持通过 ALSA 设备进行音频采集与回放双向音频对应实现位于 pkg/alsa 与 internal/alsa。Consumers输出格式、协议与 API 端点输出侧Consumers矩阵列出了 go2rtc 对外提供流服务的所有方式其中 Send codecs 是 go2rtc 向客户端发送的编码Recv codecs 是 go2rtc 从客户端接收的编码同样服务于双向音频等场景FormatProtocolSend codecsRecv codecsExampleadtshttpaacGET /api/stream.adtsasciihttpmjpegGET /api/stream.asciiflvhttph264, aacGET /api/stream.flvhls/mpegtshttph264, hevc, aacGET /api/stream.m3u8hls/fmp4httph264, hevc, aac, pcm*, opusGET /api/stream.m3u8?mp4homekithaph264, opusApple HomeKit appmjpegwsmjpeg{type:mjpeg}-/api/wsmpjpeghttpmjpegGET /api/stream.mjpegmp4httph264, hevc, aac, pcm*, opusGET /api/stream.mp4mse/fmp4wsh264, hevc, aac, pcm*, opus{type:mse}-/api/wsmpegtshttph264, hevc, aacGET /api/stream.tsrtmprtmph264, aacrtmp://localhost:1935/{stream_name}rtsprtsph264, hevc, aac, pcm*, opusrtsp://localhost:8554/{stream_name}webrtcwebrtch264, pcm_alaw, pcm_mulaw, opuspcm_alaw, pcm_mulaw, opus{type:webrtc}-/api/wsyuv4mpegpipehttprawvideoGET /api/stream.y4m其中pcm同样指pcm_alaw、pcm_mulaw、pcm_s16be、pcm_s16le。输出侧的三个观察点HTTP API 是主输出通道绝大多数输出格式通过 HTTP REST 端点暴露形式统一为GET /api/stream.{format}由 internal/api/api.go 与各输出模块internal/hls、internal/mp4、internal/mjpeg、internal/mpeg 等共同实现前端 Web UI 中的播放器www 目录正是通过这些端点拉流。WebSocket 通道承载交互式协议mjpeg、mse/fmp4、webrtc三种输出都通过{type:...}的 JSON 消息路由到/api/ws由 internal/api/ws/ws.go 统一处理其中webrtc是唯一同时具备 Recv codecs 的输出格式支持pcm_alaw、pcm_mulaw、opus回传即浏览器端经 WebRTC 实现双向音频。RTSP/RTMP 同时是输入与输出rtsp://localhost:8554/{stream_name}与rtmp://localhost:1935/{stream_name}既可被 go2rtc 拉取Source也可由 go2rtc 对外分发输出对应 internal/rtsp 与 internal/rtmp 中 server 与 client 的双重实现。Snapshots快照单帧抓取接口go2rtc 还提供两种轻量级快照端点适合门禁联动、缩略图、定时抓帧等场景FormatProtocolSend codecsExamplejpeghttpmjpegGET /api/frame.jpegmp4httph264,hevcGET /api/frame.mp4GET /api/frame.jpeg以 MJPEG 编码输出一帧 JPEG 图片GET /api/frame.mp4输出一小段 MP4 视频h264/hevc 编码通常作为几秒短视频快照使用。两者均由 internal/mjpeg / internal/mp4 模块承载与 Web UI 的实时预览共用同一套流媒体管线。Developers如何新增一种格式源码结构约定对于想在 go2rtc 中接入新设备/新格式的开发者pkg/README.md给出了清晰的文件命名规范File namingpkg/{format}/producer.go—— 该格式的 producer 实现若支持 backchannelbackchannel 能力也在此文件内pkg/{format}/consumer.go—— 该格式的 consumer 实现pkg/{format}/backchannel.go—— 仅含 backchannel 功能的 producer。这与实际仓库结构完全吻合例如 RTSP 模块 pkg/rtsp 下同时存在producer.go、consumer.go、helpers.go而仅做回传通道的模块如 pkg/doorbird/backchannel.go、pkg/tapo/backchannel.go、pkg/xiaomi/miss/backchannel.go 则遵循backchannel.go的独立命名约定。新增模块时需要同步提及的位置Mentioning modules文档明确列出新增/修改一个模块时需要同步更新以下文件中与该模块相关的注册或引用信息main.go —— 模块的Init注册列表源码中以modules : []module{...}的形式按分组顺序执行初始化例如 HTTP/RTSP/WebRTC 作为 Main sources 最先注册硬件源与私有云源随后注册README.md —— 项目主文档中的功能说明internal/README.md —— 模块-格式-协议对照总表该表进一步把模块细分为 Modules 实现通信 API、Formats 描述数据结构、Protocols 实现传输并在 internal/README.md 中列出每个模块的 formats、protocols、input/output/ingest/two-way 能力website/.vitepress/config.js —— 文档站点的侧边栏导航注意该配置中srcDir: ..且srcExclude: [examples/, pkg/]即文档站点从仓库根目录构建但pkg/目录被排除在站点之外属于内部实现层website/api/openapi.yaml —— API 的 OpenAPI 描述文件www/schema.json —— 前端 Web UI 的配置 schema。其中 main.go 的模块注册顺序值得一提它先初始化app配置与日志、api与wsAPI 端点、streams流管理核心然后是 Main sources and servershttp、rtsp、webrtc再是 Main APImp4、hls、mjpeg最后是各类脚本源、硬件源与私有云源。新增格式若需要服务端能力如监听端口必须参考这一顺序在合适的位置注册Init。总结pkg/README.md本质上是一张 go2rtc 的能力全景图输入侧按 Devices / Files / Net (pub) / Net (priv) / Services / Other 六个分组输出侧按 Format-Protocol-API 三元组加上 JPEG/MP4 快照端点共同构成了完整的媒体接入与分发体系。搭配 pkg/core/core.go 的Producer/Consumer接口、main.go 的模块注册顺序以及 internal/README.md 的模块能力总表你可以快速判断某路摄像头RTSP/ONVIF/私有云该用哪个xxx:前缀接入浏览器、播放器、Home Assistant 等下游分别该走哪个/api/stream.*端点双向往来双向音频、语音回传依赖哪些 Sender/Recv codecs新协议接入时该在pkg/下如何组织producer.go/consumer.go/backchannel.go文件以及需要同步修改哪些注册与文档文件。【免费下载链接】go2rtcUltimate camera streaming application项目地址: https://gitcode.com/GitHub_Trending/go/go2rtc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考