From 3a176c5cc8432a343e0f24cd3ce48f05bfbeffa3 Mon Sep 17 00:00:00 2001 From: Julian Cuni Date: Sun, 23 Aug 2026 14:50:22 +0200 Subject: [PATCH] =?UTF-8?q?docs(wiki):=20DS-2CD1047G3H-LIU=20main-stream?= =?UTF-8?q?=20ISAPI=20snapshot=20is=20a=20firmware=20bug=20=E2=80=94=20cam?= =?UTF-8?q?era=20line=20to=20be=20replaced?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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/entities/lpr-camera.md | 110 +++++++++++++++++++++++++++++- wiki/index.md | 3 +- wiki/log.md | 54 +++++++++++++++ wiki/raw/DS-2CD1047G3H-LIU.md | 50 ++++++++++++++ wiki/sources/ds-2cd1047g3h-liu.md | 41 +++++++++++ 5 files changed, 255 insertions(+), 3 deletions(-) create mode 100644 wiki/raw/DS-2CD1047G3H-LIU.md create mode 100644 wiki/sources/ds-2cd1047g3h-liu.md diff --git a/wiki/entities/lpr-camera.md b/wiki/entities/lpr-camera.md index 35e02c8..1e962fe 100644 --- a/wiki/entities/lpr-camera.md +++ b/wiki/entities/lpr-camera.md @@ -1,8 +1,8 @@ --- type: entity tags: [parking, hardware, readers, offline-first] -sources: [parking-system-architecture] -updated: 2026-07-07 +sources: [parking-system-architecture, DS-2CD1047G3H-LIU] +updated: 2026-08-23 --- # LPR Camera @@ -110,6 +110,112 @@ Covered by `packages/devices/src/drivers/camera.test.ts` (retry behaviour + the selection). `healthCheck()` deliberately reports a live 503 as `degraded` (it surfaces a genuinely saturated main stream rather than hiding it behind a retry). +### Main-stream ISAPI snapshot 503 is model-specific, not config — and RTSP routes around it (2026-08-23) + +Live comparison, same site (park-buzi), same day, both cameras reachable via the site's port +forwards (`park-buzi.msai.al:8081` / `:8082`) and directly on the LAN (`10.0.10.13` = the `:8082` +unit): + +| | `:8081` (works) | `:8082` = `10.0.10.13` (503s) | +|---|---|---| +| Model | **DS-2CD1043G2-LIU** | **DS-2CD1047G3H-LIU** | +| Firmware | V5.8.10 | V5.8.11 | +| Channel 101 config | 2560×1440, VBR, 6144 Kbps cap, 20fps | **identical** — 2560×1440, VBR, 6144 Kbps cap, 20fps | +| `SmartCodec` | disabled | disabled | +| `GET /ISAPI/Streaming/channels/101/picture` | **200**, valid JPEG | **503**, `statusCode 2 / deviceBusy` (3/3 retries, instant) | +| `GET /ISAPI/Streaming/channels/102/picture` (sub) | — | **200**, valid JPEG | + +Channel-101 config is **byte-identical** between the two units (bitrate, resolution, frame rate, +SmartCodec) — this rules out "misconfigured over some ceiling" definitively; the only things that +differ are model + firmware. Combined with the [[#Source: HIKVISION DS-2CD1047G3H-LIU-F datasheet| +vendor datasheet]] fact that the G3H's **main stream has no MJPEG option** (sub-stream does), the +working theory is that this SKU's snapshot codepath has to transcode a live H.264/H.265 frame into +JPEG on demand for main, and its firmware/encoder can't do that reliably at this resolution — +while sub can serve JPEG more natively. **Treat this as a `DS-2CD1047G3H-LIU`-model limitation +(this firmware line), not a config or ISAPI-usage bug** — matches every earlier finding on this +same unit (`10.0.10.13`) in the sections below, now cross-confirmed against a working sibling model +on the same network with identical settings. + +**RTSP main-stream frame-grab works and routes around it entirely**, confirmed live against +`10.0.10.13`: + +```bash +ffmpeg -rtsp_transport tcp -y \ + -i "rtsp://admin:@10.0.10.13:554/Streaming/Channels/101" \ + -frames:v 1 -update 1 snapshot.jpg +``` + +Returned a valid 2560×1440 JPEG (94 KB) on the first try — same camera, same main-stream +resolution the ISAPI endpoint 503s on. This makes sense mechanically: RTSP just taps the H.264 +stream the encoder is **already producing continuously** for live-view/recording; there's no +on-demand "pause and re-encode as standalone JPEG" step for the firmware to choke on, unlike the +ISAPI snapshot path. Port 554 is open on the LAN (`10.0.10.13`) but **not** forwarded through the +site's public port-forward (`park-buzi.msai.al` only exposes the HTTP/ISAPI ports, consistent with +[[network-isolation|the camera/controller network staying LAN-only]] — RTSP was only reachable +from inside the site network, never tested through the public forward). + +**Not yet built**: `packages/devices/src/drivers/camera.ts` is HTTP-Digest/ISAPI only today: no +RTSP client, no `ffmpeg` child-process dependency. Adding an RTSP fallback (or RTSP-first path for +cameras that report persistent `deviceBusy` on ISAPI main) is a real architectural addition — new +process-spawn dependency, RTSP auth handling, transport selection (TCP confirmed working; UDP +untested) — not implemented as of this writing. + +**Escalated from "nice to have" to a real requirement (2026-08-23): the sub-stream (768×432) is +too weak for reliable plate reads** — it fails to read plates "from time to time" in practice, so +sub-stream-only is not an acceptable permanent mitigation for this camera; RTSP-for-main is needed +for ANPR accuracy, not just for a higher-res evidence photo. + +**Firmware update tested and RULED OUT as the fix (2026-08-23).** Before building the RTSP path, +checked whether this was simply a day-one bug: the camera shipped on `V5.8.11` build 250415 — +confirmed via the official Hikvision release note to be **the very first H13U firmware build that +added support for the DS-2CD1XX7G3H-LIU family at all** ("Newly add 1 series 4MP fixed-focus +cameras: DS-2CD1XX7G3H-LIU"), a plausible day-one-bug candidate. Upgraded live to **`V5.11.0` build +260701** (over a year of firmware progress, incl. an intermediate `V5.8.21_SP1` release explicitly +noting "Fix network and image potential bugs to enhance device stability"). **Result: NO CHANGE.** +Post-upgrade, `channels/101/picture` still returns `HTTP 503 / statusCode 2 / deviceBusy`, 5/5 +consecutive attempts, byte-identical error body to pre-upgrade. Sub-stream (`102`) still healthy +(200, ~15KB) — camera is fine post-upgrade, just this one limitation persists. + +**Superseded finding, below: "durable hardware/encoder ceiling" was the wrong framing.** At this +point in the investigation it looked like a real capacity limit (reproduced across ~15 months of +firmware). The channel-sweep test below shows that's not what's actually happening. + +### The real cause: a broken/incomplete ISAPI snapshot handler, not "busy" (2026-08-23) + +`deviceBusy` never meant "busy." Swept every channel/stream ID against the snapshot endpoint in +one sitting, including IDs that don't exist on this camera at all: + +| channel | `GET .../channels//picture` | +|---|---| +| 1 | 503 `deviceBusy` | +| 100 | 503 `deviceBusy` | +| **101** (real main) | **503 `deviceBusy`** | +| **102** (real sub) | **200 OK** | +| 103 | 503 `deviceBusy` | +| 201 (channel 2 doesn't exist — single-channel camera) | 503 `deviceBusy` | +| 999 (garbage) | 503 `deviceBusy` | + +**Every ID fails identically except exactly `102`.** A genuinely busy/saturated encoder would not +succeed on one specific value and fail the same way on nonexistent channel IDs — a real resource +contention error would 404 or behave differently on garbage input, not return the identical `Device +Busy` XML body regardless of whether the target exists. This is the signature of a **generic +fallback error path**: the firmware's snapshot handler appears to only be correctly wired for +`102` (the one channel/stream combination Hikvision evidently tested for this SKU) and returns a +stock, misleading `deviceBusy` for every other case — valid main-stream `101` included. It is a +**firmware bug that mislabels itself as resource contention**, not a real capacity ceiling — which +also fits the firmware-upgrade non-result above (a wrong-code-path bug doesn't get fixed by +"more capacity," so no firmware version fixing it would be surprising). + +**Decision (2026-08-23): replace this camera line rather than build around it.** RTSP main-stream +capture is proven to work (see above) and could still be built as a `camera.ts` addition, but given +the ISAPI snapshot path is flatly broken for anything but one hardcoded channel value, and the +site's actual need (reliable plate reads — sub-stream alone isn't accurate enough) requires +full-resolution captures, the owner chose to swap out the `DS-2CD1047G3H-LIU` units rather than +carry a `ffmpeg`/RTSP dependency to route around a vendor firmware bug. The working `DS-2CD1043G2- +LIU` (`:8081` in the comparison above) has no such issue — ISAPI main-stream snapshot works +natively — and is the reference model for replacements. RTSP-frame-grab remains documented above +as a viable fallback if a `G3H`-family camera is ever unavoidable. + ## Clock sync — the 1970 power-cut reset (built 2026-07-07) Field observation (park-buzi): after a power cut these cameras come back with their clock at the diff --git a/wiki/index.md b/wiki/index.md index ccbcdd2..a6d6c1b 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -19,6 +19,7 @@ Counts: 4 sources · 19 entities · 47 concepts · 8 decision records. - [[dingtian-dt008]] — Dingtian DT-008 product page: QR/RFID access reader (QR/barcode + ID/IC/NFC; Wiegand/TCP-IP/USB/RS485; HTTP-GET push). - [[qrcode-sdk]] — QRCode SDK v1.6.5: the reader's HTTP-GET-poll protocol + JSON verdict (beep/output). - [[parksql2017-legacy-schema]] — predecessor SQL Server schema (Albanian market): legacy tariff/discount/membership/shift/fiscal model; confirms blocks, adds time-windows + categories, lacks postpaid sponsors. +- [[ds-2cd1047g3h-liu]] — HIKVISION DS-2CD1047G3H-LIU-F datasheet: 4MP, main stream has no MJPEG option (sub does) — likely explains the model's persistent ISAPI snapshot 503 on main; confirms ISAPI/RTSP both fully in-spec. ## Entities — technology stack - [[technology-stack]] — the full stack table; all MIT/Apache/BSD, chosen to avoid lock-in. @@ -39,7 +40,7 @@ Counts: 4 sources · 19 entities · 47 concepts · 8 decision records. - [[esp32-custom-controller]] — prevention-grade upgrade; device-level auth. - [[atecc608]] — secure element; non-extractable signing key (host events + controller auth). - [[wiegand]] — reader standard feeding the controller directly (autonomous permit-holder path). -- [[lpr-camera]] — edge-AI plate recognition; host-side casual-identity source. +- [[lpr-camera]] — edge-AI plate recognition; host-side casual-identity source; DS-2CD1047G3H-LIU main-stream ISAPI snapshot 503 is a firmware bug (only channel 102 ever works, ALL other IDs incl. garbage 503 identically) — firmware update tested, no fix; owner decided to replace the camera line rather than build an RTSP workaround. - [[dingtian-dt008-reader]] — Dingtian DT-008 QR/RFID reader on hand; host-side serial → `read` bus (the QR-ticket scanner). - [[zkteco-controller]] — ❌ rejected/historical; aux-input path was a contender, not pursued. - [[dingtian-relay]] — ✅ CHOSEN access controller; decoupled inputs solve the button blocker (driver verified on hardware); spare relays drive aux outputs (`setAux`). diff --git a/wiki/log.md b/wiki/log.md index 3aab68d..5afec6a 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -2619,3 +2619,57 @@ scanning (blocked on secure-context TLS for LAN phones + weak Code128-via-camera QR-on-ticket first) and a Tauri v2 Android merchant app (native ML Kit scanning via the official barcode-scanner plugin; deferred over Android build/distribution overhead + the configurable-server-URL prerequisite). Full analysis on [[validation-discounts]]. + +## [2026-08-23] ingest | HIKVISION DS-2CD1047G3H-LIU-F datasheet + +Vendor datasheet dropped in `raw/DS-2CD1047G3H-LIU.md`. Key new fact: main stream on this model +supports H.265+/H.265/H.264+/H.264 only — **no MJPEG**; sub-stream adds MJPEG. Likely mechanical +explanation for the persistent ISAPI main-stream snapshot 503 (`deviceBusy`) already logged on this +model in [[lpr-camera]] (2026-06-26/27): the on-demand JPEG snapshot has no native path on main, +so it has to transcode from H.264/H.265 live, which this SKU's firmware apparently can't do +reliably at 2560×1440. Bitrate spec (32Kbps–16Mbps) also confirms the site's main-stream config +(6144–12288Kbps) was never out of range — rules out misconfiguration definitively. + +## [2026-08-23] query | Main-stream 503: model-specific or config? RTSP as a workaround? + +Live-compared two Hikvision units at park-buzi via their public port forwards +(`park-buzi.msai.al:8081`/`:8082`) plus the `:8082` unit directly on the LAN (`10.0.10.13`). +Channel-101 (main) config is **byte-identical** between a working `DS-2CD1043G2-LIU` (8081, 200 OK) +and the failing `DS-2CD1047G3H-LIU` (8082 / `10.0.10.13`, persistent 503 `deviceBusy`, 3/3 retries +instant) — same resolution/bitrate/framerate/SmartCodec state. Rules out config as the cause; +confirms it's model/firmware-specific (matches the datasheet finding above). Then tested RTSP +(`rtsp://…@10.0.10.13:554/Streaming/Channels/101` via ffmpeg, TCP transport) against the SAME +failing camera: returned a valid 2560×1440 JPEG on the first try. RTSP taps the continuously- +running encode rather than asking for an on-demand re-encoded JPEG, so it sidesteps whatever the +ISAPI snapshot path chokes on. Not yet built into `camera.ts` (would add an `ffmpeg` child-process +dependency + RTSP auth/transport handling) — filed as a viable, proven fallback if full-resolution +main-stream stills are ever needed; sub-stream ISAPI snapshot remains sufficient for current ANPR +use. Full comparison table + RTSP command on [[lpr-camera]]. + +## [2026-08-23] update | Firmware update tested and ruled out; sub-stream confirmed too weak for ANPR — RTSP is now required + +Two developments on the DS-2CD1047G3H-LIU (`10.0.10.13`) main-stream 503: (1) the owner reports the +sub-stream (768×432) **fails to read plates "from time to time"** in real use — sub-stream-only is +no longer an acceptable mitigation, it's an accuracy problem. (2) Before building RTSP, tested +whether this was a day-one firmware bug: the camera's original `V5.8.11`/250415 build was confirmed +(via Hikvision's own release note) to be the FIRST H13U firmware to support this camera family at +all. Upgraded live to `V5.11.0`/260701 (~15 months newer, spanning an intermediate release that +explicitly claimed "image stability" fixes). Result: **no change** — identical `deviceBusy` 503, +5/5 attempts, post-upgrade. Firmware is now a ruled-out cause, not a theory; this looks like a real +encoder/hardware ceiling on this SKU. Next step: build the RTSP-based main-stream capture path into +`packages/devices/src/drivers/camera.ts` (not yet started). Full detail on [[lpr-camera]]. + +## [2026-08-23] update | Root cause nailed down: broken ISAPI handler, not "busy" — decision to REPLACE the camera line + +Final test on the DS-2CD1047G3H-LIU snapshot 503: swept every channel/stream ID against +`GET .../channels//picture`, including nonexistent ones (1, 100, 103, 201, 999). Every single +ID returns the identical `503 deviceBusy` body EXCEPT exactly `102` (the real sub-stream), which is +always 200. A real busy/saturated encoder would not succeed on one specific value while failing +garbage IDs identically — this is a generic fallback error: the firmware's snapshot handler is only +correctly wired for channel 102, and everything else (valid main-stream 101 included) falls through +to a stock, mislabeled "Device Busy" response. Confirms the firmware-upgrade non-result from +earlier today (a wrong-code-path bug wouldn't be fixed by more capacity). Owner's decision: replace +the DS-2CD1047G3H-LIU units rather than carry an RTSP/ffmpeg workaround dependency — the sibling +DS-2CD1043G2-LIU (no such bug, ISAPI main-stream snapshot works natively) is the reference model +going forward. RTSP main-stream capture remains documented as a proven, viable fallback if a G3H +camera is ever unavoidable, but is not being built. Full sweep table + reasoning on [[lpr-camera]]. diff --git a/wiki/raw/DS-2CD1047G3H-LIU.md b/wiki/raw/DS-2CD1047G3H-LIU.md new file mode 100644 index 0000000..db74114 --- /dev/null +++ b/wiki/raw/DS-2CD1047G3H-LIU.md @@ -0,0 +1,50 @@ +#### HIKVISION DS-2CD1047G3H-LIU-F 4 MP ColorVu 3.0 Fixed Bullet Network Camera + +![HIKVISION-DS-2CD1047G3H-LIU-F-4-MP-ColorVu-3.0-Fixed-Bullet-Network-Camera-PRODUCT](https://manuals.plus/wp-content/uploads/2025/07/HIKVISION-DS-2CD1047G3H-LIU-F-4-MP-ColorVu-3.0-Fixed-Bullet-Network-Camera-PRODUCT.png) + +#### FEATURE + +- HikAI-ISP for excellent noise reduction effect +- Super clear 24/7 colorful imaging with ColorVu 3.0 technology +- Motion Detection 3.0, more accurate on person and vehicle classification +- Strobe Light & Audio Alarm to deter intruders (optional) +- Two-Way Audio via camera and Hik-Connect +- Smart Hybrid Light: integrates IR and white lights, 3 supplemental lighting modes +- On-board storage with SD card up to 512 GB (optional) +- Water and dust resistant (IP67)![HIKVISION-DS-2CD1047G3H-LIU-F-4-MP-ColorVu-3.0-Fixed-Bullet-Network-Camera-FIG-1](https://manuals.plus/wp-content/uploads/2025/07/HIKVISION-DS-2CD1047G3H-LIU-F-4-MP-ColorVu-3.0-Fixed-Bullet-Network-Camera-FIG-1.png) + +#### Specification + +
n Specification
Camera
Max. Resolution2560 × 1440
Min. IlluminationColor: 0.0001 Lux @ (F1.0, AGC ON)
Shutter Time1 s to 1/100,000 s
Day & NightIR cut filter
Angle AdjustmentPan: 0° to 360°,tilt: 0° to 90°,rotate: 0° to 360°
Lens
Lens TypeFixed focal lens, 2.8 and 4 mm optional
Focal Length & FOV2.8 mm, horizontal FOV 104°, vertical FOV 54.4°, diagonal FOV 126.7°

