@camstack/addon-provider-reolink 1.2.161 → 1.2.163
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/dist/addon.js +583 -17
- package/dist/addon.mjs +583 -17
- package/package.json +2 -2
package/dist/addon.mjs
CHANGED
|
@@ -5386,7 +5386,7 @@ var ZodIssueCode = {
|
|
|
5386
5386
|
var ZodFirstPartyTypeKind;
|
|
5387
5387
|
ZodFirstPartyTypeKind || (ZodFirstPartyTypeKind = {});
|
|
5388
5388
|
//#endregion
|
|
5389
|
-
//#region ../types/dist/sleep-
|
|
5389
|
+
//#region ../types/dist/sleep-COWaSCAi.mjs
|
|
5390
5390
|
/**
|
|
5391
5391
|
* The audio chunk plane's byte format, and the ONE expansion from a coded
|
|
5392
5392
|
* window to float samples (D455).
|
|
@@ -7602,6 +7602,24 @@ object({
|
|
|
7602
7602
|
unreachable: number()
|
|
7603
7603
|
})
|
|
7604
7604
|
});
|
|
7605
|
+
/** The wire shape of {@link PeerBytesTicket} — see the type for what it is. */
|
|
7606
|
+
var PeerBytesTicketSchema = object({
|
|
7607
|
+
/** `http://127.0.0.1:<port>/<token>`. One `GET` takes it. */
|
|
7608
|
+
url: string().min(1),
|
|
7609
|
+
/**
|
|
7610
|
+
* The HOST node this URL means something on — the hub or a named agent,
|
|
7611
|
+
* never a runner. {@link AddonPeerBytes.open} compares it to its own and
|
|
7612
|
+
* refuses `cross-node` by name when they differ, without dialling.
|
|
7613
|
+
*/
|
|
7614
|
+
hostNodeId: string().min(1),
|
|
7615
|
+
expiresAtMs: number().int().nonnegative(),
|
|
7616
|
+
/**
|
|
7617
|
+
* What the producer DECLARED the body to be, when it knows — `null` when it
|
|
7618
|
+
* does not. Never `0` for unknown (D393): a consumer sizing a bound off this
|
|
7619
|
+
* must be able to tell "the producer did not say" from "the body is empty".
|
|
7620
|
+
*/
|
|
7621
|
+
declaredBytes: number().int().nonnegative().nullable()
|
|
7622
|
+
});
|
|
7605
7623
|
/**
|
|
7606
7624
|
* Adoption job — the background form of `device-adoption.adopt`.
|
|
7607
7625
|
*
|
|
@@ -25347,6 +25365,7 @@ _enum([
|
|
|
25347
25365
|
"sleeping",
|
|
25348
25366
|
"camera-refused",
|
|
25349
25367
|
"no-keyframe",
|
|
25368
|
+
"decode-failed",
|
|
25350
25369
|
"no-catalog-row",
|
|
25351
25370
|
"unsupported",
|
|
25352
25371
|
"unknown-device",
|
|
@@ -25355,6 +25374,39 @@ _enum([
|
|
|
25355
25374
|
_enum(["deferred", "final"]);
|
|
25356
25375
|
/** The camera's / provider's own words. Kept verbatim, never parsed. */
|
|
25357
25376
|
var CLIP_STILL_REASON_HEADER = "x-camstack-reason";
|
|
25377
|
+
/**
|
|
25378
|
+
* Make a refusal sentence safe to put in an HTTP header.
|
|
25379
|
+
*
|
|
25380
|
+
* **An HTTP header value is Latin-1.** Node throws `Invalid character in
|
|
25381
|
+
* header content` on anything above U+00FF, the handler dies mid-response,
|
|
25382
|
+
* and the client gets a socket hang up — no status, no reason, nothing. The
|
|
25383
|
+
* mechanism that exists to EXPLAIN a refusal is then the thing that silences
|
|
25384
|
+
* it, and the surface shows "nothing happened".
|
|
25385
|
+
*
|
|
25386
|
+
* That is not hypothetical: measured 2026-09-23 on 1436, a Hikvision replay
|
|
25387
|
+
* refusal read `SETUP of the video track answered 500 — the camera refused
|
|
25388
|
+
* this replay`, and the EM DASH in it threw on every clip the operator
|
|
25389
|
+
* opened. This repository writes its refusals in prose, and its prose uses
|
|
25390
|
+
* `—`, `’` and `…` everywhere, so every reason string is a candidate.
|
|
25391
|
+
*
|
|
25392
|
+
* Substitutes rather than strips: an operator reading a log or a response
|
|
25393
|
+
* should get a readable sentence, not one with holes in it. The typographic
|
|
25394
|
+
* characters this repo actually writes have exact ASCII equivalents; anything
|
|
25395
|
+
* else non-Latin-1 becomes `?`, which is visible rather than silent. Control
|
|
25396
|
+
* characters go too — a newline in a header value is a response-splitting
|
|
25397
|
+
* bug, not a formatting one.
|
|
25398
|
+
*/
|
|
25399
|
+
function clipReasonHeaderValue(reason) {
|
|
25400
|
+
const folded = reason.replace(/[\u2013\u2014\u2212]/g, "-").replace(/[\u2018\u2019\u201b]/g, "'").replace(/[\u201c\u201d]/g, "\"").replace(/\u2026/g, "...").replace(/[\u00a0\u2007\u202f]/g, " ");
|
|
25401
|
+
let out = "";
|
|
25402
|
+
for (const ch of folded) {
|
|
25403
|
+
const code = ch.codePointAt(0) ?? 0;
|
|
25404
|
+
if (code < 32 || code === 127) out += " ";
|
|
25405
|
+
else if (code > 255) out += "?";
|
|
25406
|
+
else out += ch;
|
|
25407
|
+
}
|
|
25408
|
+
return out.slice(0, 500).trim();
|
|
25409
|
+
}
|
|
25358
25410
|
/** One {@link ClipStillRefusalCodeSchema} token, alone. */
|
|
25359
25411
|
var CLIP_STILL_REASON_CODE_HEADER = "x-camstack-reason-code";
|
|
25360
25412
|
/** One {@link ClipStillDispositionSchema} token, alone. */
|
|
@@ -25617,12 +25669,37 @@ var ClipWakeSchema = _enum(["authorised"]);
|
|
|
25617
25669
|
* the size in the message, never truncates. Half a video is worse than an
|
|
25618
25670
|
* honest refusal.
|
|
25619
25671
|
*
|
|
25620
|
-
*
|
|
25621
|
-
*
|
|
25622
|
-
*
|
|
25672
|
+
* **Superseded as the way a clip export gets its bytes** (D613). The bound is
|
|
25673
|
+
* a property of the ENVELOPE, not of clips, so the cure was a transport with
|
|
25674
|
+
* no envelope: {@link videoclipsCapability.methods.offerClipBytes} hands back
|
|
25675
|
+
* a one-shot `peerBytes` ticket and the consumer streams it straight to disk,
|
|
25676
|
+
* holding nothing. This method stays for a consumer that genuinely wants the
|
|
25677
|
+
* bytes in hand, and for a provider not yet redeployed — with this bound,
|
|
25678
|
+
* which for an inline read is not going to move.
|
|
25623
25679
|
*/
|
|
25624
25680
|
var VIDEOCLIPS_MAX_READ_BYTES = 50 * 1024 * 1024;
|
|
25625
25681
|
/**
|
|
25682
|
+
* Hard ceiling on ONE {@link videoclipsCapability.methods.offerClipBytes}
|
|
25683
|
+
* transfer — ten times {@link VIDEOCLIPS_MAX_READ_BYTES}, and the reasoning is
|
|
25684
|
+
* not "ten times more comfortable".
|
|
25685
|
+
*
|
|
25686
|
+
* The inline bound is set by what is HELD: a base64 envelope is the payload at
|
|
25687
|
+
* ~1.33× in the provider AND the same again in the caller, so 50 MiB of clip
|
|
25688
|
+
* is ~133 MiB of heap across two processes. Over `peerBytes` the consumer
|
|
25689
|
+
* holds one socket chunk at a time and writes straight through to the export
|
|
25690
|
+
* file, so its contribution is flat whatever the clip weighs. What is left is
|
|
25691
|
+
* the PRODUCER's own copy, and that is a property of how each provider makes a
|
|
25692
|
+
* clip rather than of this transport: Hikvision's fetch writes to a scratch
|
|
25693
|
+
* FILE and offers it (nothing is held), Reolink's cmd-5 transfer is collected
|
|
25694
|
+
* in memory and offered from there (one copy, the one it already had).
|
|
25695
|
+
*
|
|
25696
|
+
* So this number bounds the worst provider, not the transport, and it is named
|
|
25697
|
+
* separately so that lifting it is a statement about a provider rather than
|
|
25698
|
+
* about clips. Above it the provider REFUSES with the size in the message and
|
|
25699
|
+
* never truncates: half a video is worse than an honest refusal.
|
|
25700
|
+
*/
|
|
25701
|
+
var VIDEOCLIPS_MAX_OFFER_BYTES = 500 * 1024 * 1024;
|
|
25702
|
+
/**
|
|
25626
25703
|
* A clip's finished bytes, inline — the twin of `recordingExport.readExportBytes`.
|
|
25627
25704
|
*
|
|
25628
25705
|
* `bytes` is the DECODED length, so nobody infers it from the base64 length,
|
|
@@ -25654,6 +25731,32 @@ var ClipBytesSchema = object({
|
|
|
25654
25731
|
durationMs: number().positive().optional()
|
|
25655
25732
|
});
|
|
25656
25733
|
/**
|
|
25734
|
+
* Where a clip's finished bytes can be TAKEN (D613) — the answer to
|
|
25735
|
+
* {@link videoclipsCapability.methods.offerClipBytes}.
|
|
25736
|
+
*
|
|
25737
|
+
* Everything {@link ClipBytesSchema} carries except the bytes themselves, plus
|
|
25738
|
+
* the one-shot ticket that leads to them. The metadata is answered BEFORE the
|
|
25739
|
+
* transfer on purpose: a consumer learns which twin it got, what to call the
|
|
25740
|
+
* file and how long the clip runs without having to read a byte, so a decision
|
|
25741
|
+
* it would make on that metadata (a wrong twin, an implausible duration) costs
|
|
25742
|
+
* no transfer at all.
|
|
25743
|
+
*/
|
|
25744
|
+
var ClipBytesOfferSchema = object({
|
|
25745
|
+
/**
|
|
25746
|
+
* One shot, seconds-long, loopback, on the PROVIDER's own host. Open it with
|
|
25747
|
+
* `ctx.peerBytes.open(...)`, which refuses a ticket from another node by
|
|
25748
|
+
* name rather than dialling a port that means something else here.
|
|
25749
|
+
*/
|
|
25750
|
+
ticket: PeerBytesTicketSchema,
|
|
25751
|
+
contentType: string(),
|
|
25752
|
+
/** Suggested filename, extension included. */
|
|
25753
|
+
name: string(),
|
|
25754
|
+
/** Which twin was actually served — see {@link ClipBytesSchema.served}. */
|
|
25755
|
+
served: CamProfileSchema,
|
|
25756
|
+
/** See {@link ClipBytesSchema.durationMs}. Absent when nothing measured it. */
|
|
25757
|
+
durationMs: number().positive().optional()
|
|
25758
|
+
});
|
|
25759
|
+
/**
|
|
25657
25760
|
* Where a clip's STREAM can be dialled (D597) — the answer to
|
|
25658
25761
|
* {@link videoclipsCapability.methods.dialClipStream}.
|
|
25659
25762
|
*
|
|
@@ -25729,6 +25832,105 @@ var ClipStreamDialSchema = object({
|
|
|
25729
25832
|
/** Why `servedAudio` is `none` although sound was asked for. */
|
|
25730
25833
|
audioReason: ClipStreamAudioReasonSchema.optional()
|
|
25731
25834
|
});
|
|
25835
|
+
/**
|
|
25836
|
+
* The playback rates a clip can be DELIVERED at, ascending, always with `1`.
|
|
25837
|
+
*
|
|
25838
|
+
* These are the BROKER's: it re-paces frames it has already demuxed — the
|
|
25839
|
+
* `MonotonicClock` divides source elapsed time by the factor and the pacer
|
|
25840
|
+
* pushes that much faster — so the domain is the recorded one, {0} ∪ [0.25, 4],
|
|
25841
|
+
* and this is the discrete ladder drawn from it. `1.5` is in it because a
|
|
25842
|
+
* re-pacer has no reason to refuse it.
|
|
25843
|
+
*
|
|
25844
|
+
* `8` and `16` are deliberately NOT here. They are the CAMERA's own
|
|
25845
|
+
* `<playSpeed>` (Reolink cmd-5 replay), a different mechanism, still unwired
|
|
25846
|
+
* (D597, D600) — a rate change there costs a new dial and a new stream, and
|
|
25847
|
+
* the camera's 8x would need a resample the clip audio path has no decoder
|
|
25848
|
+
* for. Offering them today accepts a rate and delivers 1x, which is the whole
|
|
25849
|
+
* defect this list exists to end (D612). When `playSpeed` IS wired its rates
|
|
25850
|
+
* join THIS array — a second list elsewhere is the second authority D62
|
|
25851
|
+
* forbids.
|
|
25852
|
+
*
|
|
25853
|
+
* Every entry must survive the broker's `clampPlaybackRate` unchanged: a set
|
|
25854
|
+
* that offers what the clamp then moves is the same lie one step later.
|
|
25855
|
+
*/
|
|
25856
|
+
var CLIP_BROKER_PACED_RATES = [
|
|
25857
|
+
.25,
|
|
25858
|
+
.5,
|
|
25859
|
+
1,
|
|
25860
|
+
1.5,
|
|
25861
|
+
2,
|
|
25862
|
+
4
|
|
25863
|
+
];
|
|
25864
|
+
/**
|
|
25865
|
+
* The rates a REALTIME-BOUND stream can be delivered at.
|
|
25866
|
+
*
|
|
25867
|
+
* **Measured, and it is the whole reason this second ladder exists.** A
|
|
25868
|
+
* Hikvision RTSP replay is not a fast fetch: it delivers the recording at the
|
|
25869
|
+
* speed it was recorded. On 1436, 2026-09-23, one stream carried 176 access
|
|
25870
|
+
* units in 14 274 ms of wall clock at a measured 12.5 fps — 14.08 s of media
|
|
25871
|
+
* in 14.27 s, **1.01× realtime** — and a whole 18 s clip took 22.3 s to fetch
|
|
25872
|
+
* end to end. Reolink's cmd-5 transfer, which {@link CLIP_BROKER_PACED_RATES}
|
|
25873
|
+
* was written for, lands the same bytes at 49–62× and therefore has the entire
|
|
25874
|
+
* clip in hand within the first second.
|
|
25875
|
+
*
|
|
25876
|
+
* The broker's pacer consumes `rate` seconds of media per second of wall
|
|
25877
|
+
* clock while the socket supplies one. So at any rate above 1 the buffer
|
|
25878
|
+
* drains at `(rate − 1)×` and a stream that is only seconds old runs dry
|
|
25879
|
+
* almost at once — the viewer stops, the queue empties, and the provider's
|
|
25880
|
+
* own drain gate eventually reports `peer-stalled`. Nothing about that is a
|
|
25881
|
+
* bug to be fixed with a bigger buffer: there is no buffer, because the bytes
|
|
25882
|
+
* do not exist yet.
|
|
25883
|
+
*
|
|
25884
|
+
* So the honest answer is the DECLARATION (D612's own rule, applied to the
|
|
25885
|
+
* case it did not yet have): a rate this transport cannot deliver is never
|
|
25886
|
+
* offered. Below 1 is free — a slower pacer only lets the buffer grow.
|
|
25887
|
+
*
|
|
25888
|
+
* When a clip is served from a FILE the constraint is gone with the transport,
|
|
25889
|
+
* which is why `file` keeps the full ladder.
|
|
25890
|
+
*/
|
|
25891
|
+
var CLIP_REALTIME_SOURCE_RATES = [
|
|
25892
|
+
.25,
|
|
25893
|
+
.5,
|
|
25894
|
+
1
|
|
25895
|
+
];
|
|
25896
|
+
/**
|
|
25897
|
+
* What a surface may DRAW for this provider's clips — the answer to
|
|
25898
|
+
* {@link videoclipsCapability.methods.getPlaybackOptions} (D612).
|
|
25899
|
+
*
|
|
25900
|
+
* The envelope is a PROVIDER fact, not a clip fact, and that is measured, not
|
|
25901
|
+
* assumed: the broker's `chooseClipPath` reads exactly two inputs — whether
|
|
25902
|
+
* `dialClipStream` and `readClipBytes` are wired — and both are constants of
|
|
25903
|
+
* the broker's own closure over the provider's methods. The `profile` it is
|
|
25904
|
+
* handed is explicitly not read. So every clip of a provider is served the
|
|
25905
|
+
* same way, and a per-clip channel carried a value that could not vary. The
|
|
25906
|
+
* per-clip `clipTransport` server message was removed for exactly that reason.
|
|
25907
|
+
*
|
|
25908
|
+
* Queried per camera, before a clip is picked, so a control is rendered or
|
|
25909
|
+
* DISABLED rather than offered and refused at play time (D62: a disabled
|
|
25910
|
+
* control reads as unavailable, one that undoes the gesture reads as broken).
|
|
25911
|
+
*/
|
|
25912
|
+
var ClipPlaybackOptionsSchema = object({
|
|
25913
|
+
/**
|
|
25914
|
+
* How this provider's clips reach the player. `stream` is the provider's
|
|
25915
|
+
* forward-only fMP4 (D597); `file` is one bounded by-handle fetch of the
|
|
25916
|
+
* whole clip, `stbl` indexed (D575).
|
|
25917
|
+
*/
|
|
25918
|
+
transport: _enum(["stream", "file"]),
|
|
25919
|
+
/** `forward` = only ahead of the playhead. `free` = anywhere. */
|
|
25920
|
+
seek: _enum(["forward", "free"]),
|
|
25921
|
+
/** Frame-step BACKWARD is meaningful. Forward always is. */
|
|
25922
|
+
stepBack: boolean(),
|
|
25923
|
+
/** Whether the scrub gesture is served, as opposed to refused by name. */
|
|
25924
|
+
scrub: boolean(),
|
|
25925
|
+
/**
|
|
25926
|
+
* The rates that can be delivered, ascending, always containing `1`. The
|
|
25927
|
+
* viewer draws its picker from this and from nothing else — a constant it
|
|
25928
|
+
* keeps instead is the second authority that produced the defect: `8` and
|
|
25929
|
+
* `16` were offered, the broker clamped them to `4`, and no line anywhere
|
|
25930
|
+
* said so. `0` is not a member: pause is the absence of a rate.
|
|
25931
|
+
*/
|
|
25932
|
+
rates: array(number().positive()).min(1).readonly()
|
|
25933
|
+
});
|
|
25732
25934
|
var ClipSourceAvailabilitySchema = object({
|
|
25733
25935
|
state: _enum([
|
|
25734
25936
|
"ok",
|
|
@@ -25907,14 +26109,18 @@ var videoclipsCapability = {
|
|
|
25907
26109
|
*
|
|
25908
26110
|
* `getClipPlayback` is the right answer for a player: it hands back a URL
|
|
25909
26111
|
* on a plane the hub serves `access:'authenticated'`, which a browser and a
|
|
25910
|
-
* viewer session satisfy. It is the wrong answer for another ADDON
|
|
25911
|
-
*
|
|
25912
|
-
*
|
|
25913
|
-
*
|
|
25914
|
-
*
|
|
25915
|
-
*
|
|
25916
|
-
*
|
|
25917
|
-
*
|
|
26112
|
+
* viewer session satisfy. It is the wrong answer for another ADDON: the
|
|
26113
|
+
* hub's proxy in front of that plane takes only a user credential, which
|
|
26114
|
+
* an addon does not hold, so a recorder that wants a camera's clip cannot
|
|
26115
|
+
* fetch that URL. This method is the shape that answer forced — the same
|
|
26116
|
+
* one (and the same bound) as `recordingExport.readExportBytes`.
|
|
26117
|
+
*
|
|
26118
|
+
* **It is no longer the only seam.** Until D613 there was no addon→addon
|
|
26119
|
+
* byte transport at all; there is now
|
|
26120
|
+
* ({@link offerClipBytes}, over `ctx.peerBytes`), it holds nothing on
|
|
26121
|
+
* either side, and it is what a clip EXPORT uses. This method remains for
|
|
26122
|
+
* a consumer that genuinely wants the bytes in hand, and as the named
|
|
26123
|
+
* fallback for a provider not yet redeployed.
|
|
25918
26124
|
*
|
|
25919
26125
|
* Routing needs no `provider` pin: the id is source-prefixed and
|
|
25920
26126
|
* self-contained, so `device-collection-dispatch.ts` rule 3 hands the call
|
|
@@ -25981,6 +26187,65 @@ var videoclipsCapability = {
|
|
|
25981
26187
|
auth: "protected"
|
|
25982
26188
|
}),
|
|
25983
26189
|
/**
|
|
26190
|
+
* Where this clip's finished bytes can be TAKEN — the by-handle read a
|
|
26191
|
+
* clip EXPORT pulls, over the addon→addon byte transport (D613).
|
|
26192
|
+
*
|
|
26193
|
+
* This is {@link readClipBytes} with the envelope removed. Same gates,
|
|
26194
|
+
* same vocabulary, same completion rules, same `served` contract — the
|
|
26195
|
+
* only difference is that the bytes travel over a one-shot loopback
|
|
26196
|
+
* socket instead of inside a base64 field, so neither side holds the
|
|
26197
|
+
* payload whole and the 50 MiB refusal on a long `high` twin stops
|
|
26198
|
+
* existing. The bound that remains is
|
|
26199
|
+
* {@link VIDEOCLIPS_MAX_OFFER_BYTES}, and it bounds the PRODUCER's own
|
|
26200
|
+
* copy rather than the transport.
|
|
26201
|
+
*
|
|
26202
|
+
* **The ticket is loopback and same-host.** A provider on an agent mints a
|
|
26203
|
+
* URL that means nothing on the hub, and `ctx.peerBytes.open` refuses it
|
|
26204
|
+
* `cross-node` by name rather than dialling whatever else holds that port
|
|
26205
|
+
* here. A consumer that can be on the other side of a node boundary from
|
|
26206
|
+
* its provider must be able to read that refusal and say so; it must not
|
|
26207
|
+
* treat it as "no bytes".
|
|
26208
|
+
*
|
|
26209
|
+
* **A ticket is a one-shot bearer credential with a seconds-long life.**
|
|
26210
|
+
* Take it immediately, never persist it, never log its `url`. An untaken
|
|
26211
|
+
* ticket costs the provider one map entry until its TTL, and outstanding
|
|
26212
|
+
* tickets are bounded — which is also what makes a per-frame misuse of
|
|
26213
|
+
* this method refuse by name rather than work slowly (D9/D18: this is a
|
|
26214
|
+
* by-handle fetch of finished media, not a frame pipe).
|
|
26215
|
+
*
|
|
26216
|
+
* Optional on the provider for the same reason `readClipBytes` is: a
|
|
26217
|
+
* source with no camera socket behind it has no bytes. A provider that
|
|
26218
|
+
* predates this method answers `NOT_IMPLEMENTED`, and a consumer may fall
|
|
26219
|
+
* back to `readClipBytes` — but it says so in the log, with the deploy
|
|
26220
|
+
* hint, because that fallback re-imposes the 50 MiB refusal and an
|
|
26221
|
+
* operator who sees `too-large-to-transfer` after this shipped is looking
|
|
26222
|
+
* at a stale addon, not at a clip that cannot be exported.
|
|
26223
|
+
*/
|
|
26224
|
+
offerClipBytes: optionalMethod(object({
|
|
26225
|
+
deviceId: number(),
|
|
26226
|
+
clipId: string().min(1),
|
|
26227
|
+
/** WHICH provider holds the bytes — see `readClipBytes.provider`. */
|
|
26228
|
+
provider: string().min(1),
|
|
26229
|
+
/** Which twin — `low | mid` → the sub file, `high` → the main twin. */
|
|
26230
|
+
profile: CamProfileSchema.optional(),
|
|
26231
|
+
/**
|
|
26232
|
+
* The CALLER's byte bound, so an over-size clip is refused before the
|
|
26233
|
+
* camera is touched rather than after. Capped by
|
|
26234
|
+
* {@link VIDEOCLIPS_MAX_OFFER_BYTES} whatever is passed; absent means
|
|
26235
|
+
* that ceiling.
|
|
26236
|
+
*/
|
|
26237
|
+
maxBytes: number().int().positive().optional(),
|
|
26238
|
+
/**
|
|
26239
|
+
* The operator's authorisation to wake a sleeping camera for this
|
|
26240
|
+
* read. Absent — the default — means a sleeping standalone battery
|
|
26241
|
+
* camera is REFUSED by name, before any session is opened.
|
|
26242
|
+
*/
|
|
26243
|
+
wake: ClipWakeSchema.optional()
|
|
26244
|
+
}), ClipBytesOfferSchema, {
|
|
26245
|
+
kind: "query",
|
|
26246
|
+
auth: "protected"
|
|
26247
|
+
}),
|
|
26248
|
+
/**
|
|
25984
26249
|
* Where this clip's STREAM can be dialled (D597) — the forward-only
|
|
25985
26250
|
* fMP4 the provider writes from the first muxed byte, for the broker to
|
|
25986
26251
|
* play through the same WebRTC session as recorded footage, with the
|
|
@@ -26017,10 +26282,88 @@ var videoclipsCapability = {
|
|
|
26017
26282
|
}), ClipStreamDialSchema, {
|
|
26018
26283
|
kind: "query",
|
|
26019
26284
|
auth: "protected"
|
|
26285
|
+
}),
|
|
26286
|
+
/**
|
|
26287
|
+
* What a surface may DRAW for this provider's clips: the rates it can be
|
|
26288
|
+
* played at, whether scrub is served, how far a position may be moved,
|
|
26289
|
+
* and whether a backward frame-step means anything (D612).
|
|
26290
|
+
*
|
|
26291
|
+
* **The only authority.** The per-clip `clipTransport` server message
|
|
26292
|
+
* that used to carry the same answer was removed: the broker's transport
|
|
26293
|
+
* choice reads nothing that varies per clip, so the clip level had no
|
|
26294
|
+
* information the provider does not already have, and two channels that
|
|
26295
|
+
* can disagree are worse than one (D62).
|
|
26296
|
+
*
|
|
26297
|
+
* Asked per camera and per provider, so it must stay CHEAP — it is a
|
|
26298
|
+
* statement about wiring, answered from a constant, never a call to the
|
|
26299
|
+
* camera. A provider answers with one of {@link CLIP_PLAYBACK_OPTIONS}
|
|
26300
|
+
* and never composes an envelope of its own.
|
|
26301
|
+
*
|
|
26302
|
+
* Optional, and absence is load-bearing: a provider that has not answered
|
|
26303
|
+
* has not restricted anything, and a viewer reads it as the freedom it
|
|
26304
|
+
* always had. See D612 on the rollout order that absence implies.
|
|
26305
|
+
*/
|
|
26306
|
+
getPlaybackOptions: optionalMethod(object({
|
|
26307
|
+
deviceId: number(),
|
|
26308
|
+
/** WHICH provider to ask — the `addonId` a {@link ClipSourceSchema}
|
|
26309
|
+
* row carries. Required for the same reason `listClips` requires it:
|
|
26310
|
+
* a collection cap has no "the bound one" to resolve to (D554). */
|
|
26311
|
+
provider: string().min(1)
|
|
26312
|
+
}), ClipPlaybackOptionsSchema, {
|
|
26313
|
+
kind: "query",
|
|
26314
|
+
auth: "protected"
|
|
26020
26315
|
})
|
|
26021
26316
|
}
|
|
26022
26317
|
};
|
|
26023
26318
|
/**
|
|
26319
|
+
* NOTE ON PLACEMENT: this block lives AFTER the capability definition on
|
|
26320
|
+
* purpose. `scripts/lib/parse-cap.ts` finds a cap by the FIRST
|
|
26321
|
+
* `export const <X> = {` in the file, so an object literal declared above
|
|
26322
|
+
* `videoclipsCapability` is silently taken for the capability itself and
|
|
26323
|
+
* codegen emits a `DeviceProxy` entry that does not type-check. Found the
|
|
26324
|
+
* hard way, 2026-09-23.
|
|
26325
|
+
*/
|
|
26326
|
+
/**
|
|
26327
|
+
* The two envelopes, spelled ONCE.
|
|
26328
|
+
*
|
|
26329
|
+
* A provider answers with the entry for the transport its own wiring buys —
|
|
26330
|
+
* `stream` if it implements `dialClipStream`, `file` if it implements only
|
|
26331
|
+
* `readClipBytes` — and never composes one of its own. One table is what
|
|
26332
|
+
* makes "the provider may not promise what no clip can be given" structural
|
|
26333
|
+
* instead of a discipline: there is nothing else to promise.
|
|
26334
|
+
*/
|
|
26335
|
+
var CLIP_PLAYBACK_OPTIONS = {
|
|
26336
|
+
stream: {
|
|
26337
|
+
transport: "stream",
|
|
26338
|
+
seek: "forward",
|
|
26339
|
+
stepBack: false,
|
|
26340
|
+
scrub: false,
|
|
26341
|
+
rates: CLIP_BROKER_PACED_RATES
|
|
26342
|
+
},
|
|
26343
|
+
/**
|
|
26344
|
+
* A `stream` whose SOURCE runs at realtime — a Hikvision RTSP replay.
|
|
26345
|
+
*
|
|
26346
|
+
* Same verbs as `stream`, a shorter rate ladder, and the difference is a
|
|
26347
|
+
* measurement rather than a preference: see
|
|
26348
|
+
* {@link CLIP_REALTIME_SOURCE_RATES}. A third entry rather than a parameter,
|
|
26349
|
+
* because a provider must still be able to do nothing but NAME one of these.
|
|
26350
|
+
*/
|
|
26351
|
+
realtimeStream: {
|
|
26352
|
+
transport: "stream",
|
|
26353
|
+
seek: "forward",
|
|
26354
|
+
stepBack: false,
|
|
26355
|
+
scrub: false,
|
|
26356
|
+
rates: CLIP_REALTIME_SOURCE_RATES
|
|
26357
|
+
},
|
|
26358
|
+
file: {
|
|
26359
|
+
transport: "file",
|
|
26360
|
+
seek: "free",
|
|
26361
|
+
stepBack: true,
|
|
26362
|
+
scrub: true,
|
|
26363
|
+
rates: CLIP_BROKER_PACED_RATES
|
|
26364
|
+
}
|
|
26365
|
+
};
|
|
26366
|
+
/**
|
|
26024
26367
|
* Optional client-side hints sent at session creation to help the provider
|
|
26025
26368
|
* pick the best native source. All fields optional — a viewer that knows
|
|
26026
26369
|
* nothing still gets a sane default. (Relocated from the retired `webrtc`
|
|
@@ -47165,6 +47508,12 @@ Object.freeze({
|
|
|
47165
47508
|
addonId: null,
|
|
47166
47509
|
access: "view"
|
|
47167
47510
|
},
|
|
47511
|
+
"videoclips.getPlaybackOptions": {
|
|
47512
|
+
capName: "videoclips",
|
|
47513
|
+
capScope: "device",
|
|
47514
|
+
addonId: null,
|
|
47515
|
+
access: "view"
|
|
47516
|
+
},
|
|
47168
47517
|
"videoclips.listClips": {
|
|
47169
47518
|
capName: "videoclips",
|
|
47170
47519
|
capScope: "device",
|
|
@@ -47177,6 +47526,12 @@ Object.freeze({
|
|
|
47177
47526
|
addonId: null,
|
|
47178
47527
|
access: "view"
|
|
47179
47528
|
},
|
|
47529
|
+
"videoclips.offerClipBytes": {
|
|
47530
|
+
capName: "videoclips",
|
|
47531
|
+
capScope: "device",
|
|
47532
|
+
addonId: null,
|
|
47533
|
+
access: "view"
|
|
47534
|
+
},
|
|
47180
47535
|
"videoclips.readClipBytes": {
|
|
47181
47536
|
capName: "videoclips",
|
|
47182
47537
|
capScope: "device",
|
|
@@ -49223,6 +49578,11 @@ Object.freeze({
|
|
|
49223
49578
|
form: "single",
|
|
49224
49579
|
optional: false
|
|
49225
49580
|
}],
|
|
49581
|
+
"videoclips.getPlaybackOptions": [{
|
|
49582
|
+
name: "deviceId",
|
|
49583
|
+
form: "single",
|
|
49584
|
+
optional: false
|
|
49585
|
+
}],
|
|
49226
49586
|
"videoclips.listClips": [{
|
|
49227
49587
|
name: "deviceId",
|
|
49228
49588
|
form: "single",
|
|
@@ -49233,6 +49593,11 @@ Object.freeze({
|
|
|
49233
49593
|
form: "single",
|
|
49234
49594
|
optional: false
|
|
49235
49595
|
}],
|
|
49596
|
+
"videoclips.offerClipBytes": [{
|
|
49597
|
+
name: "deviceId",
|
|
49598
|
+
form: "single",
|
|
49599
|
+
optional: false
|
|
49600
|
+
}],
|
|
49236
49601
|
"videoclips.readClipBytes": [{
|
|
49237
49602
|
name: "deviceId",
|
|
49238
49603
|
form: "single",
|
|
@@ -79032,7 +79397,7 @@ var require_lz4 = /* @__PURE__ */ __commonJSMin(((exports) => {
|
|
|
79032
79397
|
};
|
|
79033
79398
|
}));
|
|
79034
79399
|
//#endregion
|
|
79035
|
-
//#region node_modules/@apocaliss92/nodelink-js/dist/chunk-
|
|
79400
|
+
//#region node_modules/@apocaliss92/nodelink-js/dist/chunk-7B2Z5FIA.js
|
|
79036
79401
|
var import_fxp = require_fxp();
|
|
79037
79402
|
var import_lz4 = /* @__PURE__ */ __toESM(require_lz4(), 1);
|
|
79038
79403
|
function encodeHeader(h) {
|
|
@@ -82541,6 +82906,7 @@ var BaichuanClient = class _BaichuanClient extends EventEmitter {
|
|
|
82541
82906
|
if (prev.superseded) continue;
|
|
82542
82907
|
prev.superseded = true;
|
|
82543
82908
|
this.logger?.warn?.(`[BaichuanClient] cmd 5 replay session #${prev.id} (channelId=${prev.discriminator.channelId}, ${prev.discriminator.kind}) superseded by #${this.replaySessionSeq + 1} after ${prev.acceptedFrames} accepted frame(s). Frames still in flight for #${prev.id} will be dropped, not handed to its successor.`);
|
|
82909
|
+
prev.onSuperseded?.(/* @__PURE__ */ new Error(`cmd 5 replay session #${prev.id} was superseded by a later transfer on this socket after ${prev.acceptedFrames} accepted frame(s)`));
|
|
82544
82910
|
}
|
|
82545
82911
|
const session = {
|
|
82546
82912
|
id: ++this.replaySessionSeq,
|
|
@@ -83263,6 +83629,10 @@ var BaichuanClient = class _BaichuanClient extends EventEmitter {
|
|
|
83263
83629
|
cleanup();
|
|
83264
83630
|
reject(e instanceof Error ? e : new Error(String(e)));
|
|
83265
83631
|
};
|
|
83632
|
+
session.onSuperseded = (reason) => {
|
|
83633
|
+
if (chunks.length > 0) finish(Buffer.concat(chunks));
|
|
83634
|
+
else fail(reason);
|
|
83635
|
+
};
|
|
83266
83636
|
const armIdleFinish = () => {
|
|
83267
83637
|
if (idleTimer) clearTimeout(idleTimer);
|
|
83268
83638
|
idleTimer = setTimeout(() => {
|
|
@@ -151596,7 +151966,7 @@ function writeRefusal(res, refusal, deviceId, logger, clipKey) {
|
|
|
151596
151966
|
else logger.debug(line, extras);
|
|
151597
151967
|
const retryAfterMs = refusal.disposition === "deferred" ? refusal.retryAfterMs : void 0;
|
|
151598
151968
|
res.writeHead(204, {
|
|
151599
|
-
[CLIP_STILL_REASON_HEADER]: refusal.reason
|
|
151969
|
+
[CLIP_STILL_REASON_HEADER]: clipReasonHeaderValue(refusal.reason),
|
|
151600
151970
|
[CLIP_STILL_REASON_CODE_HEADER]: refusal.code,
|
|
151601
151971
|
[CLIP_STILL_DISPOSITION_HEADER]: refusal.disposition,
|
|
151602
151972
|
...retryAfterMs === void 0 ? {} : { "retry-after": String(Math.max(1, Math.ceil(retryAfterMs / 1e3))) }
|
|
@@ -151793,7 +152163,7 @@ function createClipStreamHandler(deps) {
|
|
|
151793
152163
|
status: resolved.status
|
|
151794
152164
|
} });
|
|
151795
152165
|
res.writeHead(resolved.status, {
|
|
151796
|
-
[CLIP_STILL_REASON_HEADER]: resolved.detail
|
|
152166
|
+
[CLIP_STILL_REASON_HEADER]: clipReasonHeaderValue(resolved.detail),
|
|
151797
152167
|
[CLIP_STILL_REASON_CODE_HEADER]: resolved.code
|
|
151798
152168
|
});
|
|
151799
152169
|
res.end();
|
|
@@ -151866,7 +152236,7 @@ function createClipStreamHandler(deps) {
|
|
|
151866
152236
|
}
|
|
151867
152237
|
});
|
|
151868
152238
|
res.writeHead(streamRefusalStatus(outcome.code), {
|
|
151869
|
-
[CLIP_STILL_REASON_HEADER]: outcome.detail
|
|
152239
|
+
[CLIP_STILL_REASON_HEADER]: clipReasonHeaderValue(outcome.detail),
|
|
151870
152240
|
[CLIP_STILL_REASON_CODE_HEADER]: outcome.code
|
|
151871
152241
|
});
|
|
151872
152242
|
res.end();
|
|
@@ -152308,7 +152678,33 @@ function createClipStreamProducer(deps) {
|
|
|
152308
152678
|
}
|
|
152309
152679
|
});
|
|
152310
152680
|
activeByHost.set(hostKey, ahead + 1);
|
|
152311
|
-
|
|
152681
|
+
let abandonedAt = null;
|
|
152682
|
+
input.sink.onceClose(() => {
|
|
152683
|
+
abandonedAt ??= Date.now();
|
|
152684
|
+
});
|
|
152685
|
+
const queuedAt = Date.now();
|
|
152686
|
+
const run = (lanes.get(hostKey) ?? Promise.resolve()).then(async () => {
|
|
152687
|
+
if (abandonedAt !== null) {
|
|
152688
|
+
const waitedMs = abandonedAt - queuedAt;
|
|
152689
|
+
deps.logger.info("videoclips: a queued clip stream was dropped, its peer had gone", {
|
|
152690
|
+
tags: { deviceId },
|
|
152691
|
+
meta: {
|
|
152692
|
+
clipKey: input.row.clipKey,
|
|
152693
|
+
twin: input.twin,
|
|
152694
|
+
branch: "queued-peer-gone",
|
|
152695
|
+
waitedMs,
|
|
152696
|
+
aheadWhenQueued: ahead
|
|
152697
|
+
}
|
|
152698
|
+
});
|
|
152699
|
+
return {
|
|
152700
|
+
kind: "refused",
|
|
152701
|
+
code: "fetch-failed",
|
|
152702
|
+
detail: `the peer left after ${String(waitedMs)} ms in the queue, so this clip was never fetched`,
|
|
152703
|
+
attempts: 0
|
|
152704
|
+
};
|
|
152705
|
+
}
|
|
152706
|
+
return await runAttempts(input);
|
|
152707
|
+
}).finally(() => {
|
|
152312
152708
|
const left = (activeByHost.get(hostKey) ?? 1) - 1;
|
|
152313
152709
|
if (left <= 0) activeByHost.delete(hostKey);
|
|
152314
152710
|
else activeByHost.set(hostKey, left);
|
|
@@ -154538,6 +154934,118 @@ function createReolinkVideoclipsProvider(deps) {
|
|
|
154538
154934
|
};
|
|
154539
154935
|
},
|
|
154540
154936
|
/**
|
|
154937
|
+
* The same clip, over the addon→addon byte transport (D613).
|
|
154938
|
+
*
|
|
154939
|
+
* Every gate {@link readClipBytes} runs, in the same order and with the
|
|
154940
|
+
* same vocabulary — the id, the row, a clip still being written, the twin,
|
|
154941
|
+
* the size the ROW declares, and the sleep gate, which the producer
|
|
154942
|
+
* decides before `getApi()` because on UDP the login IS the wake. The one
|
|
154943
|
+
* difference is the envelope: the bytes leave over a one-shot loopback
|
|
154944
|
+
* socket instead of inside a base64 field, so the caller holds nothing and
|
|
154945
|
+
* this process holds the one copy the cmd-5 transfer already produced.
|
|
154946
|
+
*
|
|
154947
|
+
* The bound is {@link VIDEOCLIPS_MAX_OFFER_BYTES}: ten times the inline
|
|
154948
|
+
* one, because the inline one was paying for two inflated copies and this
|
|
154949
|
+
* pays for one plain one.
|
|
154950
|
+
*/
|
|
154951
|
+
offerClipBytes: async ({ deviceId, clipId, profile, maxBytes, wake }) => {
|
|
154952
|
+
const tags = { deviceId };
|
|
154953
|
+
const refuse = (code, detail, meta) => {
|
|
154954
|
+
deps.logger.warn("videoclips: refusing a clip byte offer", {
|
|
154955
|
+
tags,
|
|
154956
|
+
meta: {
|
|
154957
|
+
clipId,
|
|
154958
|
+
branch: code,
|
|
154959
|
+
...meta
|
|
154960
|
+
}
|
|
154961
|
+
});
|
|
154962
|
+
throw new Error(clipExportFailure(code, detail));
|
|
154963
|
+
};
|
|
154964
|
+
const parsed = parseClipId(clipId);
|
|
154965
|
+
if (parsed === null) return refuse("catalog-miss", `clip id "${clipId}" was not minted by the Reolink provider`, {});
|
|
154966
|
+
const clipKey = clipKeyFor(parsed.channel, parsed.fileName);
|
|
154967
|
+
const row = rowsByKey.get(`${deviceId}|${clipKey}`);
|
|
154968
|
+
if (row === void 0) return refuse("catalog-miss", `clip "${clipId}" is not in this node's catalog for device ${deviceId} — list the day that holds it first`, { clipKey });
|
|
154969
|
+
if (row.inProgress === true) return refuse("clip-in-progress", `clip "${clipId}" is still being written, so it has no end to export`, { clipKey });
|
|
154970
|
+
const chosen = chooseClipTwin(profile, row);
|
|
154971
|
+
if (chosen.downgraded) deps.logger.warn("videoclips: no main twin for this clip — serving the sub copy", {
|
|
154972
|
+
tags,
|
|
154973
|
+
meta: {
|
|
154974
|
+
clipId,
|
|
154975
|
+
clipKey,
|
|
154976
|
+
branch: "no-main-twin",
|
|
154977
|
+
asked: profile
|
|
154978
|
+
}
|
|
154979
|
+
});
|
|
154980
|
+
const twin = chosen.twin;
|
|
154981
|
+
const fileName = chosen.fileName;
|
|
154982
|
+
if (fileName === "") return refuse("no-file-for-window", `clip "${clipId}" is listed with no byte handle behind it`, {
|
|
154983
|
+
clipKey,
|
|
154984
|
+
twin
|
|
154985
|
+
});
|
|
154986
|
+
const served = chosen.served;
|
|
154987
|
+
const bound = Math.min(maxBytes ?? 524288e3, VIDEOCLIPS_MAX_OFFER_BYTES);
|
|
154988
|
+
const declaredBytes = twin === "main" ? row.mainBytes : row.subBytes;
|
|
154989
|
+
if (declaredBytes !== void 0 && declaredBytes > bound) return refuse("too-large-to-transfer", `the camera lists the ${twin} file of clip "${clipId}" as ${declaredBytes} bytes, over the ${bound}-byte bound for one transfer`, {
|
|
154990
|
+
clipKey,
|
|
154991
|
+
twin,
|
|
154992
|
+
declaredBytes,
|
|
154993
|
+
bound
|
|
154994
|
+
});
|
|
154995
|
+
const outcome = await deps.prepareOffer({
|
|
154996
|
+
deviceId,
|
|
154997
|
+
row,
|
|
154998
|
+
fileName,
|
|
154999
|
+
twin,
|
|
155000
|
+
...wake !== void 0 ? { wake } : {}
|
|
155001
|
+
});
|
|
155002
|
+
if (outcome.kind === "refused") throw new Error(clipExportFailure(outcome.code, outcome.detail));
|
|
155003
|
+
if (outcome.bytes > bound) return refuse("too-large-to-transfer", `clip "${clipId}" muxed to ${outcome.bytes} bytes, over the ${bound}-byte bound for one transfer`, {
|
|
155004
|
+
clipKey,
|
|
155005
|
+
twin,
|
|
155006
|
+
bytes: outcome.bytes,
|
|
155007
|
+
bound
|
|
155008
|
+
});
|
|
155009
|
+
deps.logger.info("videoclips: offered a Reolink clip by handle", {
|
|
155010
|
+
tags,
|
|
155011
|
+
meta: {
|
|
155012
|
+
clipId,
|
|
155013
|
+
clipKey,
|
|
155014
|
+
twin,
|
|
155015
|
+
served,
|
|
155016
|
+
asked: profile ?? null,
|
|
155017
|
+
bytes: outcome.bytes,
|
|
155018
|
+
durationMs: outcome.durationMs,
|
|
155019
|
+
wake: wake ?? "none"
|
|
155020
|
+
}
|
|
155021
|
+
});
|
|
155022
|
+
return {
|
|
155023
|
+
ticket: outcome.ticket,
|
|
155024
|
+
contentType: "video/mp4",
|
|
155025
|
+
name: clipFileLabel(fileName),
|
|
155026
|
+
served,
|
|
155027
|
+
...outcome.durationMs !== null ? { durationMs: outcome.durationMs } : {}
|
|
155028
|
+
};
|
|
155029
|
+
},
|
|
155030
|
+
/**
|
|
155031
|
+
* What a surface may DRAW for this camera's clips (D612).
|
|
155032
|
+
*
|
|
155033
|
+
* A CONSTANT, and it has to be: this method is asked per camera, and the
|
|
155034
|
+
* answer is a fact about which accessors this provider wires, not about
|
|
155035
|
+
* the camera. Every clip here reaches the player over
|
|
155036
|
+
* {@link dialClipStream}'s forward-only stream, so every clip gets the
|
|
155037
|
+
* `stream` envelope — measured, not assumed: the broker's `chooseClipPath`
|
|
155038
|
+
* reads only whether the dial and the file read are wired, and never the
|
|
155039
|
+
* clip or the profile.
|
|
155040
|
+
*
|
|
155041
|
+
* The rates are the BROKER's re-pacing ladder. The camera's own
|
|
155042
|
+
* `<playSpeed>` (8, 16) is real and still unwired (D597, D600): it would
|
|
155043
|
+
* ride on the dial and cost a new stream per change, and its audio has no
|
|
155044
|
+
* resampler on this path. When it is wired its rates join
|
|
155045
|
+
* `CLIP_BROKER_PACED_RATES` — not a second list here.
|
|
155046
|
+
*/
|
|
155047
|
+
getPlaybackOptions: async () => CLIP_PLAYBACK_OPTIONS.stream,
|
|
155048
|
+
/**
|
|
154541
155049
|
* Where this clip's STREAM is dialled (D597) — the same questions
|
|
154542
155050
|
* `readClipBytes` asks before the camera is touched (the id, the row, a
|
|
154543
155051
|
* file still being written), the same vocabulary, and NO fetch: the URL
|
|
@@ -155508,6 +156016,62 @@ function createClipService(deps) {
|
|
|
155508
156016
|
return outcome;
|
|
155509
156017
|
};
|
|
155510
156018
|
/**
|
|
156019
|
+
* The same clip, offered over the addon→addon byte transport (D613).
|
|
156020
|
+
*
|
|
156021
|
+
* It reuses {@link prepareBytes} whole — one fetch path, one set of
|
|
156022
|
+
* completion rules, one scratch. A second producer here would be the second
|
|
156023
|
+
* authority D558 refuses to create. What changes is only how the result
|
|
156024
|
+
* LEAVES: `offerBuffer` writes it to a one-shot loopback socket in bounded
|
|
156025
|
+
* chunks, honouring `write()`'s return (D447), instead of base64-ing it into
|
|
156026
|
+
* a cap envelope that the caller then copies again.
|
|
156027
|
+
*/
|
|
156028
|
+
const prepareOffer = async (input) => {
|
|
156029
|
+
const peerBytes = deps.peerBytes;
|
|
156030
|
+
if (peerBytes === void 0) {
|
|
156031
|
+
deps.logger.warn("videoclips: no peer-bytes transport on this node", {
|
|
156032
|
+
tags: { deviceId: input.deviceId },
|
|
156033
|
+
meta: {
|
|
156034
|
+
clipKey: input.row.clipKey,
|
|
156035
|
+
branch: "no-peer-bytes"
|
|
156036
|
+
}
|
|
156037
|
+
});
|
|
156038
|
+
return {
|
|
156039
|
+
kind: "refused",
|
|
156040
|
+
code: "fetch-failed",
|
|
156041
|
+
detail: "this node has no addon-to-addon byte transport wired"
|
|
156042
|
+
};
|
|
156043
|
+
}
|
|
156044
|
+
const outcome = await prepareBytes(input);
|
|
156045
|
+
if (outcome.kind === "refused") return outcome;
|
|
156046
|
+
const offered = await peerBytes.offerBuffer({
|
|
156047
|
+
bytes: outcome.bytes,
|
|
156048
|
+
contentType: "video/mp4",
|
|
156049
|
+
label: "reolink-clip",
|
|
156050
|
+
deviceId: input.deviceId
|
|
156051
|
+
});
|
|
156052
|
+
if (offered.kind === "refused") {
|
|
156053
|
+
deps.logger.warn("videoclips: the clip byte offer could not be minted", {
|
|
156054
|
+
tags: { deviceId: input.deviceId },
|
|
156055
|
+
meta: {
|
|
156056
|
+
clipKey: input.row.clipKey,
|
|
156057
|
+
branch: offered.code,
|
|
156058
|
+
detail: offered.detail
|
|
156059
|
+
}
|
|
156060
|
+
});
|
|
156061
|
+
return {
|
|
156062
|
+
kind: "refused",
|
|
156063
|
+
code: "fetch-failed",
|
|
156064
|
+
detail: `${offered.code}: ${offered.detail}`
|
|
156065
|
+
};
|
|
156066
|
+
}
|
|
156067
|
+
return {
|
|
156068
|
+
kind: "ok",
|
|
156069
|
+
ticket: offered.ticket,
|
|
156070
|
+
durationMs: outcome.durationMs,
|
|
156071
|
+
bytes: outcome.bytes.byteLength
|
|
156072
|
+
};
|
|
156073
|
+
};
|
|
156074
|
+
/**
|
|
155511
156075
|
* The STREAM's path (`clip-stream-route.ts`): the same gates, the same row,
|
|
155512
156076
|
* nothing written. Beside the file path, not in its place.
|
|
155513
156077
|
*/
|
|
@@ -155547,6 +156111,7 @@ function createClipService(deps) {
|
|
|
155547
156111
|
served: profile === "high" ? "high" : "low"
|
|
155548
156112
|
}),
|
|
155549
156113
|
prepareBytes,
|
|
156114
|
+
prepareOffer,
|
|
155550
156115
|
prepareStreamDial: async ({ deviceId, row, twin, audio }) => {
|
|
155551
156116
|
const gate = await gateClipDevice({
|
|
155552
156117
|
deviceId,
|
|
@@ -170225,6 +170790,7 @@ var ReolinkProviderAddon = class extends BaseDeviceProvider {
|
|
|
170225
170790
|
this.clipService = createClipService({
|
|
170226
170791
|
dataDir: this.ctx.dataDir,
|
|
170227
170792
|
logger: this.ctx.logger,
|
|
170793
|
+
...this.ctx.peerBytes !== void 0 ? { peerBytes: this.ctx.peerBytes } : {},
|
|
170228
170794
|
resolveDevice: async (deviceId) => {
|
|
170229
170795
|
const device = this.ctx.kernel.deviceRegistry?.getById(deviceId);
|
|
170230
170796
|
return device instanceof ReolinkCamera ? device.getClipDeviceRef() : null;
|