同期发布的 MiBeeNvr v0.6.0 带来了延时摄影、视频转码、ONVIF 增强等大功能，光靠单元测试远远不够，必须在真实摄像头环境下跑完整流程。为了给这个版本提供靠谱的测试机器，6 月 5 日同一天更新了三个摄像头项目——既是给 NVR 提供测试环境，也顺手解决了一些嵌入式开发中比较典型的工程问题。

MiBeeNvr 连续跑了几周录像后，存储最先告急。单路 1080p 摄像头每天要写几十 GB，30 天留存一件 1TB 硬盘就没了大半。社区里不少朋友反馈了同样的问题，讨论中延时摄影和转码保存的方案呼声最高——画面大部分时间静止，用 timelapse 压缩后同样时长只需要 5% 的空间。

v0.4.0 发布不到一周，又肝了 31 个提交。v0.5.0 是一个功能密度很高的版本：ONVIF 全协议支持（Device/Media/PTZ/Imaging/Event 五大服务全覆盖）、硬件转码（H.265 → H.264）、录制器重连优化。127 个文件变更，+24,509 / -730 行。完整更新列表见 GitHub Release Notes。

做运维出身，后来转开发，维护的项目越来越多。各种中间件、数据库、监控组件……每次升级版本都是一场体力活：去官网找下载链接、比对版本号、手动下载到内网、再分发到各台机器。以前写了一堆 Shell 脚本定期拉取最新版本到局域网，能用但不好用——脚本散落在各处，加新软件得手写解析逻辑，出错了也没什么日志可查。

之前 MiBeeNvr 录的 MP4 文件只有视频轨，播放时是静音的。v0.4.0 补上了这个功能 —— 音频录制。同时新增了更实用的 摄像头健康监控和自动恢复。 录像有声音了 每个摄像头都可以单独开启音频录制：

v0.3.1 发布之后又肝了 196 个提交。v0.4.0 是一个功能密度很高的版本：音频录制管线、多层健康监控引擎、HLS/LL-HLS 播放稳定性优化、UI 大改版。完整更新列表见 GitHub Release Notes。

v0.2.0 发布之后又折腾了不少，这次 v0.3.x 带来了几个重量级更新：小米摄像头内置支持、归档录像功能、多协议流媒体架构（WebRTC/HTTP-FLV/RTMP/SRT/LL-HLS），以及一大波安全加固。从外部依赖到内置实现、从单协议到全协议支持的架构演进过程，比我想象的要曲折得多。

起因：等保检查的那点事 做运维的都知道，国内服务器逃不过一道坎：网络安全等级保护（GB/T 22239-2019，俗称等保 2.0）。不管你是三级还是二级，测评机构来了都得查这几样东西：

家里有小米摄像头？想把录像存到自己手里，不靠云存储？ 作为一个家里装了几个小米摄像头的用户，我一直有个烦恼：每次想看门口的录像，都得先登录小米云，加载半天还经常转圈。而且云存储按天收费，一个月下来也不是小数目。有时候换摄像头，之前的录像就全没了，想想都觉得可惜。

从静态到实时 上一篇文章介绍了 security-collector-exporter v0.1.0——把 Linux 安全配置状态变成 Prometheus 指标。但 v0.1.0 本质上还是"快照式"的：定时读 /etc、/proc，抓的是某一时刻的静态配置。