Save pipeline proposals: parallel fragment downloads during a save, gap padding in hls2mp4, flat output from the remuxer, subtitle muxing, up-front co64 choice #224

Severity: low

• Fragment downloads during a save are strictly sequential: every getEntry awaits downloadFragment one at a time (HLSPlayer.mjs, DashPlayer.mjs, MP4Player.mjs saveVideo), so a save of an un-buffered stream runs at single-connection speed although the download manager supports parallel downloads. Pre-queue the next N fragments (pinned) while the converter consumes the current one.
• hls2mp4 partial saves concatenate across holes (sn gaps are treated as discontinuities) with no padding, while mp4merger extends the previous sample over a gap; hls2mp4 could reuse that so a partial TS save keeps A/V aligned after a missing fragment.
• The remuxer writes a fragmented MP4 (Mp4OutputFormat({fastStart: 'fragmented'})): Firefox reports its duration as the shortest track's end (noted in modules.e2e.mjs) and some editors dislike fMP4. The merger and hls2mp4 outputs are already moov-first flat files; a flat remuxer output needs a second pass or Mediabunny's reserve mode.
• No subtitle muxing: active subtitle tracks are converted to SRT for mpv but not written into saved files; tx3g or wvtt tracks would be a natural addition for the flat writers.
• MP4Generator.stco falls back to co64 only by catching the "Offset is too large" throw after a full initSegment build (hls2mp4 and mp4merger each build the moov up to three times for large files); computing use64Offsets from datasOffset + headerSize > 2^32 up front avoids that.

Confidence: high.

From a line-by-line code review of the tree at 41363fd (2026-10-02). Each claim above was checked against the source before filing; the reproduction steps and line references are as of that commit.

Generated by Claude Code