@camstack/system 1.2.260 → 1.2.262

package/dist/builtins/camera-grid/index.js

@@ -1587,23 +1587,64 @@ var PIXEL_FORMAT = "yuv420p";
 */
 var GOP_SECONDS = 1;
 /**
-* `-analyzeduration` / `-probesize`, well under ffmpeg's 5 s / 5 MB defaults.
+* `-analyzeduration` / `-probesize`, as small as ffmpeg allows.
 *
-* Safe on RTSP specifically: the SDP already declares the codec, so the probe
-* has nothing to discover. It matters more here than anywhere else in the repo
-* because the probes are PARALLEL inputs of one child — the composite emits
-* nothing until the LAST of them has finished, so the default budget is paid
-* once per grid, at the slowest source's pace.
+* ## The probes are SEQUENTIAL, and this is what the tile skew was
+*
+* The sentence that used to be here said the probes are "PARALLEL inputs of one
+* child". They are not. ffmpeg opens its inputs one after another and each open
+* BLOCKS in `avformat_find_stream_info` until its budget is spent — so input 0
+* is already connected and receiving while ffmpeg is still opening input 1, its
+* frames pile up, and `overlay` (which pairs inputs BY PTS) marries input 0's
+* oldest frame to input 1's newest. The lag is fixed for the life of the child:
+* both tiles then advance one frame per output frame, so nothing ever closes it.
+* The FIRST cell is the most behind; the last is live.
+*
+* Reproduced in one command on 2026-09-18 — two sources hstacked, one frame,
+* reading the cameras' own burnt-in clocks out of the composed picture:
+*
+* ```
+* 13:11:21 | 13:11:23      two seconds, and the earlier input is the late one
+* ```
+*
+* ## Why the old numbers cost seconds
+*
+* `-probesize` is a BYTE budget, and 1 MB of a 640x360 sub-stream is tens of
+* seconds of video — so `-analyzeduration 1s` never got the chance to stop it
+* and each open ran until the byte budget filled. Zero and 32 make the probe
+* return from the SDP, which already declares the codec, without reading media.
+*
+* Measured on this hub, the two sources of the live grid, three runs each,
+* production input args otherwise identical — time to the first composed frame,
+* and the skew read off the two burnt-in clocks in that frame:
+*
+* ```
+*   1 s / 1 MB     8986, 9728, 9712 ms      skew 5 s, 5 s, 4 s
+*   0   / 32       2281, 2270, 2304 ms      skew 1 s, 1 s, 0 s
+* ```
+*
+* The same numbers are the ~9 s cold start the operator had accepted: it was a
+* SUM of the opens, never the wait for the slowest source.
+*
+* Checked before shipping, because a probe that reads nothing has to survive
+* what it is not told: h264, h265 and a derived (`mid-to-low`) source all open
+* with `rc=0`, a 20 s run produces 200 frames of 200 either way (so the pacing
+* this file already lost once is untouched), and the skew is still 0 at 25 s
+* into a run — it is set at start-up and does not drift.
+*
+* What remains is the spread in when each source's first key frame arrives, and
+* a `/muted` dial waits for the next IDR. That spread is small here; if it ever
+* is not, the answer is to start the inputs from a join point we hold, NOT to
+* re-time the inputs (see `useWallclockTimestamps` below).
 */
