LiveForge：单二进制的多协议流媒体服务器，音频转码用 build tag 开关
项目信息
- 仓库：https://github.com/im-pingo/liveforge
- 中文 README：https://github.com/im-pingo/liveforge/blob/main/README.zh-CN.md
- Wiki：https://github.com/im-pingo/liveforge/wiki
- 许可证：MIT，Go 1.26+
构建形态：默认不碰 FFmpeg
LiveForge 是一个 Go 写的多协议流媒体服务器，编译产物是单个二进制。默认构建不依赖 FFmpeg，也不开 CGO；只有需要音频转码时才走带 tag 的构建：
go build -tags audiocodec # 需要系统安装 FFmpeg / libav 开发库 + CGO
配置按模块分节，覆盖 rtmp、rtsp、http_stream、webrtc、srt、sip、gb28181、audio_codec、api、auth、record、notify、cluster、metrics、limits、tls、stream。默认监听端口：
| 服务 | 端口 |
|---|---|
| RTMP | 1935 |
| RTSP | 8554 |
| HTTP（HLS/LL-HLS/DASH/HTTP-FLV/WebSocket） | 8080 |
| WebRTC | 8443 |
| SRT | 6000 |
| SIP（GB28181） | 5060 |
| API / Web Console | 8090 |
| Metrics | 9090 |
协议矩阵
推流接入侧支持 RTMP、RTSP（TCP + UDP）、SRT、WebRTC WHIP、GB28181。拉流侧支持 RTMP、RTSP、SRT、WebRTC WHEP、HLS、LL-HLS、DASH、HTTP-FLV、HTTP-TS、FMP4、WebSocket。
编解码覆盖 H.264、H.265/HEVC、VP8、VP9、AV1、AAC、Opus、G.711（μ-law/A-law）、MP3。
SRT 走纯 Go 实现（datarhei/gosrt），支持 AES 加密，承载低延迟 MPEG-TS。WebRTC 提供 WHIP/WHEP，SDP offer 上限 1 MiB，启用 ICE Lite，带 GCC 发送侧带宽估计，可以直接从浏览器推流。
任意到任意桥接
协议之间不是各自孤立的入口和出口，任意组合都能对接：RTMP 推流、WebRTC 播放，或者 WebRTC 推流、HLS 播放，不需要为每种组合单独配置。这一点在生产上省掉的是「网关链」——不用再拿别的进程在中间转一次容器格式。
LL-HLS 和普通 HLS 的差别
普通 HLS 靠固定时长的完整分片堆积延迟，LL-HLS 把这套流程拆细：
- fMP4 partial segment，默认 200ms；
- blocking playlist reload，用
_HLS_msn/_HLS_part让客户端请求阻塞到新分片就绪，而不是轮询； - delta playlist，
_HLS_skip=YES只下发增量； - 保留 TS 回退路径，旧播放器自动降级。
Console 播放 HLS 时会先等 0.8s 连续缓冲再启动，目标直播延迟 1.5s。如果请求等不到完整分片，服务端返回 503，而不是吐一份只含 part 的 manifest。
音频转码为什么需要 audiocodec tag + CGO + FFmpeg
AAC、Opus、G.711、MP3 之间的转换没有纯 Go 的现实路径，所以这部分被显式隔离在 audiocodec build tag 后面，依赖 CGO 调 FFmpeg/libav。转码按需触发，自动桥接 AAC↔Opus↔G.711↔MP3；同一个目标编解码器共享一条转码管线，发布者编码与订阅者编码一致时直接直通，零转码开销。典型链路：
- RTMP(AAC) → WebRTC(Opus)
- WebRTC(Opus) → RTMP(AAC)
- GB28181(G.711) → HLS(AAC)
不带 CGO 的便携构建保留兼容音频直通；遇到不支持的组合时可能丢弃音频，但视频仍可播放。Console 报「音频转码不可用」时，WebRTC 只请求视频轨；外部 WHEP 客户端请求不支持的音频格式会收到 HTTP 415。
GB28181 国标接入
面向视频监控场景，实现了完整 SIP 信令栈：设备注册、心跳、digest 鉴权、目录查询、实时 INVITE 邀约、录像回放、PTZ 云台控制、报警处理，以及 RTP/PS 的 MPEG-PS 解复用（H.264 + AAC）。信令之外暴露 REST API：/api/v1/gb28181/*。
调试可以起内置设备模拟器，走完 REGISTER → keepalive → 目录 → RTP/PS 推流 → BYE 全流程：
go run ./tools/gb28181-sim -server 127.0.0.1:5060 -fps 25
集群拓扑
集群模式做多协议转发加按需回源，中继协议涵盖 RTMP、SRT、RTSP、RTP、GB28181；目标地址由 HTTP scheduler 动态解析。拓扑支持 origin-edge、origin-multi-edge、origin-center-edge 三级结构，重试次数、重试间隔和退避策略都可配。
运维侧能力
- Web Console：7 个权限化 tab（Streams / GB28181 / Config / Cluster / SIP Calls / Storage / Security），另带
/console/publish广播工作区。 - REST API 与 RBAC：viewer / operator / admin 三档 token，推拉流鉴权支持 JWT 或 callback，附带审计日志。
- 录制 / DVR：FLV、fMP4、MP4、TS、HLS，默认 fMP4。
- 通知：HTTP webhook（HMAC-SHA256 签名）+ WebSocket。
- Prometheus 指标：per-stream 标签 opt-in，配 allowlist 做基数预算。
- 限流与保护：按 IP 令牌桶，trusted proxy 从右到左解析，防 XFF 伪造；慢消费者用 EWMA 做帧丢弃；WebRTC 侧有 GCC 拥塞控制。
与 MediaMTX / SRS / Monibuca 对照
| 能力 | LiveForge | MediaMTX | SRS | Monibuca |
|---|---|---|---|---|
| 语言 | Go | Go | C++ | Go |
| LL-HLS | 支持（fMP4 + blocking reload） | 不支持 | 支持 | 不支持 |
| HTTP-FLV | 支持 | 不支持 | 支持 | — |
| FMP4 streaming | 支持 | — | — | — |
| GB28181 | 完整支持 | — | — | — |
| 浏览器 WHIP 推流 | 支持 | — | — | — |
| ICE Lite | 支持 | — | — | — |
| GCC 拥塞控制 | 支持 | — | — | — |
| 单二进制 | 是 | 是 | 是 | 否 |
| 许可证 | MIT | MIT | MIT | MIT |
取舍上比较直白：如果只需要基础的 RTSP/RTMP 转发、想要极简配置，MediaMTX 更轻；要 HTTP-FLV、成熟社区和大量生产案例，SRS 更稳；想在 Go 里做二次开发和插件式扩展，Monibuca 是纯 Go 路线。LiveForge 的差异点在 LL-HLS、FMP4 streaming、GB28181、浏览器 WHIP 推流、ICE Lite 和 GCC 这几项上，代价是音频转码引入 FFmpeg 依赖，默认构建则完全不带。
相关同题材项目
- MediaMTX：https://github.com/bluenviron/mediamtx （Go）
- SRS：https://github.com/ossrs/srs （C++）
- Monibuca：https://github.com/langhuihui/monibuca （纯 Go）
- ZLMediaKit：https://github.com/ZLMediaKit/ZLMediaKit （C++，StreamUI 基于它做管理 UI）