9 路摄像头挂在 Banana Pi M5 上跑了大半年，从 v0.6 开始累积的工程债到了不得不还的时候。/api/cameras 接口在 9 个录制器全部启动的过程中要卡 14.9 秒——不是遍历慢，是 cm.mu RWMutex 在阻塞，任何读操作都进不来。ONVIF 摄像头添加还得手动填 IP，家里装了 CW500、DS-2CD2047G2 这类设备之后，每多一台就要开一次终端，不可持续。FFmpeg 作为 NVR 唯一的第三方二进制依赖，每次部署都要确认装没装，树莓派上还要操心硬件编码器版本。更扎心的是，Xiaomi 的那几个旧设备——Dafang、Xiaofang、Aqara G2——因为走了 TUTK 协议，一直没法接入。这些问题都不是新技术挑战，是工程债，v0.9 一次性还了。
Continue reading →上一篇讲了 v0.3.0 有什么。这篇讲为什么——本版有三个看似随意、背后有具体工程取舍的决定：Docker 网络模式如何决定 scanner 的探测保真度、TLS 证书链采集为什么能用一个核心覆盖 8 个协议、L2 拓扑为什么需要三个 MIB 才拼得起来。逐个拆。
Continue reading →接手一个不熟悉的局域网，第一件事是搞清楚里面有什么——办公室、机房、家里几个网段混接，没人留下文档，交换机上连着一堆没人叫得出名字的 MAC。MiBeeSteward 就是干这件事的：扫一遍网络，告诉你有哪些设备、它们是什么、它们之间怎么连的。
Continue reading →上一篇讲了 v0.2.0 有什么。这篇讲为什么这么设计——分布式一致性是这个版本最重的部分，几个看似随意的决定背后都有具体的取舍。 要解决的问题很明确：center 只能看见自己所在的 LAN，但用户有多个 LAN。把 center 扔到每个网段不现实，于是有了 mibee-agent——一个只做「扫本地 + 报 center」的二进制。但 agent 一上，立刻带出一串协议问题：怎么上报、怎么对账、怎么判定掉线、怎么不把 center 写爆。下面逐个拆。
Continue reading →v0.1.0 发布的时候我写了一句：它能回答「网络上有哪些设备、它们是什么、它们之间什么关系」。但说实话，v0.1.0 只答好了前半句——而且只限于 center 所在的那一个 LAN。 工作室的真实场景是：办公室一个网段、机房一个网段、家里跑测试机又一个网段。center 坐在办公室，机房的摄像头它根本看不见。要让 center 去扫机房，得跨子网穿透，要么开 SNMP 路由转发，要么干脆把 center 搬过去——两个都不优雅。
Continue reading →做工作室运维，最头疼的从来不是某个具体问题，而是设备多起来之后的「不知道」。 不知道哪个设备还活着，不知道它上面跑了什么服务，不知道网络里什么时候多了台新机器，不知道某个端口是不是还开着——这种「不知道」积累到最后就是故障。
Continue reading →内容写得再好，搜索引擎抓不到、搜不到，等于没写。这话说得有点重，但对绝大多数独立博客来说就是事实——你的服务器托管在某个 VPS 上、域名权重不高、外链稀少，Googlebot 可能一个月才来转一圈，而且每次来了看到的还是几周前的内容。读者在搜索框里输入的关键词，永远不会指向你的页面。一篇精心打磨的技术文章，最终只能躺在自己的归档页里吃灰。
Continue reading →在 MiBee NVR 项目里要把摄像头画面推到国内某直播平台，候选方案有三个：直接调 FFmpeg、用纯 Go 的 gortmplib、用 go2rtc。三个都能「推 RTMP」，但实际对接国内直播平台时表现差异巨大——有的秒断、有的几秒后断、有的稳如老狗。这篇从源码层面把三者拆开对比，并梳理对接国内 FMS 兼容平台时的坑和解法。
Continue reading →Zhi 主题 发布了 v0.2.0——这是从 4 月份 初次发布 后最重要的功能更新。这次发布的三个重头功能——多语言切换、文章系列（Series）分类法、Mermaid v11+ 升级——都是在自己使用过程中逐步积累的需求。
Continue reading →v0.6.0 把延时摄影管道搭起来之后，社区反馈很快就指出了几个硬伤：JPEG 序列要吃掉太多存储、H.265 摄像头生成的延时片段播放不了、双摄小米设备只能抓到主镜头、偶尔还会出现 H.265 HLS 直接 panic 的崩溃。这些都不是边缘场景——双摄 CW500 和室外摄像头 4 在国内出货量很大，H.265 已经是中高端摄像头的事实标准。v0.7.0 的主线就是围绕这些反馈展开的。
Continue reading →