diff --git a/assets/_/2025/construction-site-surveillance/grafana-traffic.png b/assets/_/2025/construction-site-surveillance/grafana-traffic.png
index 40ac28b..ee8898c 100644
Binary files a/assets/_/2025/construction-site-surveillance/grafana-traffic.png and b/assets/_/2025/construction-site-surveillance/grafana-traffic.png differ
diff --git a/assets/_/2025/construction-site-surveillance/frigate-config.png b/assets/_/2025/construction-site-surveillance/moonfire-config.png
similarity index 100%
rename from assets/_/2025/construction-site-surveillance/frigate-config.png
rename to assets/_/2025/construction-site-surveillance/moonfire-config.png
diff --git a/content/log/2025/construction-site-surveillance.md b/content/log/2025/construction-site-surveillance.md
index aa1c912..c19d3be 100644
--- a/content/log/2025/construction-site-surveillance.md
+++ b/content/log/2025/construction-site-surveillance.md
@@ -1,7 +1,6 @@
---
title: "Construction site surveillance"
-date: 2025-02-24T22:01:14+02:00
-draft: true
+date: 2025-04-01T14:26:00+02:00
---
I am building a house, for which I decided I need a surveilance cameras. I have
@@ -59,12 +58,18 @@ There are two codec choices, mostly:
found in Wikipedia][14], it was used by 91% of video industry developers as
of September 2019. Every screen-equipped device that I tried can play it.
- *H.265* (a.k.a. _HEVC_) is a royalty- and patent-ridden codec which offers
- 25-50% better compression ratios[15]. In my experience, the compression ratio
- was over 50%. It is amazing for transfer, un-playable on everything I've
- tried except Google Chrome browser on Android[^1].
-- Footnote: *H.264+*, *H.264B*, *H.264H* and similar. They are "close"
- derivatives of H.264. Software support is hit-or-miss, so I mostly ignore
- those.
+ 25-50% [better compression ratios][15]. In my experience, the compression
+ ratio was over 50%. It is amazing for transfer, un-playable on everything
+ I've tried except Google Chrome browser on Android[^1].
+- *AV1* seems to be anecdotally on-par with H.265 and is not patent-ridden.
+ Camera cannot stream it, but lack of patent problems implies, it should be
+ good for recordings. However:
+ - I was not able to (easily) setup go2rtc with AV1.
+ - The 5-minute experiments yielded similar bitrates for similar quality. In
+ the end, I decided it's not worth the hassle until go2rtc offers a packaged
+ configuration for it.
+- *H.264+*, *H.264B*, *H.264H* and similar. They are "close" derivatives of
+ H.264. Software support is hit-or-miss, so I mostly ignore those.
# Picking the camera
@@ -83,8 +88,7 @@ There are a few variables you may want to check:
known about it, or at least read the Dahua part, before purchasing mine.
Note that most cameras are designed and manufactured in China. Which,
-unsurprisingly, have [bad reputation in the Chinese-controlled areas][1]. I
-also found out about it only while researching open-source NVRs.
+unsurprisingly, have [bad reputation in the Chinese-controlled areas][1].
# Network Video Recorder
@@ -102,20 +106,40 @@ two options for an NVR:
[home server]({{< ref "log/2023/nixos-subjective" >}}), I am self-hosting my
NVR.
+## Moonfire NVR
+
*Moonfire NVR* seems like the simplest of the bunch: low hardware requirements
(raspberry pi 2!), minimal number of features. Cons: does not have object
detection, not even "in theory". I have relatively powerful hardware in the
closet and want object detection for it.
+Moonfire NVR's interface is ncurses-based, similar to how Linux kernel is
+configured. In opinion, for end-user product, one either offers file-based
+configuration, or web-based configuration directly in the browser. Many
+projects do both (e.g. home-assistant, frigate). This is the first ncurses-based
+configuration for a consumer product. Which makes me wonder what their audience
+is.
+
+
+{{
}}
+
+Once configured, the recordings are printed as a timestamped list. Which is
+good if you know the time upfront, but is not great for discovery.
+
+{{
}}
+
+## Setting up Frigate
+
*Frigate* seems to be what the kids use these days. Documentation is extensive,
though sometimes not very accurate, but [their forums][13] compensate for it.
It took a few evenings to get it to work, and it works.
-*ZoneMinder* is the oldest and most established. I learned about it only after
-having set up Frigate.
-
-## Setting up Frigate
-
A few tips before you get started:
- for object detection you will need hardware support. Look at [recommended
@@ -123,16 +147,13 @@ A few tips before you get started:
OpenVINO too.
- start with go2rtc from the get-go. I had to re-configure all the Frigate
streams, which was way more annoying than it's worth if you start with
- go2rtc.
-- as of writing I have [a performance problem with detectors using lots of
- CPU][7] that nobody seem to be able to reproduce. I am hopeful Frigate 0.15
- will fix this.
+ go2rtc. Saved a lot of bandwidth, too. More on that later.
## Connecting the camera
I bought [Teltonika Rutx11][8] 4G router/wifi modem that will fit in the
[camera junction box][9]. Antennas will be outside:
-- [External 4G antenna from Mikrotik][10]
+- [External 4G antenna from Mikrotik][10].
- [Wi-fi dual-band magnetic sma antenna from Teltonika][11].
I purchased an unlimited 4G plan from an ISP that has good connectivity in the
@@ -140,14 +161,24 @@ area. Then connected the Rutx11 via tailscale/[headscale][12]. Using tailscale
I can connect to the camera directly from both my NVR and all personal devices,
a yet another tailscale+headscale recommendation.
+I disabled outgoing connections from the camera on the router. As a nice
+side-effect, I have a _really nice_ WiFi hotspot in the construction site.
+
## Bandwidth and codec considerations
Two camera streams (`2688x752` and `1920x1080`), encoded in h.265 consume
-around 1.8Mb/s 24/7. Both streams are transcoded to h.264 via go2rtc and then
-sent over to Frigate and live view. and
+around 2Mb/s 24/7. Both streams are transcoded to h.264 via go2rtc and then
+sent over to Frigate and live view. Then recorded as H.264. Recordings for both
+cameras take ~21-24GiB/day.
Every 5 minutes a separate process captures a full-resolution picture of both
-cameras: `5376x1520` and `2560x1440`.
+cameras: `5376x1520` and `2560x1440`. I have a bunch of timelapses already! If
+we meet in person, I will happily show.
+
+{{
}}
Using exactly the same parameters (resolution, fps), but with h.264, the
bandwidth grows to 11 Mb/s. Which may not sound like a lot with today's fiber
@@ -155,6 +186,7 @@ everywhere, but is considerable on a 4G connection.
Since the home server has a graphics card, it can use hardware acceleration for
video encoding and decoding. Thanks to proliferation of online video platforms,
+those decoders and encoders are available on even the cheapest hardware.
It takes ~5-10% of a single CPU core to transcode a stream, depending on the
resolution. In my case, I am transcoding 4 streams (2 cameras, "low" and "high"
@@ -165,13 +197,19 @@ Once the house is complete and I move NVR to the same physical network, I will
change the encoding to h.264, stop transcoding and use more video bandwidth
locally.
+# Final notes
+
+With the current open-source NVR ecosystem and the price of consumer-grade
+surveilance cameras (low hundreds of €), I highly recommend setting one up if
+you are building something. It takes a few weeks to learn all the dusty
+corners, but, in my opinion, in the end it's worth it.
+
[1]: https://uhrp.org/statement/hikvision-and-dahua-facilitating-genocidal-crimes-in-east-turkistan/
[2]: https://web.archive.org/web/20250221205936/https://ipcamtalk.com/wiki/ip-cam-talk-cliff-notes/
[3]: https://frigate.video
[4]: https://github.com/scottlamb/moonfire-nvr
[5]: https://zoneminder.com/
[6]: https://docs.frigate.video/frigate/hardware
-[7]: https://github.com/NixOS/nixpkgs/issues/381280
[8]: https://teltonika-networks.com/products/routers/rutx11
[9]: https://www.dahuasecurity.com/products/All-Products/Accessories/Camera-Accessories/Camera-Mounts/Junction-Boxes/PFA126
[10]: https://mikrotik.com/product/mant_lte_5o