4 mm, horizontal FOV 89.3°, vertical FOV 48.2°, diagonal FOV 106.5°

Lens MountM16
Iris TypeFixed
ApertureF1.0
Depth of Field2.8 mm: 2.5 m to ∞

4 mm: 2.8 m to ∞

DORI
DORI2.8 mm, D: 61 m, O: 24 m, R: 12 m, I: 6 m

4 mm, D: 68 m, O: 27 m, R: 13 m, I: 6 m

Illuminator
Supplement Light TypeIR,White Light
Supplement Light RangeIR: up to 30 m

White Light: up to 20 m

Smart Supplement LightYes
IR Wavelength850 nm
Video
 

 

Main Stream

50 Hz:

25 fps (2560 × 1440, 1920 × 1080, 1280 × 720)

60 Hz:

24 fps (2560 × 1440, 1920 × 1080, 1280 × 720)

Sub-Stream50 Hz: 25 fps (768 × 432, 640 × 360)

60 Hz: 24 fps (768 × 432, 640 × 360)

Video CompressionMain stream: H.265+/H.265/H.264+/H.264,

Sub-stream: H.265/H.264/MJPEG

Video Bit Rate32 Kbps to 16 Mbps
H.264 TypeBaseline Profile,Main Profile,High Profile
H.265 TypeMain Profile
Bit Rate ControlCBR,VBR
Scalable Video Coding (SVC)H.264 and H.265 encoding
Region of Interest (ROI)1 fixed region for main stream
Audio
Audio TypeMono sound
Audio CompressionG.711/G.722.1/G.726/MP2L2/PCM/MP3/AAC-LC
Audio Bit Rate64 Kbps (G.711)/16 Kbps (G.722.1)/16 Kbps (G.726)/32 to 160 Kbps (MP2L2)/16 to 64