-var ANALYZE_DURATION_US = 1e6;
-var PROBE_SIZE_BYTES = 1e6;
+var ANALYZE_DURATION_US = 0;
+var PROBE_SIZE_BYTES = 32;
 function inputPlanFor(source) {
 	return {
 		url: source.url,
 		rtspTransport: "tcp",
 		fflags: ["+discardcorrupt"],
 		lowDelay: true,
-		useWallclockTimestamps: true,
 		analyzeDurationUs: ANALYZE_DURATION_US,
 		probeSizeBytes: PROBE_SIZE_BYTES
 	};

package/dist/builtins/camera-grid/index.mjs

@@ -1582,23 +1582,64 @@ var PIXEL_FORMAT = "yuv420p";
 */
 var GOP_SECONDS = 1;
 /**
-* `-analyzeduration` / `-probesize`, well under ffmpeg's 5 s / 5 MB defaults.
+* `-analyzeduration` / `-probesize`, as small as ffmpeg allows.
 *
-* Safe on RTSP specifically: the SDP already declares the codec, so the probe
-* has nothing to discover. It matters more here than anywhere else in the repo
-* because the probes are PARALLEL inputs of one child — the composite emits
-* nothing until the LAST of them has finished, so the default budget is paid
-* once per grid, at the slowest source's pace.
+* ## The probes are SEQUENTIAL, and this is what the tile skew was
+*
+* The sentence that used to be here said the probes are "PARALLEL inputs of one
+* child". They are not. ffmpeg opens its inputs one after another and each open
+* BLOCKS in `avformat_find_stream_info` until its budget is spent — so input 0
+* is already connected and receiving while ffmpeg is still opening input 1, its
+* frames pile up, and `overlay` (which pairs inputs BY PTS) marries input 0's
+* oldest frame to input 1's newest. The lag is fixed for the life of the child:
+* both tiles then advance one frame per output frame, so nothing ever closes it.
+* The FIRST cell is the most behind; the last is live.
+*
+* Reproduced in one command on 2026-09-18 — two sources hstacked, one frame,
+* reading the cameras' own burnt-in clocks out of the composed picture:
+*
+* ```
+* 13:11:21 | 13:11:23      two seconds, and the earlier input is the late one
+* ```
+*
+* ## Why the old numbers cost seconds
+*
+* `-probesize` is a BYTE budget, and 1 MB of a 640x360 sub-stream is tens of
+* seconds of video — so `-analyzeduration 1s` never got the chance to stop it
+* and each open ran until the byte budget filled. Zero and 32 make the probe
+* return from the SDP, which already declares the codec, without reading media.
+*
+* Measured on this hub, the two sources of the live grid, three runs each,
+* production input args otherwise identical — time to the first composed frame,
+* and the skew read off the two burnt-in clocks in that frame:
+*
+* ```
+*   1 s / 1 MB     8986, 9728, 9712 ms      skew 5 s, 5 s, 4 s
+*   0   / 32       2281, 2270, 2304 ms      skew 1 s, 1 s, 0 s
+* ```
+*
+* The same numbers are the ~9 s cold start the operator had accepted: it was a
+* SUM of the opens, never the wait for the slowest source.
+*
+* Checked before shipping, because a probe that reads nothing has to survive
+* what it is not told: h264, h265 and a derived (`mid-to-low`) source all open
+* with `rc=0`, a 20 s run produces 200 frames of 200 either way (so the pacing
+* this file already lost once is untouched), and the skew is still 0 at 25 s
+* into a run — it is set at start-up and does not drift.
+*
+* What remains is the spread in when each source's first key frame arrives, and
+* a `/muted` dial waits for the next IDR. That spread is small here; if it ever
+* is not, the answer is to start the inputs from a join point we hold, NOT to
+* re-time the inputs (see `useWallclockTimestamps` below).
 */
-var ANALYZE_DURATION_US = 1e6;
-var PROBE_SIZE_BYTES = 1e6;
+var ANALYZE_DURATION_US = 0;
+var PROBE_SIZE_BYTES = 32;
 function inputPlanFor(source) {
 	return {
 		url: source.url,
 		rtspTransport: "tcp",
 		fflags: ["+discardcorrupt"],
 		lowDelay: true,
-		useWallclockTimestamps: true,
 		analyzeDurationUs: ANALYZE_DURATION_US,
 		probeSizeBytes: PROBE_SIZE_BYTES
 	};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camstack/system",
-  "version": "1.2.260",
+  "version": "1.2.262",
   "description": "Core addon for CamStack — builtins, pipeline, process management, auth, logging, events",
   "keywords": [
     "camstack",