@torrent-tv/proxy 2.9.81 → 2.9.82

package/CHANGELOG.md

@@ -1,5 +1,6 @@
-## 2.9.81
+## 2.9.82
 
+- **Fix**: The playlist and the real segments now describe the same thing. On the copy path ffmpeg was given only a target duration and chose its own cut points, while the playlist was built from the container keyframe index — two independent calculations tied together by nothing but the assumption that they agree. They do not: the index is a navigation table and is not obliged to list every keyframe. On a field file it held 1902 while ffmpeg found roughly twice as many and cut twice as often, so segment #876 meant 1:26:50 to the player and about minute 58 to ffmpeg. A seek into the middle landed at the end and the reported duration drifted. ffmpeg now receives the very boundaries the playlist was built from, via the `segment` muxer, which takes the list outright — agreement by construction instead of by luck. Verified on deliberately uneven keyframes: cuts requested at 4.44, 10.36, 16.28, 22.2 and 28.12 s landed exactly there. Two measured details are encoded in the code: those times count from the start of the RUN, not of the file (starting at 12 s and asking for 18 s put the cut at 29.4), and a tolerance absorbs rounding so a boundary recorded a hair late cannot skip to the next keyframe and silently double a segment. MPEG-TS only for now — fMP4 can do this too, but only as self-contained fragments, which removes the shared init segment and the `tfdt` rewriting built around it; that is a separate change and not one to make blind.
 - **New**: The stream route says why a read failed. A body that failed mid-flight was dropped silently — the connection closed with no status and no log line, which from the client looks like the proxy died and from the log like nothing happened; found while probing the route by hand, where every ranged read closed the socket without a word. It now reports the file, the range, how many bytes had been sent, and the error.
 
 ## 2.9.80

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.9.81",
+  "version": "2.9.82",
   "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
   "license": "GPL-3.0-or-later",
   "publishConfig": {

package/services/hls-session-manager.js

@@ -606,6 +606,41 @@ function computeSegmentBoundaries({ transcodeVideo, durationSeconds, segDur, key
   return boundaries.length >= 2 ? boundaries : uniform();
 }
 
+/**
+ * The cut times to hand ffmpeg for a run that starts at `startIndex`.
+ *
+ * Two adjustments, both of which cost a broken session to learn:
+ *
+ *  - **Rebased.** `-segment_times` is measured from the start of the run, not
+ *    of the file. Measured: starting at 12 s and asking for a cut at 18 s put
+ *    it at 29.4 s — 12 + 18. So every boundary has the run's own start
+ *    subtracted.
+ *  - **Interior only.** The first boundary is where the run begins and the last
+ *    is where the file ends; neither is a cut. Sending them would produce an
+ *    empty leading segment and a spurious trailing one.
+ *
+ * @param {number[]} boundaries - Segment start times, ascending, ending at the
+ *   file duration (as {@link computeSegmentBoundaries} returns).
+ * @param {number} startIndex - Segment this run starts at.
+ * @returns {number[] | null} Times relative to the run start, or null when the
+ *   boundaries cannot serve (missing, or the index is outside them).
+ */
+export function segmentCutTimesFrom(boundaries, startIndex) {
+  if (!Array.isArray(boundaries) || boundaries.length < 2) {
+    return null;
+  }
+  const index = Number.isInteger(startIndex) && startIndex > 0 ? startIndex : 0;
+  if (index >= boundaries.length - 1) {
+    return null;
+  }
+  const base = boundaries[index];
+  const times = [];
+  for (let at = index + 1; at < boundaries.length - 1; at += 1) {
+    times.push(Number((boundaries[at] - base).toFixed(6)));
+  }
+  return times;
+}
+
 /**
  * The largest keyframe time that does not exceed `target`, from a SORTED
  * (ascending) array of keyframe times such as {@link probeVideoKeyframeTimes}
@@ -1766,24 +1801,68 @@ export class HlsSessionManager {
       // Type-relative audio track chosen by the viewer (default 0).
       `0:a:${session.audioTrackIndex ?? 0}?`,
       ...videoCodecArgs,
-      ...audioCodecArgs,
-      "-f",
-      "hls",
-      "-hls_time",
-      String(this.segmentDurationSec),
-      "-hls_list_size",
-      "0",
-      "-hls_flags",
-      "independent_segments+temp_file",
-      // Container selection + segment naming, from the active format module.
-      ...this.segmentFormat.muxerArgs(),
-      "-start_number",
-      String(safeIndex),
-      // ffmpeg writes its own playlist here; we ignore it and serve the
-      // synthetic VOD playlist instead (see getFileStream).
-      PLAYLIST_FILE_NAME
+      ...audioCodecArgs
     );
 
+    // Where the cuts come from. On the copy path they are the source's own
+    // keyframes, and until now they were only ever GUESSED: ffmpeg got a target
+    // duration and chose its own cut points, while the playlist was built from
+    // the container index — two independent calculations with nothing tying
+    // them together but the hope that they agree. They do not. The index is a
+    // navigation table and is not obliged to list every keyframe; for a field
+    // file it held 1902 while ffmpeg found roughly twice as many and cut twice
+    // as often. Segment #876 then meant 1:26:50 to the player and about minute
+    // 58 to ffmpeg, which is why a seek landed nowhere near where it was aimed
+    // and the reported duration drifted.
+    //
+    // So stop guessing and say it: the `segment` muxer takes the list of times
+    // outright. Passing the very boundaries the playlist was built from makes
+    // the two agree by construction. Only cut points already known to be real
+    // keyframes are sent, so ffmpeg never has to move one forward.
+    const explicitTimes = this.segmentFormat.explicitTimesMuxerArgs?.() ?? null;
+    const cutTimes = explicitTimes && !session.transcodeVideo
+      ? segmentCutTimesFrom(session.segmentBoundaries, safeIndex)
+      : null;
+
+    if (cutTimes && cutTimes.length > 0) {
+      args.push(
+        "-f",
+        "segment",
+        // Times are measured from the START OF THIS RUN, not from the start of
+        // the file — verified: starting at 12 s and asking for a cut at 18 s
+        // produced one at 29.4 s. `segmentCutTimesFrom` rebases them.
+        "-segment_times",
+        cutTimes.join(","),
+        // A cut lands on the first keyframe at or after its time, so a boundary
+        // recorded a hair late would skip to the next one and double the
+        // segment. The tolerance absorbs that rounding.
+        "-segment_time_delta",
+        "0.05",
+        "-segment_start_number",
+        String(safeIndex),
+        ...explicitTimes,
+        this.segmentFormat.segmentFileNameTemplate()
+      );
+    } else {
+      args.push(
+        "-f",
+        "hls",
+        "-hls_time",
+        String(this.segmentDurationSec),
+        "-hls_list_size",
+        "0",
+        "-hls_flags",
+        "independent_segments+temp_file",
+        // Container selection + segment naming, from the active format module.
+        ...this.segmentFormat.muxerArgs(),
+        "-start_number",
+        String(safeIndex),
+        // ffmpeg writes its own playlist here; we ignore it and serve the
+        // synthetic VOD playlist instead (see getFileStream).
+        PLAYLIST_FILE_NAME
+      );
+    }
+
     const ffmpeg = spawn(this.ffmpegBin, args, {
       cwd: session.dirPath,
       stdio: ["ignore", "pipe", "pipe"]

package/services/segment-formats/fmp4.js

@@ -37,6 +37,24 @@ export const fmp4Format = {
     ];
   },
 
+  /**
+   * Not supported on this format — deliberately, for now.
+   *
+   * The `segment` muxer can produce fMP4 (verified: explicit times cut exactly
+   * where asked), but only as self-contained fragments carrying their own
+   * `moov`. That removes the shared init segment this format is built around —
+   * `#EXT-X-MAP`, and with it the whole `tfdt` rewriting that took a field
+   * failure to get right. Changing all of that at once, on a path no current
+   * deployment exercises and that cannot be verified without a real browser, is
+   * how the last round of regressions happened. MPEG-TS, which is what runs in
+   * the field, gets the fix first.
+   *
+   * @returns {null}
+   */
+  explicitTimesMuxerArgs() {
+    return null;
+  },
+
   playlistHeaderLines() {
     return [
       // The init segment (codec config). Fetched once; applies to every media

package/services/segment-formats/mpegts.js

@@ -31,6 +31,26 @@ export const mpegtsFormat = {
     return ["-hls_segment_filename", "segment-%05d.ts"];
   },
 
+  /**
+   * Arguments for cutting at times we choose rather than times ffmpeg picks.
+   *
+   * The `hls` muxer takes only a target duration and finds its own cut points,
+   * which is why the playlist and the real segments drifted apart; the `segment`
+   * muxer takes the list. Self-contained segments make this straightforward
+   * here: no init segment to reconcile, so the only difference is the container
+   * and the file name template.
+   *
+   * @returns {string[]}
+   */
+  explicitTimesMuxerArgs() {
+    return ["-segment_format", "mpegts"];
+  },
+
+  /** The output path template for the `segment` muxer. */
+  segmentFileNameTemplate() {
+    return "segment-%05d.ts";
+  },
+
   playlistHeaderLines() {
     return []; // no `#EXT-X-MAP`
   },

package/test/segment-cut-times.test.js

@@ -0,0 +1,63 @@
+/**
+ * The playlist and the real segments must describe the same thing.
+ *
+ * They did not. The playlist was built from the container index while ffmpeg
+ * chose its own cut points from a target duration, and the two only ever agreed
+ * by luck — on a field file the index listed 1902 keyframes, ffmpeg found about
+ * twice as many, and segment #876 meant 1:26:50 to the player and roughly
+ * minute 58 to ffmpeg. Seeks landed nowhere near where they were aimed.
+ *
+ * These tests pin the arithmetic that ties the two together.
+ */
+
+import test from "node:test";
+import assert from "node:assert/strict";
+import { segmentCutTimesFrom } from "../services/hls-session-manager.js";
+
+test("cut times are the interior boundaries, rebased on the run start", () => {
+  // Segments 0-10, 10-20, 20-30, 30-40 (file ends at 40).
+  const boundaries = [0, 10, 20, 30, 40];
+
+  assert.deepEqual(
+    segmentCutTimesFrom(boundaries, 0),
+    [10, 20, 30],
+    "from the start, the cuts are every boundary except 0 and the file end"
+  );
+
+  // Restarting at segment 2 means the run begins at 20 s; a cut at 30 s is 10 s
+  // into the run. Sending 30 would put it at 50 — `-segment_times` counts from
+  // the run, which is what made a seek land in the wrong place.
+  assert.deepEqual(
+    segmentCutTimesFrom(boundaries, 2),
+    [10],
+    "after a restart the times must be relative to where the run starts"
+  );
+});
+
+test("uneven, real-world boundaries survive the rebasing exactly", () => {
+  // Keyframes never land on round numbers; rounding here is what would push a
+  // cut past its keyframe and silently double a segment.
+  // Starting at segment 1 leaves segments 1, 2 and 3 — three segments, so two
+  // cuts between them, each measured from the run start at 10.427.
+  const boundaries = [0, 10.427, 20.854, 31.281, 41.708];
+  assert.deepEqual(segmentCutTimesFrom(boundaries, 1), [10.427, 20.854]);
+});
+
+test("boundaries that cannot serve are refused rather than half-used", () => {
+  assert.equal(segmentCutTimesFrom(null, 0), null);
+  assert.equal(segmentCutTimesFrom([], 0), null);
+  assert.equal(segmentCutTimesFrom([0], 0), null, "a single boundary describes no segment");
+  assert.equal(
+    segmentCutTimesFrom([0, 10, 20], 2),
+    null,
+    "a start index at or past the last boundary has no run to describe"
+  );
+});
+
+test("the final run has no interior cuts and asks for none", () => {
+  assert.deepEqual(
+    segmentCutTimesFrom([0, 10, 20], 1),
+    [],
+    "starting at the last segment leaves nothing to cut, which is not an error"
+  );
+});