Kbps (AAC-LC)

Audio Sampling Rate8 kHz/16 kHz
+ +
Environment Noise FilteringYes
Network
ProtocolsTCP/IP, ICMP, DHCP, DNS, HTTP, RTP, RTSP, RTCP, NTP, IPv4, IPv6, IGMP, UDP, QoS,

FTP, SMTP

Simultaneous Live ViewUp to 6 channels
APIONVIF (Profile S, Profile G),ISAPI,SDK
User/HostUp to 32 users

3 user levels: administrator, operator, and user

 

Security

Password protection, complicated password, watermark, basic and digest

authentication for HTTP, WSSE and digest authentication for Open Network Video

Interface, security audit log, host authentication (MAC address)

ClientiVMS-4200,Hik-Connect
Web BrowserPlug-in required live view: Chrome 80+, Firefox 80+, Edge 89+, Safari 13+,

Plug-in free live view: Chrome 80+, Firefox 80+, Edge 89+

Image
Image SettingsRotate  mode,saturation,brightness,contrast,sharpness,gain,white balance,adjustable

by client software or web browser

Day/Night SwitchDay,Night,Auto,Schedule
Wide Dynamic Range (WDR)120 dB
SNR≥ 52 dB
Image EnhancementBLC,HLC,3D DNR
Privacy Mask4 programmable polygon privacy masks
Interface
Ethernet Interface1 RJ45 10 M/100 M self-adaptive Ethernet port
 

 

 

 

 

 

 

 

