MiBeeNvr v0.2.0 更新:Docker 部署、HLS 直播、录像合并,以及一份完整的安装指南
上一篇文章介绍了 MiBeeNvr 的基本功能和设计思路,距离 v0.1.0 发布也就一周时间,v0.2.0 紧跟着就出来了。这次更新内容不少,15 个新特性,有些是我自己需要的,有些是来自社区反馈的。
这篇主要讲三件事:v0.2.0 有什么新东西、怎么从零开始部署、以及一些实际使用中的注意事项。
v0.2.0 新功能概览
这次更新内容不少,按类别列一下:
部署相关
- Docker 容器镜像(AMD64 + ARM64),发布到 GHCR
- 一键安装脚本
curl | bash - 自动初始化 + 设置模式,首次启动无需配置文件
mibee-nvr init交互式配置命令mibee-nvr health健康检查
录制和存储
- H.265 全链路支持(录制 + HLS 直播)
- HTTP JPEG 摄像头接入(ESP32-CAM 直连)
- 录像段自动合并,减少碎片文件
- 每摄像头独立保留天数
- 明文密码自动转 bcrypt hash
直播和协议
- HLS 按需直播流(H.264 / H.265)
- 子码流回退(带宽有限时自动降级)
- ONVIF 设备发现(后端框架已搭好)
Web 界面
- Chart.js 统计图表(存储趋势 + 每摄像头统计)
- 明暗主题自动检测
- 中英文语言切换
- 响应式布局(手机 + 桌面)
- 合并进度监控面板
- WebDAV 读写模式
挑几个重点展开说说。
Docker 支持
这应该是挺必要的功能了。v0.1.0 只有二进制文件下载,虽然对老手来说够用了,但很多朋友还是习惯 Docker 一把梭。v0.2.0 提供了官方容器镜像,支持 AMD64 和 ARM64 双架构,发布在 GitHub Container Registry。
关键点是:支持自动初始化。第一次启动不需要提前准备配置文件,容器会自己生成一份默认配置,然后进入「设置模式」——所有 API 都不需要认证,方便你通过 Web 界面完成首次配置。
HLS 直播流
之前只能看录像,不能看实时画面。v0.2.0 加了 HLS 直播功能,支持 H.264 和 H.265 两种编码。实现在 Web UI 里点一下就能看,不需要额外装播放器。
技术细节上用的是 gohlslib,按需生成 HLS 流——有客户端请求的时候才启动,没人看就自动释放资源。还做了异步帧写入,把 HLS 流和录制管线解耦,互不影响。
另外一个实用的点:支持子码流(sub-stream)回退。如果主码流带宽占用太高,可以配置一个低分辨率的子码流地址,在带宽有限的时候自动切换。
HTTP JPEG 摄像头
v0.1.0 只支持 RTSP 协议的摄像头,v0.2.0 加了 HTTP JPEG 支持。这意味着 ESP32-CAM 这类只能输出 MJPEG 流的设备可以直接接入了,不需要再折腾 RTSP 转换。
在 Web UI 里用 Canvas 做了一个 MJPEG 帧播放器,效果比直接显示 JPEG 图片流畅不少。
录像段合并
30 秒一个分段文件,一天下来一个摄像头就是 2880 个文件。文件多了管理起来不方便,数据库查询也会变慢。v0.2.0 加了自动合并功能:定期把同一摄像头的时间段内的小文件合并成大的 MP4。
合并策略可以全局配置,也可以针对单个摄像头单独设置。Web UI 上还有合并进度的监控面板。
每摄像头独立保留策略
之前所有摄像头共用一个保留天数,但实际使用中不同摄像头的录像重要性差别很大。门口的录像可能要保留 30 天,但阳台的保留 7 天就够了。v0.2.0 支持给每个摄像头设置独立的 retention_days。
安装部署指南
这部分是重点,详细说一下各种部署方式。从最简单的到最灵活的,按需选择。
部署方式对比
graph TB
A["选择部署方式"] --> C["有 Docker → Docker 部署<br/>最省心"]
C --> D["Linux 裸机 → 一键脚本<br/>最快"]
D --> E["想自己控制 → 手动下载<br/>最灵活"]
E --> F["要改代码 → 源码编译<br/>最硬核"]方式一:Docker 部署(推荐新手)
如果你机器上已经装了 Docker,这是最省心的方式。两条命令搞定。
最简单的跑法,不用提前准备任何配置文件:
| |
第一次启动会自动生成默认配置,进入设置模式。打开浏览器访问 http://你的IP:9090,不需要密码就能进。
如果想直接指定初始密码:
| |
用 docker-compose 的话也很简单。先创建目录结构:
| |
然后写一个 docker-compose.yml:
| |
然后:
| |

