@torrent-tv/proxy 2.54.0 → 2.55.1

package/CHANGELOG.md

@@ -1,3 +1,19 @@
+## 2.55.1
+
+- **Fix**: A source is now keyed by its own infohash, not by a hash of the request bytes. A magnet URI and a `.torrent` file for the same content are different bytes, so the old key (`sha1` of the source) named the same film as two unrelated sources — measured 2026-08-19, `a518ff46…` and `7ab2fb5d…` for one infohash `11f09299…` — sharing neither the swarm, nor a cache, nor any work already downloaded, and surfacing as `WebTorrent client error: Cannot add duplicate torrent`. The new key (`services/torrent-source-key.js`) reads the infohash straight out of the magnet's `btih` or the `.torrent`'s own `info` dictionary via `parse-torrent`, synchronously, with no network round trip — so both forms of the same torrent now share one entry from the first request, on both the pool's own map (`torrent-pool.js`) and the worker-thread boundary (`torrent-worker/pool-adapter.js`), instead of relying on WebTorrent's own duplicate-add error to reconcile them after the fact.
+- **Chore**: The decode-cost reading now logs how many MB/s the pipe was actually fed against how many MB/s the measured speed implies were needed (item 4(d2)) — a divergence between the two is worth a second look before trusting the reading. A `write()`-return-value signal was tried first, to say outright whether the pipe or the decoder was the limit, and measured false on every reading taken while building it — including clips this host decodes at 15-80x with slack to spare — so it does not discriminate and was not shipped; only the byte count, which is real, is kept.
+
+## 2.55.0
+
+- **Fix**: The decode calibration was measuring the loop rather than the decode. It looped each clip with `-stream_loop -1`, and a loop is not free: measured 2026-08-22, a restart costs **0.03 s on the 480p clip and 0.12 s on the 1080p one** — it scales with the picture, so it is the decoder tearing down and re-allocating its frame buffers rather than anything about reading the file. A five-second clip decoded at 55x restarts eleven times a second, and that cost dominated the reading: the same clips measured 53.7x looped against 80.3x in one continuous pass, and 11.8x against 15.8x. Worse, the bias depends on BOTH the clip's own resolution and the host's speed — the two axes the fit exists to separate — so it did not cancel out, it tilted the fit. That is the fast-host failure recorded on 2026-08-20, where a desktop read 1080p at 9.35 Mbit/s as cheaper than 720p at 9.94, an ordering no decoder produces, and the H.264 fit refused to solve at all. A host that could not fit H.264 got no decode figure whatsoever, which is exactly the host most able to serve.
+- **New**: The clip is fed to the decoder as ONE Annex-B elementary stream, written to its stdin over and over. Parameter sets are inline in Annex-B and it can be joined by plain byte concatenation — that is what a broadcast is — so more bytes are simply more stream: nothing re-opens, nothing re-initialises, and there is no restart inside the measured window. The lift out of the container is a copy, not a re-encode, and it goes straight to a pipe: no temporary media is written at any point. Error against the continuous-pass truth is now −0.2 % and −5.5 %, with the readings spread 2-6 %, against −25 % and −33 % for the loop. Every reading on the developer's desktop moved, by up to 66 %, and they are monotonic in both axes for the first time.
+- **New**: The measured window is half a second instead of one. What used to make a long window necessary was the clip restarting inside it; with the stream continuous, the only thing left to average over is the timing jitter of two progress lines, which is milliseconds. Measured at half a second: −3.0 % and +0.6 %.
+- **Fix**: The contention penalty was wrong for the same reason. It compares a decode alone against the same decode beside an encoder, and both readings carried the loop, but not equally — the machine's speed differs between them. Decoding alone now reads 77.5x where it read about 53x.
+- **Chore**: A codec family's clips are lifted out of their containers in ONE ffmpeg run, and the startup is shorter than before rather than longer. The lift is a copy, so its cost is almost entirely the process: one per clip added 11 s here, and running them concurrently did not help — six at once took 4.75 s against 0.89 s for one, so the machine serialises them. One run with many inputs and many outputs costs one process. Measured end to end on the same desktop, alternating old and new: **35.3 s before, 31.6 s after**, with the readings corrected. The contention benchmark lifts its clip once and decodes the same bytes three times instead of lifting it again for each reading. Done before the measurements and never beside them: a remux running next to a decode is a second job on the machine, and this benchmark exists to find out what one job costs.
+- **Fix**: The lift has a time bound and is killed on it. It was the only ffmpeg run in this file without one, and it is awaited before the proxy's tunnel opens — so a remux that never exited was a startup that never finished, with nothing said. Its failures, and the decode's, now carry ffmpeg's own last line instead of "said nothing".
+- **Fix**: A codec family with no Annex-B mapping fails by name instead of being lifted with H.264's filter. This matters for what comes next: AV1 has no Annex-B form at all — its packaging is OBU — and MPEG-2 and VC-1 have no `*_mp4toannexb` filter, so all three of the families the roadmap plans need another route through here, and finding that out as "the clip failed" would send the reader after the clip.
+- **Chore**: `test/decode-measurement.test.js` states the orderings the readings must have — a bigger picture costs more than a smaller one at the same bitrate, a thicker stream more than a thin one at the same size, HEVC more than H.264 — rather than any number, since the numbers belong to whatever machine runs them. Those are the properties the loop inverted, and nothing was checking them.
+
 ## 2.54.0
 
 - **Fix**: The automatic quality step no longer changes the SIZE of the picture underneath a session the browser is already decoding. The fMP4 init segment is fetched once — a player reads `#EXT-X-MAP` and never asks again — and `avc1` keeps SPS and PPS in it rather than in the fragments, so every fragment produced after a size change was decoded against parameter sets describing a picture that was no longer being made. Measured 2026-08-21 across five viewing attempts: both re-encoded sessions of the five were destroyed by it. On `LXH-12.TS` the encoder left 1280x720 for 960x540 at 13:30:06 and the browser went on reporting `decode … size=1280x720` for the next three and a half minutes — 67 readings, not one of them 960x540 — while the viewer watched a band of macroblock garbage over a smeared field. On `c0930.com_chijyo0073.wmv` the same act at 13:35:36 made the element error on the first mismatched fragment, close the MediaSource, throw `bufferAppendError InvalidStateError` on both tracks and sit at `size=0x0 readyState=0` for four and a half minutes. Which of the two happens is the decoder's choice, not ours, and no layer reported an error either time. A change of resolution is a change of VARIANT, as the standard has it: every height is already published in the master with its own init, so the proxy now ASKS the browser to move — the same act the manual menu performs, which has never had this fault.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.54.0",