On-Board Storage

DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-SL/SRB/LIUF:  Yes

-LIU: NA

Built-in MicrophoneYes,1 built-in microphone
+ +| Built-in Speaker | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-SL/SRB:  Yes \-LIU/LIUF: NA | +| --- | --- | +| Audio | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU:  NA | +| Alarm | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU:  NA | +| Reset Key | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-SL/SRB/LIUF:  Yes, \-LIU: NA | + +
Event
Basic EventMotion detection (support alarm triggering by specified target types (human and

vehicle)),video tampering alarm,exception

LinkageUpload to FTP,notify surveillance center,send email,trigger recording,trigger capture
General
PowerDS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU: 12 VDC ± 25%, 0.58 A, max. 7 W, Ø5.5 mm

coaxial power plug, reverse polarity protection, PoE: IEEE 802.3af, Class 3,max. 9 W LIUF: 12 VDC ± 25%, 0.67 A, max. 8 W, Ø5.5 mm coaxial power plug, reverse polarity protection, PoE: IEEE 802.3af, Class 3,max. 10 W

-SL/SRB: 12 VDC ± 25%, 0.84 A, max. 10.1 W, Ø5.5 mm coaxial power plug, reverse polarity protection, PoE: IEEE 802.3af, Class 3,max. 12.1 W

 

 

 

 

 

 

 

 

 

