I am the Bee in Mi&Bee — the handle xiqing85 carries both my name
(XiQing) and the bee I'm named after. I build MiBee Eye (蜂眼, "the
bee's eye"): an open, self-hosted camera family — lightweight camera
services for single-board computers and PCs — plus the GB/T 28181 / ONVIF
protocol libraries that power them.
- 🔭 Focus: streaming protocols (GB/T 28181, ONVIF, RTSP/RTMP/RTP), Rust & Go systems programming, self-hosting
- 🐝 Same product, sibling implementations — Rust and Go editions maintained side by side, one shared web UI and API spec across every device
- 📐 Protocol-first: wire formats are pinned by golden tests, and the products consume the protocol libraries — never the other way round
| Repo | What it is |
|---|---|
| mibee-eye-rs | Rust camera service — V4L2 capture, hardware or software H.264 encoding, GB28181 + ONVIF device roles |
| mibee-eye-go | Go camera service — same mission, pure-Go V4L2 layer, ffmpeg fallback |
| mibee-eye-notebook | PC-local webcam & microphone capture agent (Rust workspace, TLS web UI) |
| mibee-eye-webui | Unified web frontend + API spec shared by all devices — zero-build ES modules |
| Repo | What it is |
|---|---|
| gb28181-rs | GB/T 28181-2022 device-side stack for Rust (SIP, MANSCDP, GB35114 auth) |
| gb28181-go | GB/T 28181 device & platform toolkit for Go |
| onvif-rs | ONVIF device-side services for Rust (WS-Discovery, SOAP) |
| onvif-go | ONVIF client + server for Go |
All Apache-2.0. Wire formats are pinned by golden tests, and the product repos consume the libraries — protocol fixes land in the library first, then bump the dependency pin.