+  "version": "2.55.1",
   "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
   "license": "GPL-3.0-or-later",
   "publishConfig": {
@@ -35,6 +35,7 @@
     "franc": "^6.2.0",
     "get-port": "^7.1.0",
     "node-datachannel": "^0.32.0",
+    "parse-torrent": "^11.0.23",
     "uint8-util": "2.2.6",
     "webtorrent": "2.8.5",
     "werift": "^0.24.2",

package/research/preset-benchmark-size-scaling-2026-08-22.md

@@ -0,0 +1,55 @@
+# Does the preset benchmark's pixels/sec figure hold at a different size? (2026-08-22)
+
+Roadmap item 4(e): the software-preset benchmark (`benchmarkSoftwarePresets`,
+`services/hwaccel.js`) measures encoder throughput at one fixed reference size —
+640×360 — and every later use of that figure (deciding which quality rungs this
+host can sustain) scales it by pixel count, assuming cost per pixel is constant
+regardless of frame size. This was never checked against a second size.
+
+## Measurement
+
+Same clip (`cal-h264-1080-hi.mp4`), same `libx264` presets, same measurement
+method as the shipped benchmark (slope between two `-progress` reports,
+excluding startup) — run once at the existing 640×360 reference and once at
+1280×720 (4× the pixel count), on the developer's desktop:
+
+| preset    | 640×360        | 1280×720       | ratio (should be ~1.0) |
+|-----------|----------------|----------------|-------------------------|
+| ultrafast | 1322.8 Mpx/s   | 588.6 Mpx/s    | 0.445                   |
+| fast      | 176.6 Mpx/s    | 128.1 Mpx/s    | 0.725                   |
+
+Script: ad-hoc, not committed (reused the benchmark's own ffmpeg arguments at a
+second `-vf scale=`/`-s` size; available on request if this needs re-running).
+
+## Reading
+
+The assumption does not hold. Cost per pixel RISES with frame size on this
+host — by 2.25× for `ultrafast`, 1.38× for `fast`, at 4× the pixel count — and
+the effect is preset-dependent, not a single constant. A quality ladder priced
+from the 640×360 figure alone over-states what this host can sustain at 1080p,
+worse for the faster presets that the ladder falls back to under load.
+
+## Why this does not become a code change yet
+
+One host, one clip, two sizes. [[feedback_pool_diversity]] — a correction fitted
+to this desktop and applied to every proxy in the pool would be exactly the
+mistake that memory exists to prevent: the pool spans ARM boards (HA Yellow /
+CM4) with different cache sizes and memory bandwidth, where a size penalty of
+this shape could be smaller, larger, or absent. [[feedback_no_fudged_numbers]] —
+publishing 0.445/0.725 as universal constants is fabricating a number for hosts
+that were never measured.
+
+The benchmark already measures per-host (item 4(f), 4(h)); a size-scaling
+correction belongs there too — the benchmark itself gains a second, cheap
+measurement point (one preset, one second size) and derives its own exponent
+from that host's two readings, the same way `fitDecodeCost` derives its terms
+from clips rather than from a stated formula. That is the remaining work under
+item 4(e); this note is the measurement that justifies doing it, not the fix
+itself.
+
+## What is verified
+
+The measurement method matches the shipped benchmark exactly (real footage,
+raw frames decoded once, slope between two progress reports) — the only
+variable changed was the target size, so this is not comparing two different
+methodologies.

package/services/hwaccel.js

@@ -22,6 +22,7 @@
 
 import { spawn } from "node:child_process";
 import { mkdtempSync, readdirSync, rmSync, statSync } from "node:fs";
+import { mkdtemp, readFile, rm } from "node:fs/promises";
 import os from "node:os";
 import path from "node:path";
 import { fitDecodeCost } from "./decode-cost-fit.js";
@@ -763,10 +764,20 @@ const CALIBRATION_SETS = {
 const CALIBRATION_CLIPS = CALIBRATION_SETS.h264;
 const CALIBRATION_DIR = path.join(path.dirname(fileURLToPath(import.meta.url)), "..", "assets", "calibration");
 // How wide the measured window must be before the slope is trusted, and how
-// long to wait for it at most. A second of decoding is thousands of frames on a
-// quick host and dozens on a weak one; both give a slope, and neither costs the
-// startup more than a second per clip.
-const DECODE_WINDOW_MIN_SEC = 1;
+// long to wait for it at most.
+//
+// Half a second, and it is the TIMING noise that sets it rather than the amount
+// of video: the slope is output time against wall time, both read from the same
+// two progress lines, and the jitter in stamping one is milliseconds — so half
+// a second of window is a fraction of a percent of error on any host. What used
+// to make a longer window necessary was the clip restarting inside it, and that
+// is gone: the stream is continuous now. Measured 2026-08-22 against the
+// continuous-pass truth on a desktop: -3.0 % and +0.6 % at half a second, with
+// the readings spread 2-6 %, against -25 % and -33 % for the loop it replaces.
+// Half a second also costs the startup about 0.6 s per clip less, which matters
+// because every clip of every codec family is paid for before any viewer
+// exists.
+const DECODE_WINDOW_MIN_SEC = 0.5;
 const DECODE_WINDOW_MAX_MS = 8000;
 
 /**
@@ -844,8 +855,18 @@ export async function benchmarkContention({ ffmpegBin, logger, clipsDir = CALIBR
   // company, not the clip's own cost, so the smallest one says it soonest.
   const clip = path.join(clipsDir, "cal-h264-480-lo.mp4");
   const startedAt = Date.now();
-  const alone = await measureDecodeSlope(ffmpegBin, clip);
-  if (!alone) {
+  // Lifted once and decoded three times from the same bytes. Going through
+  // `measureDecodeSlope` lifted it again for every reading — three process
+  // starts on a path that is awaited before the proxy's tunnel opens, for a
+  // remux whose result had not changed.
+  const streams = await extractFamilyStreams(ffmpegBin, [clip], "h264");
+  const stream = streams?.[0];
+  if (!stream) {
+    log.warn("hwaccel: contention could not be measured; costs will be added as though jobs were independent");
+    return null;
+  }
+  const alone = await decodePipedStream(ffmpegBin, stream, log);
+  if (!alone?.speed) {
     log.warn("hwaccel: contention could not be measured; costs will be added as though jobs were independent");
     return null;
   }
@@ -871,8 +892,8 @@ export async function benchmarkContention({ ffmpegBin, logger, clipsDir = CALIBR
       await new Promise((resolve) => {
         setTimeout(resolve, 2_000);
       });
-      const withCompany = await measureDecodeSlope(ffmpegBin, clip);
-      if (withCompany) {
+      const withCompany = await decodePipedStream(ffmpegBin, stream, log);
+      if (withCompany?.speed) {
         beside.push({ others, speed: withCompany.speed });
       }
     }
@@ -947,10 +968,29 @@ async function fitOneFamily({ ffmpegBin, log, clipsDir, family, clips }) {
   const startedAllAt = Date.now();
   /** @type {Array<{ megapixelsPerSecond: number, megabitsPerSecond: number, costSecondsPerSecond: number }>} */
   const samples = [];
-  for (const clip of clips) {
-    const measured = await measureDecodeSlope(ffmpegBin, path.join(clipsDir, clip));
-    if (!measured) {
-      log.warn(`hwaccel: decode benchmark "${clip}" failed or said nothing; ${family} not measured`);
+  // Every clip of the family is lifted out of its container FIRST, in one
+  // ffmpeg run. See `extractFamilyStreams` for why one run rather than one per
+  // clip, and why before the measurements rather than beside them.
+  const streams = await extractFamilyStreams(
+    ffmpegBin,
+    clips.map((clip) => path.join(clipsDir, clip)),
+    family
+  );
+  if (!streams) {
+    log.warn(
+      `hwaccel: ${family} cannot be lifted out of its container — no Annex-B filter is mapped for it, ` +
+        `so its clips were never measured`
+    );
+    return null;
+  }
+  for (const [index, clip] of clips.entries()) {
+    const stream = streams[index];
+    const measured = stream ? await decodePipedStream(ffmpegBin, stream, log) : null;
+    if (!measured?.speed) {
+      log.warn(
+        `hwaccel: decode benchmark "${clip}" said nothing; ${family} not measured` +
+          (measured?.error ? ` — ${measured.error}` : " — the clip could not be lifted out of its container")
+      );
       return null;
     }
     const cost = 1 / measured.speed;
@@ -984,88 +1024,372 @@ async function fitOneFamily({ ffmpegBin, log, clipsDir, family, clips }) {
 }
 
 /**
- * Measure how fast this host DECODES a clip, from ffmpeg’s own report of how
+ * The bitstream filter and demuxer that turn a clip's video track into a
+ * continuous elementary stream, by codec family.
+ *
+ * H.264 and HEVC in MP4 keep their parameter sets in the container's `avcC` /
+ * `hvcC` and their access units length-prefixed; Annex-B carries them inline,
+ * with start codes, which is what makes plain byte concatenation a valid
+ * stream. That is the property this whole measurement rests on.
+ */
+const ANNEX_B_BY_FAMILY = {
+  h264: { filter: "h264_mp4toannexb", demuxer: "h264" },
+  hevc: { filter: "hevc_mp4toannexb", demuxer: "hevc" },
+  hevc10: { filter: "hevc_mp4toannexb", demuxer: "hevc" }
+};
+
+/**
+ * The last complaint in an ffmpeg stderr, for a line that has to say why.
+ *
+ * @param {string} stderr
+ * @returns {string}
+ */
+function lastErrorLine(stderr) {
+  const lines = String(stderr ?? "")
+    .split(/\r?\n/)
+    .map((line) => line.trim())
+    .filter((line) => line.length > 0);
+  return lines[lines.length - 1] ?? "";
+}
+
+/**
+ * How long the lift may take before it is abandoned. It is a remux of a few
+ * megabytes, so this is not a budget — it is the difference between a startup
+ * that reports a failure and one that never finishes. Every other ffmpeg run in
+ * this file has such a bound; this one did not, and it is awaited before the
+ * proxy's tunnel opens.
+ */
+const EXTRACT_TIMEOUT_MS = 20_000;
+
+/**
+ * Lift a whole family's clips out of their containers, as Annex-B elementary
+ * streams, in ONE ffmpeg run.
+ *
+ * No re-encoding — the frames are copied — so the work itself is trivial and
+ * the cost is almost entirely the process. Doing one process per clip added
+ * 11 s to the startup here (fourteen clips at about 0.83 s each), and running
+ * them concurrently did not help: six at once took 4.75 s against 0.89 s for
+ * one, so the machine serialises them. One run with many inputs and many
+ * outputs costs one process.
+ *
+ * The outputs go to temporary files because several outputs cannot share one
+ * pipe; they are read into memory and deleted immediately, and nothing about
+ * this measurement is kept between runs.
+ *
+ * Before the measurements, never beside them: a remux running next to a decode
+ * is a second job on the machine, and this benchmark exists to find out what
+ * ONE job costs here.
+ *
+ * @param {string} ffmpegBin
+ * @param {string[]} clipPaths
+ * @param {string} family
+ * @returns {Promise<Array<{ bytes: Buffer, demuxer: string, megapixelsPerSecond: number, megabitsPerSecond: number, fps: number } | null> | null>}
+ *   One entry per clip, in order; null when the family cannot be lifted at all.
+ */
+async function extractFamilyStreams(ffmpegBin, clipPaths, family) {
+  const shape = ANNEX_B_BY_FAMILY[family];
+  // A family with no mapping is a hard failure, not a silent fallback to
+  // H.264's filter. AV1 has no Annex-B form at all (its packaging is OBU), and
+  // MPEG-2 and VC-1 have no `*_mp4toannexb` filter — so the three families the
+  // roadmap plans next cannot come through here, and finding that out as
+  // "the clip failed" would send the reader after the clip.
+  if (!shape) {
+    return null;
+  }
+  const workDir = await mkdtemp(path.join(os.tmpdir(), "ttv-calibration-"));
+  const outputs = clipPaths.map((_, index) => path.join(workDir, `stream-${index}.${shape.demuxer}`));
+  /** @type {string[]} */
+  const args = ["-hide_banner", "-loglevel", "info", "-nostats", "-y"];
+  for (const clipPath of clipPaths) {
+    args.push("-i", clipPath);
+  }
+  for (const [index, output] of outputs.entries()) {
+    args.push("-map", `${index}:v:0`, "-c:v", "copy", "-bsf:v", shape.filter, "-f", shape.demuxer, output);
+  }
+  const stderr = await runCapturingStderr(ffmpegBin, args, EXTRACT_TIMEOUT_MS);
+  try {
+    if (stderr === null) {
+      return null;
+    }
+    // One banner block per input, in the order they were given. Read rather
+    // than declared, so replacing a clip cannot silently invalidate the fit
+    // that rests on it.
+    const blocks = splitInputBlocks(stderr, clipPaths.length);
+    return await Promise.all(clipPaths.map(async (_, index) => {
+      const block = blocks[index];
+      if (!block) {
+        return null;
+      }
+      const clipInfo = parseClipCharacteristics(block);
+      const fps = parseFfmpegVideoFps(block);
+      if (!clipInfo || !(fps > 0)) {
+        return null;
+      }
+      let bytes;
+      try {
+        bytes = await readFile(outputs[index]);
+      } catch {
+        return null;
+      }
+      if (bytes.length === 0) {
+        return null;
+      }
+      return {
+        bytes,
+        demuxer: shape.demuxer,
+        megapixelsPerSecond: clipInfo.megapixelsPerSecond,
+        megabitsPerSecond: clipInfo.megabitsPerSecond,
+        fps
+      };
+    }));
+  } finally {
+    await rm(workDir, { recursive: true, force: true }).catch(() => {});
+  }
+}
+
+/**
+ * The part of an ffmpeg banner describing each input, in order.
+ *
+ * ffmpeg prints one `Input #N, …` block per input and then the stream mapping;
+ * the parsers here read a single input's facts, so they are given a single
+ * input's text rather than the whole banner.
+ *
+ * @param {string} stderr
+ * @param {number} count
+ * @returns {string[]}
+ */
+function splitInputBlocks(stderr, count) {
+  /** @type {string[]} */
+  const blocks = [];
+  for (let index = 0; index < count; index += 1) {
+    const from = stderr.indexOf(`Input #${index},`);
+    if (from < 0) {
+      blocks.push("");
+      continue;
+    }
+    const nextInput = stderr.indexOf(`Input #${index + 1},`, from);
+    const mapping = stderr.indexOf("Stream mapping:", from);
+    const ends = [nextInput, mapping].filter((at) => at > from);
+    blocks.push(stderr.slice(from, ends.length > 0 ? Math.min(...ends) : stderr.length));
+  }
+  return blocks;
+}
+
+/**
+ * Run ffmpeg to completion and return its stderr, or null when it failed or
+ * outlasted its bound.
+ *
+ * @param {string} ffmpegBin
+ * @param {string[]} args
+ * @param {number} timeoutMs
+ * @returns {Promise<string | null>}
+ */
+function runCapturingStderr(ffmpegBin, args, timeoutMs) {
+  return new Promise((resolve) => {
+    let stderr = "";
+    let settled = false;
+    let child;
+    const settle = (value) => {
+      if (settled) {
+        return;
+      }
+      settled = true;
+      clearTimeout(timer);
+      try {
+        child?.kill("SIGKILL");
+      } catch {
+        // already gone
+      }
+      resolve(value);
+    };
+    const timer = setTimeout(() => settle(null), timeoutMs);
+    try {
+      child = spawn(ffmpegBin, args, { stdio: ["ignore", "ignore", "pipe"], windowsHide: true });
+    } catch {
+      settle(null);
+      return;
+    }
+    child.stderr.on("data", (chunk) => {
+      stderr += String(chunk);
+    });
+    child.on("error", () => settle(null));
+    child.on("close", (code) => settle(code === 0 ? stderr : null));
+  });
+}
+
+/**
+ * Measure how fast this host DECODES a clip, from ffmpeg's own report of how
  * much video it has processed.
  *
- * Wall-clock around the process cannot answer this: starting ffmpeg costs about
- * a second, and on a quick machine a five-second clip decodes in a tenth of
- * that, so the measurement would be of the program starting. Progress lines
- * arrive twice a second AFTER it has started, and the slope between two of them
- * — video processed against time taken — contains no part of the startup by
- * construction.
+ * Two things are deliberately outside the measurement.
+ *
+ * **The process starting.** Wall-clock around the process cannot answer this:
+ * starting ffmpeg costs about a second, and on a quick machine a five-second
+ * clip decodes in a tenth of that, so the measurement would be of the program
+ * starting. Progress lines arrive AFTER it has started, and the slope between
+ * two of them — video processed against time taken — contains no part of the
+ * startup by construction.
+ *
+ * **The clip restarting.** This used to loop the clip with `-stream_loop -1`,
+ * and a loop is not free: measured 2026-08-22 on a desktop, a restart costs
+ * 0.03 s on the 480p clip and 0.12 s on the 1080p one — the decoder tearing
+ * down and re-allocating its frame buffers, which is why the price rises with
+ * the picture. A five-second clip decoded at 55x restarts eleven times a
+ * second, so that cost DOMINATED the reading: the same clips measured 53.7x
+ * looped against 80.3x in one continuous pass, and 11.8x against 15.8x. Worse,
+ * the bias is not shared — it depends on the clip's own resolution and on how
+ * fast the host is — so it does not cancel out of the fit, it tilts it. That is
+ * the fast-host failure recorded on 2026-08-20, where 1080p read cheaper than
+ * 720p, which is not a thing a decoder does.
  *
- * The clip is looped forever and the process killed as soon as the window is
- * wide enough, so the cost is bounded by the clock rather than by the clip:
- * roughly a second of measurement on any host, quick or slow.
+ * So the clip is fed to the decoder as ONE stream instead. An Annex-B
+ * elementary stream carries its parameter sets inline, so writing the same
+ * bytes again is simply more stream — the decoder never re-initialises, and
+ * there is no restart inside the window to measure. Verified against the
+ * continuous-pass truth on the same host: -0.2 % and -5.5 %, against -25 % and
+ * -33 % for the loop. Nothing is written to disk and the process is killed as
+ * soon as the window is wide enough.
+ *
+ * Exported because the property that broke here is checkable and was not being
+ * checked: a bigger picture must cost more than a smaller one of the same
+ * bitrate, and under the loop it did not.
  *
  * @param {string} ffmpegBin
  * @param {string} clipPath
+ * @param {string} [family="h264"]
+ * @returns {Promise<{ speed: number, windowSec: number, megapixelsPerSecond: number, megabitsPerSecond: number } | null>}
+ */
+export async function measureDecodeSlope(ffmpegBin, clipPath, family = "h264") {
+  const streams = await extractFamilyStreams(ffmpegBin, [clipPath], family);
+  const stream = streams?.[0];
+  if (!stream) {
+    return null;
+  }
+  const measured = await decodePipedStream(ffmpegBin, stream);
+  return measured?.speed ? measured : null;
+}
+
+/**
+ * Decode an elementary stream fed from memory, and report the slope.
+ *
+ * @param {string} ffmpegBin
+ * @param {{ bytes: Buffer, demuxer: string, megapixelsPerSecond: number, megabitsPerSecond: number, fps: number }} stream
  * @returns {Promise<{ speed: number, windowSec: number, megapixelsPerSecond: number, megabitsPerSecond: number } | null>}
  */
-function measureDecodeSlope(ffmpegBin, clipPath) {
+function decodePipedStream(ffmpegBin, stream, log = { info: () => {}, warn: () => {} }) {
   return new Promise((resolve) => {
     const args = [
-      "-hide_banner", "-loglevel", "info", "-nostats",
-      "-stream_loop", "-1",
-      "-i", clipPath,
+      "-hide_banner", "-loglevel", "error", "-nostats",
+      // A raw stream states no frame rate, so the one the container declared is
+      // given back to it. It decides how output time advances, and therefore
+      // what "seconds of video per second of clock" means.
+      "-f", stream.demuxer, "-framerate", String(stream.fps), "-i", "pipe:0",
       "-an", "-f", "null", "-",
       "-progress", "pipe:1"
     ];
     /** @type {Array<{ wallSec: number, outSec: number }>} */
     const samples = [];
-    let stderr = "";
     let stdout = "";
+    // Kept because this path depends on three things the old one did not: the
+    // raw demuxer accepting the frame rate, the bitstream filter having
+    // produced something parsable, and the fed concatenation being decodable.
+    // Without it the only trace of any of those failing is "said nothing".
+    let stderr = "";
     let settled = false;
     let child;
     const startedAt = Date.now();
+    // Whether the FEED, not the decoder, could be what this reading measures
+    // (item 4(d2)). `child.stdin.write()` returning false was tried as the
+    // signal — never once true would mean this process was never ahead of the
+    // pipe — and measured false on every reading taken while writing this,
+    // including clips this same host decodes at 15-80x with room to spare, so
+    // it does not discriminate: `write()`'s return value tracks Node's own
+    // internal watermark against the size of what was just handed to it, not
+    // real drain state, and answered "no slack" identically whether the pipe
+    // or the decoder was the true limit. Rather than publish a verdict that
+    // reads the same in both cases, only the byte count is kept, for the
+    // MB/s figure below — a number to read, not a boolean to trust.
+    let bytesWritten = 0;
     const finish = () => {
       if (settled) {
         return;
       }
       settled = true;
       clearTimeout(timer);
+      try {
+        child?.stdin?.destroy();
+      } catch {
+        // already gone
+      }
       try {
         child?.kill("SIGKILL");
       } catch {
         // already gone
       }
-      // The first sample is the one that still carries the startup — it reports
-      // whatever was processed while the process was coming up. Everything is
-      // measured from the second onwards.
+      // The first sample still carries the startup — it reports whatever was
+      // processed while the process was coming up. Everything is measured from
+      // the second onwards.
       const first = samples[1];
       const last = samples[samples.length - 1];
-      const clipInfo = parseClipCharacteristics(stderr);
-      if (!first || !last || !clipInfo) {
-        resolve(null);
+      if (!first || !last) {
+        resolve({ error: lastErrorLine(stderr) || "the decoder reported no progress" });
         return;
       }
       const windowSec = last.wallSec - first.wallSec;
       const producedSec = last.outSec - first.outSec;
       if (!(windowSec >= DECODE_WINDOW_MIN_SEC) || !(producedSec > 0)) {
-        resolve(null);
+        resolve({ error: lastErrorLine(stderr) || `the window was ${windowSec.toFixed(2)}s of ${producedSec.toFixed(2)}s produced` });
         return;
       }
+      const speed = producedSec / windowSec;
+      // Diagnostic only — logged, not acted on. The required rate is what
+      // THIS reading implies was needed to keep the decoder fed; the achieved
+      // rate is what this process actually pushed over its whole run (a wider
+      // span than `windowSec`, since the feed starts before the first kept
+      // sample — a looser figure is enough for a sanity comparison).
+      const elapsedSec = (Date.now() - startedAt) / 1000;
+      const achievedMBps = elapsedSec > 0 ? bytesWritten / elapsedSec / 1e6 : 0;
+      const requiredMBps = ((stream.megabitsPerSecond * 1e6) / 8) * speed / 1e6;
+      log.info(
+        `hwaccel: decode pipe fed ${achievedMBps.toFixed(1)} MB/s, ${requiredMBps.toFixed(1)} MB/s ` +
+        `needed for ${speed.toFixed(2)}x — a reading where these are far apart is worth a second look`
+      );
       resolve({
-        speed: producedSec / windowSec,
+        speed,
         windowSec,
-        megapixelsPerSecond: clipInfo.megapixelsPerSecond,
-        megabitsPerSecond: clipInfo.megabitsPerSecond
+        megapixelsPerSecond: stream.megapixelsPerSecond,
+        megabitsPerSecond: stream.megabitsPerSecond,
+        pipeThroughputMBps: achievedMBps
       });
     };
     const timer = setTimeout(finish, DECODE_WINDOW_MAX_MS);
     try {
-      child = spawn(ffmpegBin, args, { stdio: ["ignore", "pipe", "pipe"], windowsHide: true });
-    } catch {
-      // The timer would otherwise hold the event loop for its full wait and
-      // then run against a child that was never created.
+      child = spawn(ffmpegBin, args, { stdio: ["pipe", "pipe", "pipe"], windowsHide: true });
+    } catch (error) {
       clearTimeout(timer);
       settled = true;
-      resolve(null);
+      resolve({ error: error instanceof Error ? error.message : String(error) });
       return;
     }
     child.stderr.on("data", (chunk) => {
       stderr += String(chunk);
     });
+    // Keep the decoder fed. `write` returning false means the pipe is full, and
+    // the next copy goes on the `drain` — so the decoder is never starved and
+    // this process never buffers more than the pipe holds.
+    const writeOnce = () => {
+      const accepted = child.stdin.write(stream.bytes);
+      bytesWritten += stream.bytes.length;
+      return accepted;
+    };
+    const feed = () => {
+      while (!settled && child.stdin.writable && writeOnce()) {
+        // Written straight through; go round again.
+      }
+    };
+    child.stdin.on("drain", feed);
+    // The kill closes the pipe under the writer; that is the intended end.
+    child.stdin.on("error", () => {});
     child.stdout.on("data", (chunk) => {
       stdout += String(chunk);
       let newline = stdout.indexOf("\n");
@@ -1084,15 +1408,26 @@ function measureDecodeSlope(ffmpegBin, clipPath) {
         finish();
       }
     });
-    child.on("error", () => {
+    child.on("error", (error) => {
       if (settled) {
         return;
       }
       clearTimeout(timer);
       settled = true;
-      resolve(null);
+      try {
+        child?.stdin?.destroy();
+      } catch {
+        // already gone
+      }
+      try {
+        child?.kill("SIGKILL");
+      } catch {
+        // already gone
+      }
+      resolve({ error: error instanceof Error ? error.message : String(error) });
     });
     child.on("close", finish);
+    feed();
   });
 }
 

package/services/torrent-pool.js

@@ -2,11 +2,12 @@
  * @file WebTorrent client pool.
  *
  * Manages a shared WebTorrent client instance and a map of active torrents
- * keyed by a hash of their source. Tracks file-level usage so that only
- * the pieces needed by active streams are selected for download.
+ * keyed by their own infohash (see `torrent-source-key.js`), so a magnet and
+ * a `.torrent` file for the same content share one entry. Tracks file-level
+ * usage so that only the pieces needed by active streams are selected for
+ * download.
  */
 
-import crypto from "node:crypto";
 import dns from "node:dns/promises";
 import os from "node:os";
 import path from "node:path";
@@ -14,6 +15,7 @@ import { rmSync, statfsSync } from "node:fs";
 import WebTorrent from "webtorrent";
 import { logger } from "../utils/logger.js";
 import { SharedPieceStore, findSharedStore } from "./piece-store/shared-piece-store.js";
+import { deriveSourceKey } from "./torrent-source-key.js";
 
 // The DHT's entry points. Two of the three the library ships answer nothing —
 // measured 2026-08-21 from the addon host: `router.bittorrent.com` and
@@ -1338,7 +1340,9 @@ export class TorrentPool {
    * @returns {Promise<import("webtorrent").Torrent>}
    */
   async getTorrent(sourceType, source) {
-    const key = `${sourceType}:${crypto.createHash("sha1").update(source).digest("hex")}`;
+    // Keyed by the torrent's own infohash, not the source bytes — a magnet
+    // and a `.torrent` file for the same content must name the same swarm.
+    const key = await deriveSourceKey(sourceType, source);
 
     // Already resolved — return immediately.
     const existing = this.torrents.get(key);

package/services/torrent-source-key.js

@@ -0,0 +1,38 @@
+/**
+ * @file Canonical identity for a torrent source: its own infohash.
+ *
+ * A magnet URI and a `.torrent` file for the same content are different
+ * bytes, so naming a source by a hash of those bytes gave the same film two
+ * unrelated keys — one from a magnet, another from a `.torrent` — sharing
+ * neither the swarm, nor a cache, nor any work already done. Measured
+ * 2026-08-19: `a518ff46…` and `7ab2fb5d…` for one infohash `11f09299…`.
+ *
+ * The infohash is the one thing both forms carry for the same content, and
+ * both carry it synchronously — a magnet's `btih` needs no network, and a
+ * `.torrent` file's SHA-1 of its own `info` dictionary needs no metadata
+ * exchange either. `parse-torrent` (already in the dependency tree via
+ * `webtorrent`) reads either form without touching the network.
+ */
+
+import parseTorrent from "parse-torrent";
+
+/**
+ * @param {"magnet" | "torrent"} sourceType
+ * @param {string} source - Magnet URI, or base64-encoded `.torrent` bytes.
+ * @returns {Promise<string>} `torrent:<infohash>` — identical for a magnet
+ *   and a `.torrent` file describing the same content.
+ */
+export async function deriveSourceKey(sourceType, source) {
+  const torrentId = sourceType === "torrent" ? Buffer.from(source, "base64") : source;
+  let parsed;
+  try {
+    parsed = await parseTorrent(torrentId);
+  } catch (error) {
+    const message = error instanceof Error ? error.message : String(error);
+    throw new Error(`Could not read an infohash from this ${sourceType}: ${message}`);
+  }
+  if (!parsed?.infoHash) {
+    throw new Error(`Could not read an infohash from this ${sourceType}.`);
+  }
+  return `torrent:${parsed.infoHash}`;
+}

package/services/torrent-worker/pool-adapter.js

@@ -22,22 +22,8 @@
  *    across calls for the same torrent.
  */
 
-import crypto from "node:crypto";
 import { TorrentWorkerClient } from "./client.js";
-
-/**
- * Stable key for a source, matching how the worker keys its torrents.
- *
- * Derived from the source itself rather than handed out per request, so two
- * routes asking for the same torrent name the same thing on the worker side.
- *
- * @param {"magnet" | "torrent"} sourceType
- * @param {string} source
- * @returns {string}
- */
-function deriveSourceKey(sourceType, source) {
-  return `${sourceType}:${crypto.createHash("sha1").update(source).digest("hex")}`;
-}
+import { deriveSourceKey } from "../torrent-source-key.js";
 
 /**
  * A torrent pool whose work happens on another thread.
@@ -65,7 +51,7 @@ export class WorkerTorrentPool {
    * @returns {Promise<object>}
    */
   async getTorrent(sourceType, source) {
-    const sourceKey = deriveSourceKey(sourceType, source);
+    const sourceKey = await deriveSourceKey(sourceType, source);
     const existing = this.#torrents.get(sourceKey);
     if (existing) {
       return existing;

package/test/decode-measurement.test.js

@@ -0,0 +1,83 @@
+/**
+ * @file What the decode measurement must never get wrong.
+ *
+ * The quality menu is predicted from these readings, so a reading that is
+ * merely PRECISE is worth nothing — it has to be ordered the way decoding is.
+ * Under `-stream_loop -1` it was not: the loop restart costs 0.03 s on a 480p
+ * clip and 0.12 s on a 1080p one (the decoder tearing down and re-allocating
+ * its frame buffers), a five-second clip at 55x restarts eleven times a second,
+ * and the resulting bias depends on the clip's own resolution and on how fast
+ * the host is. On a fast desktop, 2026-08-20, that made 1080p read cheaper than
+ * 720p — which is not a thing a decoder does, and the fit refused to solve.
+ *
+ * These tests state the orderings instead of the numbers: the numbers are
+ * properties of whatever machine runs them.
+ */
+
+import test from "node:test";
+import assert from "node:assert/strict";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+import ffmpegStatic from "ffmpeg-static";
+import { measureDecodeSlope } from "../services/hwaccel.js";
+
+const CLIPS = path.join(path.dirname(fileURLToPath(import.meta.url)), "..", "assets", "calibration");
+const clip = (name) => path.join(CLIPS, name);
+
+test("a bigger picture costs more than a smaller one of the same bitrate", async () => {
+  const big = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-1080-hi.mp4"));
+  const small = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-480-hi.mp4"));
+
+  assert.ok(big, "the 1080p clip was measured");
+  assert.ok(small, "the 480p clip was measured");
+  assert.ok(
+    small.speed > big.speed,
+    `480p decoded at ${small.speed.toFixed(1)}x and 1080p at ${big.speed.toFixed(1)}x — ` +
+      `an ordering no decoder produces, which is what the loop used to invert`
+  );
+});
+
+test("a thicker stream costs more than a thin one of the same size", async () => {
+  const thick = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-480-hi.mp4"));
+  const thin = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-480-lo.mp4"));
+
+  assert.ok(thick && thin);
+  assert.ok(
+    thin.speed > thick.speed,
+    `the same picture at ${thin.megabitsPerSecond.toFixed(2)} Mbit/s decoded at ${thin.speed.toFixed(1)}x ` +
+      `and at ${thick.megabitsPerSecond.toFixed(2)} Mbit/s at ${thick.speed.toFixed(1)}x`
+  );
+});
+
+test("HEVC costs more than H.264 for the same picture on the same machine", async () => {
+  const h264 = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-480-lo.mp4"), "h264");
+  const hevc = await measureDecodeSlope(ffmpegStatic, clip("cal-hevc-480-lo.mp4"), "hevc");
+
+  assert.ok(h264 && hevc, "both families are lifted out of their containers correctly");
+  assert.ok(
+    h264.speed > hevc.speed,
+    `H.264 ${h264.speed.toFixed(1)}x against HEVC ${hevc.speed.toFixed(1)}x — the reason the model ` +
+      `is fitted per codec family at all`
+  );
+});
+
+test("the clip's own characteristics come back with the reading", async () => {
+  const measured = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-1080-hi.mp4"));
+
+  assert.ok(measured);
+  // Read from the container rather than declared anywhere, so replacing a clip
+  // cannot silently invalidate the fit that rests on it.
+  assert.ok(measured.megapixelsPerSecond > 40 && measured.megapixelsPerSecond < 60);
+  assert.ok(measured.megabitsPerSecond > 5 && measured.megabitsPerSecond < 15);
+  assert.ok(measured.windowSec >= 0.5, "the slope is taken over a window wide enough to divide by");
+});
+
+test("a reading carries what the pipe was actually fed, for item 4(d2)'s sanity check", async () => {
+  const measured = await measureDecodeSlope(ffmpegStatic, clip("cal-h264-480-lo.mp4"));
+
+  assert.ok(measured);
+  assert.ok(
+    measured.pipeThroughputMBps > 0,
+    "the write path pushed a nonzero amount of the clip through, or nothing was measured at all"
+  );
+});