Restreamer 介绍与选型指南

‍‍​​‌​> 目标：说清 Restreamer 是什么、能做什么、什么时候该选它——基于 Restreamer 2.12.0 在 Ubuntu 24.04 x86_64 服务器上的完整实测（RTMP 推流入站、HLS 分发拉流、REST API 全套调用均已跑通），身份与版本事实溯源自官方仓库与文档站。

一、环境信息

本文所有结论均在以下真实环境实测或溯源得到（实测与查询日期 2026-10-30）：

• 操作系统：Ubuntu 24.04 LTS（x86_64）
• Restreamer：2.12.0（官方发行渠道 datarhei/restreamer:2.12.0，GitHub Releases 实查为当前最新稳定版）
• 内核组件版本（实测 GET /api 回显）：datarhei-core 16.16.0（commit 6872ba0，构建日期 2024-06-07，Go 1.22.4 编译，linux/amd64）
• 服务端口（实测监听）：HTTP 8080（Web 界面 + REST API + HLS 分发）、HTTPS 8181（TLS，默认未启用）、RTMP 1935、RTMPS 1936、SRT 6000/UDP
• 推拉流工具：FFmpeg 6.1.1（含 libx264、libsrt）
• 全流程一键化部署方案见[《Restreamer 2.12.0 Docker Compose 部署指南》](https://www.quzuo.net/document/3IVvGXTSwFYs)，配置项逐项拆解见[[《Restreamer 2.12.0 配置参数详解》](https://www.quzuo.net/document/u6Yi2xGp3c4T)](https://www.quzuo.net/document/u6Yi2xGp3c4T)，自动化管理见[[《Restreamer 2.12.0 API 使用详解》](https://www.quzuo.net/document/DAWPhSW0QKsb)](https://www.quzuo.net/document/DAWPhSW0QKsb)

二、软件概述

本节交代 Restreamer 的身份、许可与版本脉络，回答「它从哪来、现在由谁维护」。

Restreamer（仓库 datarhei/restreamer，由德国 datarhei 公司主导维护）是一个面向网站直播与多平台转推的开源流媒体服务器：它把「一路直播流的接入 → 服务端处理 → 网站播放器分发 → 转推到 YouTube-Live/Twitch/Vimeo 等外部平台」做成一个带图形向导的一体化服务。与 MediaMTX 这类「纯转发、不转码」的极简枢纽不同，Restreamer 内嵌完整 FFmpeg 处理能力，服务端可以直接转码、叠加滤镜、混音，官方把它定位为「A really nice and free alternative for handling live streams（处理直播流的免费好选择）」。

关键事实（均经实测或官方仓库核验，查询日期 2026-10-30）：

• 许可证：Apache-2.0（仓库 License 徽章与 datarhei/core 源码包内 LICENSE 文件均为 Apache License 2.0），可商用、可二次分发
• 社区规模：GitHub 实查 5.2k Stars、566 Forks（2026-10-30）；另有官方在线演示站 demo.datarhei.com（用户名 admin、密码 demo）
• 版本节奏：GitHub Releases 实查（2026-10-30），最新稳定版 2.12.0（2024-09-13 发布）；前一版 2.11.0（2024-06-07，内核升级 core v16.16.0）。2.x 系列约每季度一个版本，更新频率低于 MediaMTX，但单版改动以界面与目标适配为主、内核稳定
• 发行渠道：官方仅以 Docker 打包分发（无裸机二进制下载），并提供 4 个官方变体——标准版（AMD64/ARM64/ARMv7）、rpi-（树莓派 OMX/V4L2-M2M 硬件编码）、cuda-（Nvidia CUDA 11.4）、vaapi-（Intel VAAPI 硬件编码），2026-10-30 实查自 GitHub Releases 发布说明
• 运行身份：单进程 ./bin/core 常驻（实测进程列表 PID 1），推流处理由其按需拉起 FFmpeg 子进程完成（实测 ps 回显子进程命令行为 -i rtmp://localhost:1935/live/test.stream -c copy -f hls ...）

💡 技术拓展：「自托管流媒体服务器」不止 Restreamer 一家，按「是否转码 + 是否带图形界面 + 协议广度」三个维度，常见选择对比——

项目	服务端转码	图形界面	协议广度	许可
Restreamer	✅ 内嵌 FFmpeg	✅ 完整向导式 Web UI	RTMP/SRT/HLS 入，HLS/RTMP/SRT 出	Apache-2.0
MediaMTX	❌ 纯转发（可外挂钩子）	❌ 无	RTSP/RTMP/SRT/HLS/WebRTC/MoQ 六协议互转	MIT
OvenMediaEngine	✅ 内置转码	✅ Web 控制台	RTMP/SRT/RTSP 入，HLS/LL-HLS/WebRTC 出	AGPL-3.0

三者都开箱即用，本文第七章给出逐维度量化对比。

三、核心架构

本节拆解 Restreamer 的内部组成与数据通路，帮助理解后面部署与配置时每个部件所处的位置。

3.1 三件套打包：core + 定制 FFmpeg + React 界面

Restreamer 2.x 由三个上游项目打包成一个发行版（官方仓库 README「Development」节明确这一分层，查询日期 2026-10-30）：

三个组件的耦合方式是：UI 与用户交互后调用 core 的 REST API；core 把每条「输入→输出」流水线翻译成一条 FFmpeg 命令并管理其生命周期；FFmpeg 子进程把进度/日志以 JSON 回传给 core 供界面展示。实测确认了这一分层：服务内只驻留一个 core 主进程，推流发生时才出现 FFmpeg 子进程，且其命令行参数与界面上配置的流水线逐字对应。

这个设计的选型含义是：Restreamer 的能力上限 = FFmpeg 的能力上限。FFmpeg 能做的（转码、滤镜、混音、拉多源）它都能配；FFmpeg 不涉及的（WebRTC 分发、GB28181 接入）它就不具备。

3.2 进程（process）模型：一切皆输入→输出流水线

core 把所有流处理抽象为 process 对象：一个 process 由「1 个输入 + N 个输出 + FFmpeg 选项」构成，配置为 JSON（实测 GET /api/v3/process 回显节选）：

{"id":"live","type":"ffmpeg",
 "input":[{"id":"input_0","address":"rtmp://localhost:1935/live/test.stream","options":[]}],
 "output":[{"id":"output_0","address":"{memfs}/live.m3u8","options":["-map","0:v","-map","0:a","-c","copy","-f","hls","-start_number","0","-hls_time","2","-hls_list_size","6","-hls_flags","append_list+delete_segments"]}],
 "reconnect":true,"reconnect_delay_seconds":5,"autostart":true}

逐项解读：id 是流水线唯一名；input/output 是 FFmpeg 的输入输出地址（{memfs} 是 core 的内存文件系统占位符）；reconnect + reconnect_delay_seconds 控制断流自动重连间隔；autostart 表示服务启动即拉起。实测验证：外部 FFmpeg 向 RTMP 入口推流后，core 自动创建了上述 live 流水线并进入 running 状态——入站推流不需要手工建流水线，这是与 MediaMTX path 模型最直观的差异（MediaMTX 的 path 是静态声明式，Restreamer 的 process 是运行时对象、可用 API 增删）。该流水线实际拉起的子进程（实测 ps 回显）为：

/usr/bin/ffmpeg -i rtmp://localhost:1935/live/test.stream -map 0:v -map 0:a -c copy -f hls \
  -start_number 0 -hls_time 2 -hls_list_size 6 -hls_flags append_list+delete_segments \
  -hls_segment_filename http://…/memfs/live_%04d.ts -y -method PUT http://…

与流水线配置逐字对应（切片文件名与写回地址由内核自动生成并注入存储凭据）。

3.3 内存文件系统 memfs 与会话令牌分发

core 内置一块内存文件系统（memfs），HLS 切片、播放器页面、录像快照都先写入这里，再按需同步到磁盘目录（默认 /core/data）。实测拉流路径为：

# 主清单（HTTP 8080 端口，实测 200）
GET /memfs/live.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=1024
live.m3u8?session=b5zHwVy8tFUBh84EgwU54v（实测回显节选）

逐行解读：主清单只含一条变体地址，并附带 session= 令牌——memfs 的读访问由「会话令牌」鉴权，播放器拿到带令牌的媒体清单后即可顺序拉取 live_0760.ts 等分片（实测分片约 82 KB，FFmpeg 解码确认为 H264 640×360 + AAC 44.1kHz）。这套令牌机制让「把播放页直接挂到你自己网站」不需要反向代理鉴权，是 Restreamer 面向「嵌播放器到自己网站」场景的针对性设计。

💡 技术拓展：流媒体服务器的「分发缓冲」有两条路线——内存缓冲与磁盘缓冲。内存缓冲（Restreamer memfs、MediaMTX 内存流）延迟低、重启即清空，适合直播；磁盘缓冲（Nginx-RTMP 录制后点播）可回放但占 IO。Restreamer 两者都提供（memfs 默认 + 磁盘目录可选同步），本方案实测采用默认 memfs 直播模式。

四、功能特性

本节按官方宣称清单逐项给出实测或实查确认，避免「宣传≠实际」的落差。

4.1 协议矩阵（实测）

实测环境完整跑通的链路（推流端 FFmpeg 6.1.1 → Restreamer 2.12.0）：

与竞品的差异一目了然：Restreamer 的入站主打「编码器/OBS 推 RTMP」，没有 RTSP 摄像机直接接入（需先用 FFmpeg/相机固件转 RTMP）——这是它相对 MediaMTX/OvenMediaEngine 最主要的协议短板。

4.2 配套能力（实测确认）

• 向导式 Web 界面：首次访问 http://<服务器>:8080 即进入安装向导，实测可全程图形化完成管理员创建与首个直播流配置（实测回显界面 HTTP 200，UI 资源目录 /core/ui 实测存在完整 React 构建产物）
• REST API（JSON）：官方宣称 100% Swagger 文档化（上游仓库 swagger.json 共 38 条路径）；注意 2.12.0 打包的 core 16.16.0 实测未内置 Swagger 页面（/api/swagger 404），且实际路由集小于上游文档——实测可用路由清单与版本差异逐条列于[《Restreamer 2.12.0 API 使用详解》](https://www.quzuo.net/document/DAWPhSW0QKsb)第三章，另实测自带 GraphQL 查询端点（/api/graph/query）
• 指标：GET /api/v3/metrics 返回指标目录（实测确认）；该打包版本实测无 Prometheus 抓取端点（/metrics 404），按官方文档预期该能力需更新内核版本
• HTTPS 与证书：支持配置文件指定证书或 Let's Encrypt 自动签发（HTTPS 监听 8181，默认关闭，实测 tls.enable=false）
• 多平台转推目标：界面内置 YouTube-Live、Twitch、Vimeo 等目标模板（实查自官方文档站与 UI 源码仓库说明），也接受任意自定义 RTMP/SRT 地址
• 硬件编码：官方 4 个发行变体分别适配树莓派 OMX/V4L2、Nvidia CUDA、Intel VAAPI（查询日期 2026-10-30，自 GitHub Releases 发布说明）

五、快速开始（最小可用示例）

本节给出从零到「推一路流、网页能看」的最短路径，全部命令与回显实测于本章第一节环境。完整的生产化部署（数据持久化、HTTPS、环境变量表）见《Restreamer 2.12.0 Docker Compose 部署指南》。

5.1 一条命令拉起服务

Restreamer 官方唯一发行形态是 Docker 打包，官方 README 给出的最小启动命令如下（查询日期 2026-10-30，/opt/restreamer 为配置与数据目录）：

docker run -d --restart=always --name restreamer \
   -v /opt/restreamer/config:/core/config -v /opt/restreamer/data:/core/data \
   -p 8080:8080 -p 8181:8181 \
   -p 1935:1935 -p 1936:1936 \
   -p 6000:6000/udp \
   datarhei/restreamer:latest

参数解读：两个 -v 把配置目录与数据目录持久化到宿主机（升级重建不丢配置）；8080 是 Web 界面 + API + HLS 的总入口，1935/1936 是 RTMP(S) 入站，6000/udp 是 SRT 入站。首次启动后浏览器访问 http://<服务器>:8080 按向导创建管理员账号即可进入主界面。

验证服务就绪（实测回显）：

curl http://127.0.0.1:8080/ping

pong

5.2 推一路流进站（实测）

用 FFmpeg 推一路测试流（testsrc 彩条 + 440Hz 正弦音）到 RTMP 入口（若宿主 1935 已被占用，映射到高位端口后用映射端口，本文实测为 19355）：

ffmpeg -re -f lavfi -i testsrc=size=640x360:rate=25 -f lavfi -i sine=frequency=440:sample_rate=44100 \
  -c:v libx264 -preset ultrafast -tune zerolatency -pix_fmt yuv420p -g 50 \
  -c:a aac -b:a 64k -f flv rtmp://127.0.0.1:19355/live/test.stream

推流建立后，Restreamer 自动创建名为 live 的流水线，Web 界面的直播管理页随即显示该流在线。用 API 核实（实测回显节选）：

curl http://127.0.0.1:8080/api/v3/process/live/state

{"order":"start","exec":"running","runtime_seconds":1532,
 "progress":{"inputs":[{"address":"rtmp://localhost:1935/live/test.stream","fps":24.267}]}}

逐项解读：exec: running 即入站流在线；progress.inputs 持续回报推流帧率，runtime_seconds 为流水线已运行秒数——这两项就是巡检「流是否还活着」的判据。

5.3 拉流取证：HLS 播放（实测）

浏览器直接打开 http://<服务器>:8080 的直播页，或用播放器/FFmpeg 拉取 HLS 分发地址 http://<服务器>:8080/memfs/live.m3u8。命令行验证清单可达（实测回显节选）：

curl http://127.0.0.1:8080/memfs/live.m3u8

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:760
#EXTINF:2.000000,
live_0760.ts?session=mQ4a33oyx46FXCHCnKBg5z

逐行解读：EXT-X-TARGETDURATION:2 表示分片 2 秒（即约 2 秒级延迟的直播）；每个分片带 session 令牌；媒体序列号持续前移即直播进行中。至此「推流 → 服务端 → 网页观看」的最小闭环走通。

六、适用场景与限制

本节把能力边界说透，避免选型后才发现缺口。

6.1 适用场景

• 个人/小团队网站直播：官方定位主场景——一路（或几路）直播源接入，网页播放器嵌入自己网站，同时转推 YouTube/Twitch 等平台。向导式界面让非运维人员也能完成日常开播。
• 单路流的服务端加工再分发：需要转码、混音、加滤镜、多码率输出，但规模只有个位数流——FFmpeg 能力全部可用，而不必自己写 FFmpeg 命令。
• 低运维预算的常驻转推节点：进程模型自带断流自动重连（实测 failed 后按 reconnect_delay_seconds 循环重试），适合放一台便宜 VPS 上做 7×24 转推。
• Raspberry Pi/单板机直播盒：官方 rpi- 变体针对树莓派硬件编码优化，配合摄像头即可做便携直播终端（实查自官方发行说明）。

6.2 限制（选型前必读）

• 无原生二进制发行：只能以 Docker 打包部署，裸机/无法用 Docker 的环境需自行从源码构建（官方 README 提供三仓库分别构建的说明），运维成本高于 MediaMTX 的单二进制。
• 不支持 RTSP 直接接入：IP 摄像机接入需外挂转换（用 FFmpeg 把 RTSP 转 RTMP 再推进站），MediaMTX/OvenMediaEngine 均原生支持 RTSP。
• 不内置 WebRTC 分发：浏览器亚秒级观看需另选 OvenMediaEngine（LL-HLS/WebRTC 原生支持）或 MediaMTX（WebRTC/WHEP）。
• 集群能力缺失：单进程单机架构，无内置集群/多节点水平扩展方案；大规模并发分发需前面挂 CDN 或换分布式方案。
• 版本迭代放缓：最新版 2.12.0 发布于 2024-09-13（查询日期 2026-10-30），近年更新以维护为主，选型时应接受「稳定但缓慢」的节奏。
• 资源占用高于纯转发服务器：内嵌 FFmpeg 与 React 界面，空载内存显著高于 MediaMTX 的约 26 MiB 量级（MediaMTX 实测口径，见其专栏介绍篇），建议按 1 GB 以上内存规划单节点。

七、同类选型对比

本节把 Restreamer 与两个最常被一起考虑的开源流媒体服务器做量化对比。竞品版本口径：MediaMTX v1.21.3（其官方 Releases 2026-10-25 发布，实查自该专栏介绍篇，查询日期 2026-10-29）；OvenMediaEngine 0.21.0（平台专栏同版本系列文档口径）。许可证三项均为各仓库 LICENSE 文件/徽章实查（查询日期 2026-10-30）。

关键差异解读：Restreamer 是三者中唯一「向导式图形界面 + 服务端转码 + 转推目标模板」三合一的，代价是协议广度（无 RTSP 入站、无 WebRTC 出站）与发行形态（仅 Docker）；MediaMTX 以协议互转与极轻资源取胜但没有界面、不转码；OvenMediaEngine 在大规模低延迟分发（LL-HLS/WebRTC 集群）上最强，但概念与资源成本最高。

如何选型（一句话版）：

• 要给网站加直播/转推主流平台、希望图形化管理、需要服务端转码 → Restreamer（本文实测其向导与 RTMP→HLS 闭环最顺滑）；
• 要多协议枢纽、RTSP 摄像机接入、极低资源 → MediaMTX（见《MediaMTX 1.21.3 介绍与选型指南》）；
• 要大规模低延迟分发、WebRTC/ABR 转码集群 → OvenMediaEngine（见《OvenMediaEngine 介绍与选型指南》）；
• 三者组合亦有实践：Restreamer 做采集/转推边缘，MediaMTX/OvenMediaEngine 做分发枢纽。

选定 Restreamer 后的落地路径：一键化部署见《Restreamer 2.12.0 Docker Compose 部署指南》，全部配置参数见《Restreamer 2.12.0 配置参数详解》，自动化运维与集成见《Restreamer 2.12.0 API 使用详解》。

八、参考链接

• 官方仓库（源码、README、Releases）：https://github.com/datarhei/restreamer
• 官方文档站（快速开始/手册/用户指南）：https://docs.datarhei.com/restreamer
• 在线演示站（用户名 admin / 密码 demo）：https://demo.datarhei.com/ui
• 内核仓库 datarhei/core（API 与配置的权威定义）：https://github.com/datarhei/core
• 2.12.0 发布说明（发行变体与变更清单，查询日期 2026-10-30）：https://github.com/datarhei/restreamer/releases/tag/v2.12.0
• 本平台对照篇目：《MediaMTX 1.21.3 介绍与选型指南》、《OvenMediaEngine 介绍与选型指南》