docs(wiki): DS-2CD1047G3H-LIU main-stream ISAPI snapshot is a firmware bug — camera line to be replaced

Full live investigation of the persistent 503 "deviceBusy" on main-stream ISAPI
snapshots (10.0.10.13): ruled out config (byte-identical to a working sibling
model), ruled out firmware age (reproduced on both the original V5.8.11 and
current V5.11.0 builds, ~15 months apart), and ruled out real resource
contention (a full channel-ID sweep shows every ID fails identically except
the one hardcoded working value, including nonexistent channels) — pointing
at a broken/incomplete ISAPI snapshot handler that mislabels itself as
"busy," not a real encoder ceiling.

RTSP main-stream frame-grab was confirmed as a working route around it, but
given the bug and the sub-stream's real-world plate-read accuracy problems,
the owner decided to replace the DS-2CD1047G3H-LIU units rather than carry
an ffmpeg/RTSP dependency to work around vendor firmware. Ingested the
vendor datasheet as a source page along the way.

Claude-Session: https://claude.ai/code/session_01FWncR69HgGPuei1dLrW3cU

wiki/sources/ds-2cd1047g3h-liu.md

@@ -0,0 +1,41 @@
+---
+type: source
+tags: [parking, hardware, cameras, hikvision, datasheet]
+sources: [DS-2CD1047G3H-LIU]
+updated: 2026-08-23
+---
+
+# Source: HIKVISION DS-2CD1047G3H-LIU-F datasheet
+
+Vendor spec sheet (`raw/DS-2CD1047G3H-LIU.md`) for the **DS-2CD1047G3H-LIU** — the exit-lane
+camera at `10.0.10.13` (park-buzi) already covered extensively in [[lpr-camera]] for its
+persistent main-stream ISAPI 503 (`deviceBusy`) and its 2026-06-27 config-DB-corruption incident.
+This is the first *vendor-sourced* spec data for the model; everything before it was field-derived.
+
+## Key takeaways
+
+- **4 MP, max resolution 2560×1440** (ColorVu 3.0 — color night imaging, not IR-only).
+- **Main stream: H.265+/H.265/H.264+/H.264 only — no MJPEG option.** **Sub-stream: H.265/H.264/
+  MJPEG** (MJPEG is sub-only). This is a concrete, spec-level asymmetry that plausibly explains
+  *why* the ISAPI on-demand JPEG snapshot is reliable on sub but structurally broken on main: sub
+  can serve a snapshot natively, main has to transcode out of H.264/H.265 on demand. Consistent
+  with — and a likely root cause for — the persistent `deviceBusy` behavior already logged in
+  [[lpr-camera]].
+- **Bit rate range 32 Kbps–16 Mbps.** The site's main-stream config (6144–12288 Kbps, confirmed
+  live 2026-08-23) is well inside spec — rules out "misconfigured over the camera's own ceiling"
+  as a cause, confirming what live testing already showed.
+- **ROI: 1 fixed region for main stream** — another main-only constraint/asymmetry vs. sub.
+- **API: ONVIF (Profile S, Profile G), ISAPI, SDK.** ISAPI is fully in-spec for this model — the
+  503 is a real firmware/hardware limitation, not a case of using an unsupported API.
+- **Protocols include RTSP** (alongside HTTP/ONVIF/etc.) — confirms RTSP is a documented, supported
+  surface on this model, not a workaround outside its design.
+- Simultaneous live view: up to 6 channels. Available in `-LIU`/`-LIUF`/`-LIUF/SL`/`-LIUF/SRB`
+  variants at 2.8mm/4mm focal lengths; the deployed unit is the base `-LIU`.
+
+## How this changes the picture
+
+Confirms rather than overturns [[lpr-camera]]'s existing conclusion (sub-stream-only for ISAPI
+snapshots on this model) — but gives it a concrete mechanical explanation (main has no MJPEG path)
+instead of just an empirically-observed limitation. See [[lpr-camera]] § "Main-stream ISAPI
+snapshot 503 vs. RTSP" for the 2026-08-23 live comparison against a `DS-2CD1043G2-LIU` sibling
+(main-stream ISAPI snapshot works fine there) and the confirmed RTSP frame-grab workaround.