julian
3a176c5cc8
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
42 lines
2.5 KiB
Markdown
42 lines
2.5 KiB
Markdown
---
|
||
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.
|