Dimension

DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU: 69.1 mm × 66.9 mm × 172.9 mm (2.7″ × 2.6″ ×

6.8″)

-LIUF/SL/SRB: 69.1 mm × 67.4 mm × 179 mm (2.7″ × 2.7″ × 7.1″)

 

Package Dimension210 mm × 116 mm × 106 mm (8.3″ × 4.6″ × 4.2″)
+ +| Weight | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU: Approx. 310 g (0.7 lb.) \-LIUF: Approx. 315 g (0.7 lb.) \-SL/SRB: Approx. 325 g (0.7 lb.) | +| --- | --- | +| With Package Weight | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-LIU: Approx. 465 g (1.0 lb.) \-LIUF: Approx. 470 g (1.0 lb.) \-SL/SRB: Approx. 495 g (1.1 lb.) | +| Storage Conditions | \-30 °C to 60 °C (-22 °F to 140 °F). Humidity 95% or less (non-condensing) | +| Startup and Operating Conditions | \-30 °C to 60 °C (-22 °F to 140 °F). Humidity 95% or less (non-condensing) | +| Language | English, Russian, Ukrainian, Arabic, Spanish, French, Portuguese, Turkish, Polish, German | +| General Function | Heartbeat,mirror,flash log,password reset via email,password protection,anti -banding | +| Flashing Light | DS-2CD1047G3H-LIU(F)(/SL)(/SRB):-SL/SRB:  Yes \-LIU/LIUF: NA | + +
Approval
EMCCE-EMC: EN 55032:2015+A1:2020, EN 50130-4:2011+A1:2014, EN IEC

61000-3-2:2019+A1:2021, EN  61000-3-3:2013+A1:2019+A2:2021

SafetyCB: IEC 62368-1: 2014+A11,

CE-LVD: EN 62368-1: 2014/A11: 2017

EnvironmentCE-RoHS: 2011/65/EU,

WEEE: 2012/19/EU

ProtectionIP67: IEC 60529-2013
+ +#### Available Model + +- DS-2CD1047G3H-LIUF/SRB(2.8mm) +- DS-2CD1047G3H-LIUF/SRB(4mm) +- DS-2CD1047G3H-LIU(2.8mm) +- DS-2CD1047G3H-LIU(4mm) +- DS-2CD1047G3H-LIUF(2.8mm) +- DS-2CD1047G3H-LIUF(4mm) +- DS-2CD1047G3H-LIUF/SL(2.8mm) +- DS-2CD1047G3H-LIUF/SL(4mm) \ No newline at end of file diff --git a/wiki/sources/ds-2cd1047g3h-liu.md b/wiki/sources/ds-2cd1047g3h-liu.md new file mode 100644 index 0000000..b8bb03e --- /dev/null +++ b/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.