@camstack/system 1.2.269 → 1.2.270

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

@@ -2279,6 +2279,24 @@ function buildGridTilePlan(input) {
 /** See D527: the probe returns from the SDP instead of reading media. */
 var ANALYZE_DURATION_US$1 = 0;
 var PROBE_SIZE_BYTES$1 = 32;
+/**
+* Threads per child, and why they are BOUNDED rather than automatic.
+*
+* ffmpeg's default is one thread per core, applied to decode, the filter graph
+* and the output — and it applies it per CHILD. A compositor has N+1 of them,
+* so on the hub's 20-core CPU two tiles reading 640x360 sub-streams were
+* measured holding 71 and 56 threads (2026-09-18). That is not a CPU problem:
+* the container's pid cgroup counts THREADS, its ceiling is 2048, and it was
+* sitting at 1858. Every new `pthread_create` then fails with EAGAIN, which
+* ffmpeg reports as `ff_frame_thread_encoder_init failed` — the grid stopped
+* working, and nothing about the message says "out of pids".
+*
+* A tile decodes one small stream and scales it once; one thread does that at a
+* few percent of a core (measured: 2.2-2.4%). The encoder gets a few more
+* because it is the only piece whose work scales with the canvas.
+*/
+var TILE_THREADS = 1;
+var ENCODER_THREADS = 4;
 var PRESET$1 = "veryfast";
 var TUNE$1 = "zerolatency";
 var GOP_SECONDS$1 = 1;
@@ -2302,7 +2320,7 @@ function gridTileDecoderInvocation(input) {
 			fps: input.fps
 		},
 		audio: { kind: "none" },
-		threadCount: 0,
+		threadCount: TILE_THREADS,
 		outputArgs: [],
 		sink: {
 			kind: "stdout",
@@ -2337,7 +2355,7 @@ function gridCanvasEncoderInvocation(input) {
 		},
 		video,
 		audio: { kind: "none" },
-		threadCount: 0,
+		threadCount: ENCODER_THREADS,
 		outputArgs: [],
 		sink: {
 			kind: "stdout",

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

@@ -2274,6 +2274,24 @@ function buildGridTilePlan(input) {
 /** See D527: the probe returns from the SDP instead of reading media. */
 var ANALYZE_DURATION_US$1 = 0;
 var PROBE_SIZE_BYTES$1 = 32;
+/**
+* Threads per child, and why they are BOUNDED rather than automatic.
+*
+* ffmpeg's default is one thread per core, applied to decode, the filter graph
+* and the output — and it applies it per CHILD. A compositor has N+1 of them,
+* so on the hub's 20-core CPU two tiles reading 640x360 sub-streams were
+* measured holding 71 and 56 threads (2026-09-18). That is not a CPU problem:
+* the container's pid cgroup counts THREADS, its ceiling is 2048, and it was
+* sitting at 1858. Every new `pthread_create` then fails with EAGAIN, which
+* ffmpeg reports as `ff_frame_thread_encoder_init failed` — the grid stopped
+* working, and nothing about the message says "out of pids".
+*
+* A tile decodes one small stream and scales it once; one thread does that at a
+* few percent of a core (measured: 2.2-2.4%). The encoder gets a few more
+* because it is the only piece whose work scales with the canvas.
+*/
+var TILE_THREADS = 1;
+var ENCODER_THREADS = 4;
 var PRESET$1 = "veryfast";
 var TUNE$1 = "zerolatency";
 var GOP_SECONDS$1 = 1;
@@ -2297,7 +2315,7 @@ function gridTileDecoderInvocation(input) {
 			fps: input.fps
 		},
 		audio: { kind: "none" },
-		threadCount: 0,
+		threadCount: TILE_THREADS,
 		outputArgs: [],
 		sink: {
 			kind: "stdout",
@@ -2332,7 +2350,7 @@ function gridCanvasEncoderInvocation(input) {
 		},
 		video,
 		audio: { kind: "none" },
-		threadCount: 0,
+		threadCount: ENCODER_THREADS,
 		outputArgs: [],
 		sink: {
 			kind: "stdout",

package/package.json

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