这是刚装完什么数据都没有的样子。接下来该添加摄像头了。
几个注意事项:
- 录像数据存在容器内的
/data目录,务必挂载到宿主机,不然容器重建数据就丢了 - FTP 端口(2121)和被动模式端口(2122-2140)是可选的,不用 FTP 的话可以不暴露
- ARM64 设备(树莓派等)拉的是同一个镜像标签,Docker 会自动选择对应架构
- 内置了健康检查命令,配合
docker ps可以看到容器状态
方式二:一键安装脚本(Linux 裸机)
没有 Docker 的 Linux 机器,用这个最快:
| |
脚本会自动完成以下步骤:
- 检测系统架构(AMD64 / ARM64)
- 从 GitHub Releases 下载最新的二进制文件
- 创建
nvr系统用户(安全考虑,不用 root 跑) - 提示你输入管理员密码
- 生成配置文件到
/var/lib/mibee-nvr/ - 安装 systemd 服务并启动
装完后直接访问 http://你的IP:9090 就行。
指定版本安装:
| |
卸载(不会删除录像数据):
| |
方式三:手动下载二进制
想完全自己控制的,手动下载也行。到 GitHub Releases 页面下载对应架构的二进制文件。
| |
初始化配置:
| |
init 命令的完整参数:
| 参数 | 默认值 | 说明 |
|---|---|---|
--password | 交互输入 | 管理员密码 |
--username | admin | 管理员用户名 |
--data-dir | /var/lib/mibee-nvr | 数据存储目录 |
--listen | :9090 | 监听地址和端口 |
--config | mibee-nvr.yaml | 配置文件路径 |
--force | false | 覆盖已有配置文件 |
启动:
| |
如果想让它在后台稳定运行,配上 systemd 服务。创建 /etc/systemd/system/mibee-nvr.service:
| |
然后:
| |
方式四:源码编译
国内 GitHub 访问慢可以走 Gitee:
| |
编译需要 Go 1.26+ 和 Node.js(前端构建用)。编译产物在当前目录下,一个二进制文件搞定。
交叉编译 ARM64(在 x86 机器上编译给 ARM 设备用):
| |
首次配置
不管用哪种方式装好的,打开浏览器访问 http://你的IP:9090,会看到登录页面:

v0.2.0 新增了明暗主题自动检测,会跟随系统设置切换。语言也支持中英文切换了。
输入你在初始化时设置的账号密码登录,进入主界面。
添加摄像头
登录后进入摄像头管理页面:

这是新装的,什么摄像头都还没加。点击「添加摄像头」,需要填写以下信息:
- ID:摄像头的唯一标识,英文小写加横线,比如
front-door - 名称:显示名称,中文也行
- 协议:
rtsp、http或onvif - 编码:
h264、h265、mjpeg或jpeg - URL:视频流地址
- 启用:是否立即开始录制
v0.2.0 把协议和编码拆成了两个独立字段,比 v0.1.0 的 rtsp_h264 这种写法更灵活。
几个常见摄像头的配置示例:
| |
添加完摄像头后,系统会自动开始录制。可以在摄像头列表看到每个摄像头的在线状态和最后活跃时间:

录像管理
录像是按时间段自动分段的,默认 30 秒一段。在录像列表页面可以按摄像头和时间筛选:

统计仪表盘
v0.2.0 新增了 Chart.js 驱动的统计图表,可以看存储趋势和每个摄像头的录制量。支持按时间范围筛选,也能单独开关某个摄像头的统计线:


设置页面
所有配置都可以在 Web UI 里改,不用手动编辑 YAML 文件:

