@torrent-tv/proxy 2.9.84 → 2.9.86

package/CHANGELOG.md

@@ -1,3 +1,12 @@
+## 2.9.86
+
+- **Fix**: fMP4 playback starts again. The real reason ffmpeg exited before writing anything was the audio, not the file names: the MP4 muxer derives a copied AC-3 track's `dac3` box from the bitstream, so it cannot write `moov` until the first audio packet arrives, while our `empty_moov` demands it at header time — `Cannot write moov atom before AC3 packets. Set the delay_moov flag to fix this.`, captured in the field on a copied AC-3 source. `delay_moov` is now passed alongside it. The `hls` muxer sets that flag itself, which is why the fault appeared only once the muxing moved to the `segment` muxer in 2.9.84; MPEG-TS has no `moov` and was never affected. Verified in the addon container on an AC-3 source: without the flag the exact command the proxy runs fails, with it the segments are written, and the piece layout is unchanged (`ftyp moov moof mdat … mfra`), so the init split added in 2.9.84 still cuts in the same places — headers of consecutive pieces differ in four bytes, all inside `elst`, which the `tfdt` rewriting already overrides.
+- **Chore**: Correcting the 2.9.85 entry below. It blames the `.m4s` extension, and that is false: with the arguments this proxy passes, ffmpeg 8.1.2 writes `.m4s` without complaint (re-measured on the same host, and on 6.1.1). The quoted error is what the same command produces when `-segment_format mp4` is missing — which the proxy never omits — and the field failure ends in `Invalid argument`, not `Muxer not found`. The rename is harmless and stays, but it fixed nothing.
+
+## 2.9.85
+
+- **Fix**: fMP4 playback did not start at all in 2.9.84 — every request for the init segment answered 500. ffmpeg had refused to open the output: `Could not write header (incorrect codec parameters ?)`, because the `segment` muxer determines the container from the file extension and does not recognise `.m4s` for MP4, whatever `-segment_format` says. Segments are now written and named `.mp4` on both paths. The extension is internal: it appears only in our own playlist and in the temporary directory, so nothing outside changes.
+
 ## 2.9.84
 
 - **Fix**: fMP4 now cuts segments where the playlist says too, closing the gap left by 2.9.82 (which covered MPEG-TS only). The muxer that takes explicit cut times writes each fMP4 piece self-contained — `ftyp moov moof mdat … mfra`, confirmed on the field host — which is not what HLS wants, so the pieces are split on serve: the header is lifted out of the first one to become the init segment named by `#EXT-X-MAP`, and removed from every media segment along with the trailing random-access index, whose offsets describe a file that no longer exists. Timestamps still need stamping exactly as before: measured, all pieces of a run report a start of 0.080 s, each carrying its own zero, which is the same defect the existing rewriting already corrects. Verified end to end on a real piece from the field host — split into a 779-byte init and 221 KB of fragments, recombined, and decoded clean.

package/package.json

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

package/services/segment-formats/fmp4.js

@@ -1,5 +1,5 @@
 /**
- * @file fMP4 (CMAF) segment format — `.m4s` media segments plus one shared
+ * @file fMP4 (CMAF) segment format — `.mp4` media segments plus one shared
  * `init.mp4` referenced by `#EXT-X-MAP`.
  *
  * Codec configuration (SPS/PPS) lives once in the init segment instead of being
@@ -54,7 +54,7 @@ function findFragmentBounds(bytes) {
 }
 
 const INIT_FILE_NAME = "init.mp4";
-const SEGMENT_PATTERN = /^segment-(\d{5})\.m4s$/;
+const SEGMENT_PATTERN = /^segment-(\d{5})\.mp4$/;
 
 /**
  * @type {import("./index.js").SegmentFormat}
@@ -74,7 +74,7 @@ export const fmp4Format = {
       "-hls_fmp4_init_filename",
       INIT_FILE_NAME,
       "-hls_segment_filename",
-      "segment-%05d.m4s"
+      "segment-%05d.mp4"
     ];
   },
 
@@ -102,14 +102,24 @@ export const fmp4Format = {
       // `empty_moov` is what makes each piece self-describing, which is what
       // lets the init be lifted out of it; `default_base_moof` keeps fragment
       // offsets relative, so removing the header does not invalidate them.
+      //
+      // `delay_moov` is not optional here. The MP4 muxer builds a copied AC-3
+      // track's `dac3` box out of the bitstream, so it cannot write `moov`
+      // until the first audio packet has arrived — while `empty_moov` asks for
+      // it at header time. Without this flag ffmpeg exits before producing
+      // anything: "Cannot write moov atom before AC3 packets", which is exactly
+      // how fMP4 playback died in the field on 2.9.84/2.9.85. The `hls` muxer
+      // sets this flag itself, which is why the fault only appeared once the
+      // muxing moved here. Delaying `moov` does not change the piece layout —
+      // measured: still `ftyp moov moof mdat … mfra`.
       "-segment_format_options",
-      "movflags=+frag_keyframe+empty_moov+default_base_moof"
+      "movflags=+frag_keyframe+empty_moov+default_base_moof+delay_moov"
     ];
   },
 
   /** The output path template for the `segment` muxer. */
   segmentFileNameTemplate() {
-    return "segment-%05d.m4s";
+    return "segment-%05d.mp4";
   },
 
   /**
@@ -151,7 +161,7 @@ export const fmp4Format = {
   },
 
   segmentFileName(index) {
-    return `segment-${String(index).padStart(5, "0")}.m4s`;
+    return `segment-${String(index).padStart(5, "0")}.mp4`;
   },
 
   isSegmentFileName(fileName) {