@7365admin1/core 3.32.2-staging.61 → 3.32.2-staging.63
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.changeset/camera-functions-for-patrol.md +42 -0
- package/.changeset/camera-monitoring-wall.md +32 -0
- package/dist/index.d.ts +541 -1
- package/dist/index.js +6668 -5861
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +6435 -5660
- package/dist/index.mjs.map +1 -1
- package/package.json +3 -2
- package/test/camera-view.util.test.mjs +475 -0
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": minor
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Camera functions for Virtual Patrol, proxied server-side.
|
|
6
|
+
|
|
7
|
+
Adds authenticated camera endpoints so the apps can use a site camera without ever
|
|
8
|
+
holding its credential. Dahua devices authenticate with digest and the cleartext
|
|
9
|
+
password on every request (HTTP API V3.37 §3.4) and the specification offers no
|
|
10
|
+
session or usable token, so the only safe shape is a server-side proxy.
|
|
11
|
+
|
|
12
|
+
- `useCameraViewController` — snapshot, snapshot-to-file for evidence, and
|
|
13
|
+
per-recorder health.
|
|
14
|
+
- A camera record does not hold a device address: `site.cameras.host` is the CCTV
|
|
15
|
+
relay's page URL and its numeric last path segment is the stream channel. A
|
|
16
|
+
camera is therefore resolved as **recorder (from `CAMERA_RTSP_DEVICES`, keyed by
|
|
17
|
+
relay authority) + channel (from the stored host)**. The address and credential
|
|
18
|
+
live in deployment configuration only — never in the database, never in a client.
|
|
19
|
+
- Pictures come off the video stream (one `ffmpeg` frame per snapshot, substream
|
|
20
|
+
for a tile, main stream for an evidence capture). The recorder in use exposes
|
|
21
|
+
RTSP only; its HTTP CGI ports are not reachable, so `snapshot.cgi`, firmware
|
|
22
|
+
(§4.6.14), device clock (§4.6.2) and PTZ (§8.1.5) cannot be used against it.
|
|
23
|
+
Firmware and clock are reported as unavailable with a reason, and PTZ refuses.
|
|
24
|
+
`GET /site-cameras/capabilities` reports `ptz: false` whatever
|
|
25
|
+
`CAMERA_PTZ_ENABLED` says, so a client hides the control rather than drawing a
|
|
26
|
+
pad whose every press fails.
|
|
27
|
+
- A camera whose relay has no configured recorder, or whose address carries no
|
|
28
|
+
channel, is refused up-front with a reason rather than failing as a blank picture.
|
|
29
|
+
- At most `CAMERA_MAX_CONCURRENT_GRABS` (4) pictures are taken at once across the
|
|
30
|
+
process, so the endpoint cannot fill the API host with ffmpeg or overpull the
|
|
31
|
+
recorder; over that, the caller is told the cameras are busy.
|
|
32
|
+
- Access is decided by the caller's site/org membership and their role's
|
|
33
|
+
permissions, never by the camera id in the URL.
|
|
34
|
+
- ANPR units are refused: ANPR belongs to visitor and vehicle management, not to
|
|
35
|
+
Virtual Patrol or CCTV.
|
|
36
|
+
- Camera host, username, password and the RTSP URL are never returned and never
|
|
37
|
+
logged; ffmpeg's stderr is discarded because it echoes the credential.
|
|
38
|
+
- No retry on a camera call: the device locks an account for 1800 s after 3
|
|
39
|
+
failures in 30 s (§4.7.x).
|
|
40
|
+
|
|
41
|
+
Requires `ffmpeg` on the API host (or `CAMERA_FFMPEG_PATH`); where it is absent the
|
|
42
|
+
snapshot endpoints answer with "Video tooling is not available on this server."
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
"@7365admin1/core": minor
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
CCTV monitoring wall: a site-scoped camera list and a batched health sweep.
|
|
6
|
+
|
|
7
|
+
Two additions to the camera proxy so a supervisor can watch a whole site rather
|
|
8
|
+
than one checkpoint at a time.
|
|
9
|
+
|
|
10
|
+
`getSiteWall` returns the cameras of one site from `site.cameras` - the
|
|
11
|
+
collection the real cameras are in - together with the polling intervals and
|
|
12
|
+
fan-out caps the client should use. No device is contacted, so opening a wall is
|
|
13
|
+
one database read. Entitlement is by site membership, not by the id in the URL,
|
|
14
|
+
and a caller outside the site gets the same answer as one asking for a site that
|
|
15
|
+
does not exist.
|
|
16
|
+
|
|
17
|
+
`getSiteHealth` probes the cameras currently on screen with at most
|
|
18
|
+
`CAMERA_WALL_MAX_CONCURRENT_PROBES` in flight. Reachability is a **per-recorder**
|
|
19
|
+
answer, cached per recorder: twelve of this estate's cameras are twelve channels
|
|
20
|
+
on one device, so a full wall is one connect rather than one per tile. It never
|
|
21
|
+
throws for a camera that is down; unreachable is the answer, and a camera whose
|
|
22
|
+
relay has no configured recorder is refused with a reason instead.
|
|
23
|
+
|
|
24
|
+
Firmware version and device clock are reported as unavailable with a reason: they
|
|
25
|
+
are HTTP CGI facts and the recorder in use exposes RTSP only.
|
|
26
|
+
|
|
27
|
+
Snapshots now record when a camera last returned a picture, so a tile can say
|
|
28
|
+
"last frame 40 minutes ago" instead of "never".
|
|
29
|
+
|
|
30
|
+
New, all optional and conservative by default: `CAMERA_WALL_POLL_MS` (5000),
|
|
31
|
+
`CAMERA_SINGLE_POLL_MS` (2000), `CAMERA_WALL_MAX_TILES` (9),
|
|
32
|
+
`CAMERA_WALL_MAX_CONCURRENT_PROBES` (4), `CAMERA_HEALTH_CACHE_SECONDS` (20).
|