主要配置项:
- 清理策略:保留天数、磁盘阈值、检查间隔
- WebDAV:开关、路径前缀、读写模式
- 合并策略:开关、合并窗口、最小段数、批量限制
- 前端偏好:每页条数、自动刷新间隔
这里提一下合并策略。如果你开了合并,系统会定期把同一摄像头的小分段文件合并成大文件。比如 30 秒一个段,合并窗口设 1 小时,那就会把 120 个小文件合成一个 1 小时的大文件。好处是文件数量大幅减少,管理和查询都更快。
v0.2.0 完整数据流
更新后的系统架构,比 v0.1.0 多了不少东西:
graph TB
CAM1["RTSP 摄像头 H.264/H.265"] --> RTSP_R["RTSP 录制器"]
CAM2["HTTP 摄像头 MJPEG/JPEG"] --> HTTP_R["HTTP 录制器"]
CAM3["ONVIF 设备"] --> API["REST API"]
RTSP_R --> SEG["MP4 分段 30s"]
HTTP_R --> SEG
SEG --> DB["SQLite 元数据"]
SEG --> MERGE["合并引擎"]
SEG --> CLEAN["清理引擎"]
RTSP_R -->|"帧分支"| HLS["HLS 直播"]
API --> UI["Web UI"]
HLS --> UI
API --> WEB["Web 浏览器"]
API --> DAV["WebDAV"]
API --> FTP["FTP"]
API --> MQTT["MQTT 触发"]
API --> PROM["Prometheus"]和 v0.1.0 相比,主要变化:
- 录制引擎从单一的 RTSP 扩展为多引擎(RTSP + HTTP JPEG)
- HLS 直播通过帧分支(frame branching)实现,录制和直播互不干扰
- 合并引擎作为存储层的后处理步骤
- 清理引擎支持每摄像头独立策略
- ONVIF 模块已搭好框架,前端 UI 也有了,等后端库集成就能用
实际部署建议
跑了一段时间下来,总结几个实用建议:
硬件选型
MiBeeNvr 本身资源占用很小,瓶颈主要在视频解码和存储。建议配置:
| 摄像头数量 | 最低配置 | 推荐配置 |
|---|---|---|
| 1-2 个 | 512MB RAM, 2GB 存储 | 1GB RAM, 16GB 存储 |
| 3-4 个 | 1GB RAM, 8GB 存储 | 2GB RAM, 32GB 存储 |
| 5+ 个 | 2GB RAM, 16GB 存储 | 4GB RAM, 64GB+ 存储 |
分段时长对内存影响比较大:30 秒分段每路大约 15-20MB 内存,60 秒翻倍。内存有限的设备建议用默认的 30 秒。
存储规划
录像文件按 数据目录/摄像头ID/日期/ 的目录结构存储。比如:
| |
开了合并之后,合并完的文件会替代原始分段:
| |
网络配置
如果要从外网访问,建议在前面加一层反向代理(Nginx / Caddy),配上 HTTPS。MiBeeNvr 本身不支持 HTTPS,但这种事交给专业的反向代理做更好。
更新日志
v0.2.0 的完整更新列表:
Docker 和部署
- 官方 Docker 容器镜像,双架构(AMD64 + ARM64),发布到 GHCR
- docker-compose.yml 一键部署
- 自动初始化,首次启动无需配置文件
- 设置模式(无密码时免认证)
- 一键安装脚本
curl | bash - 内置 Docker HEALTHCHECK
- GitHub Actions CI/CD 自动构建和发布
录制和媒体
- 录像段自动合并,支持全局和每摄像头独立配置
- HTTP JPEG 摄像头录制(MJPEG 流)
- 每摄像头独立保留天数(
retention_days) - 协议和编码字段独立配置(
rtsp+h265,http+jpeg)
直播和 ONVIF
- HLS 直播流(H.264 / H.265),按需生成
- 子码流回退,带宽有限时自动降级
- ONVIF 设备发现(后端框架已搭好)
Web UI
- 明暗主题,自动检测系统偏好
- Chart.js 统计图表(存储趋势、每摄像头统计)
- 中英文语言切换
- 响应式布局(手机和桌面)
- 合并进度监控面板
运维工具
mibee-nvr init交互式初始化mibee-nvr health健康检查命令- 明文密码自动转 bcrypt hash
开源地址
项目持续更新中,欢迎 star 和反馈:
- MiBeeNvr:https://github.com/Mi-Bee-Studio/MiBeeNvr (MIT 许可证)
- 国内镜像:https://gitee.com/Mi-Bee-Studio/MiBeeNvr