moq import ts aborts on continuous content join (TimestampRewind)

[t0ms]

Summary

On 5d0991b9 (main after #3793), moq import ts exits at the first content join on a continuous timeline with:

Error: frame timestamp is below the live edge

(moq_mux::container::TimestampRewind from rs/moq-mux/src/container/producer.rs.)

Reproducer

python3 ts-continuous-source.py CNNiEMEA2.ts --passes 2 \
  | tsp -I file - -P regulate --pcr-synchronous -O file - \
  | moq --connect-tls-insecure --connect https://127.0.0.1:443/anon \
        --broadcast repro.hang import ts

Fails at the pass boundary (~600 s on CNNiEMEA2.ts). PCR/PTS stay monotone across the join (0 backward PCR steps); this is a content repeat on a continuous transport timeline, not a true rewind.

Root cause

#3793 merged the monotonic-timeline rule into container::Producer::write, which refuses frame.timestamp < live_edge.

The #3533 fix added reanchor() on the legacy audio path only (LegacyStream in rs/moq-mux/src/container/ts/import.rs; test legacy_resync_below_the_live_edge_publishes_forward). H.264/H.265 and verbatim PES paths call self.track.write(frame)? with no re-anchor, so at least one track publishes below the live edge at a content join and the import aborts.

Expected

Per quest/m1/monotonic-timeline.md: on trusted TS ingest, re-anchor forward (as legacy audio does) or call discontinuity() at the join.

Suggested fix

Extend reanchor() to all TS elementary-stream importers (minimum H.264/H.265 video and verbatim PES), or detect content-join and call Producer::discontinuity() before the new epoch.

[t0ms]

Additional campaign data: the same abort occurs at the first loop wrap on tsp --infinite (~631 s on CNNiEMEA2.ts), not only at ts-continuous-source.py content joins. Standing moq-live-publisher on 5d0991b9 fed via SRT caller with the same loop dies identically.

[t0ms]

Re-testing this on ffa5b81b after the close, since the quest notes the triggers are "none yet reproduced in-tree". The one I went after is the second claim in quest/m1/ts-import-reanchor.md — that the legacy shift "is set once, so a second unflagged loop wrap lands below the edge again" — because it decides whether the fix is "apply reanchor everywhere" or "apply it and make it cumulative".

Method. One elementary stream per fixture, each with its own PCR, looped with tsp --infinite so both PCR and PTS restart without the discontinuity indicator. Elapsed time to the import's exit divided by the fixture's wrap period gives the wrap it died on. One host, one relay, fixtures cut from one clip.

Fixture	Elementary stream	Wrap period	Died at	Wrap index
fx-h264	H.264, high profile, B-frames	30.2 s	30.3 s	1.00
fx-legacy	MPEG-1 Layer II	30.1 s	59.6 s	1.98
fx-ac3	AC-3	30.1 s	59.6 s	1.98

All three exit frame timestamp is below the live edge.

Both claims hold. H.264 aborts on the first frame below the edge; the legacy path absorbs exactly one wrap and aborts on the second. So lifting the existing reanchor into a shared helper without making it cumulative would move every stream kind from wrap 1 to wrap 2 and leave the defect for any source that joins more than once — every looping playout, and every channel that takes more than one break. That matches the plan's "Grow the offset whenever the shifted timestamp is still below the edge"; this is just the evidence for it.

One correction to the plan's scope. It describes the re-anchoring path as "legacy MPEG audio" and lists AC-3 among the kinds that abort immediately, but AC-3 measures identically to MPEG-1 Layer II at wrap 1.98. The code agrees: StreamType::DolbyDigitalUpToSixChannelAudio and …ForAtsc both dispatch to legacy_stream, and LegacyStream is documented in-tree as "one stream of legacy broadcast audio (MP2, AC-3, E-AC-3), carried verbatim". The dividing line is the LegacyStream type rather than the MPEG-1 codec, and it already spans three codecs — worth having right in the test list, since an AC-3 arm written to assert an immediate abort would fail.

Two things I did not measure, so the other hypotheses are untouched:

• The B-frame trigger on a continuous PCR, where a new IDR after a join lands below the last P-frame's PTS with no wrap at all. My trigger is a wrap, which is blunter; the H.264 fixture carries B-frames but the arm does not isolate them. This is the one I'd most want a reproduction for, and a synthetic fixture would serve it better than a broadcast clip.
• Sections after a B-frame PES. A section-only stream with its own PCR and no media is not something an encoder emits, so the arm would have been contrived.

Fixture recipe, since two gotchas cost me time: tsp -P filter keeps the PIDs you ask for but does not move the PCR, so an audio-only filter output has pcrbitrate=0 and is not a valid transport stream; -P pcradjust does not rescue it, because it rewrites PCRs that exist and cannot mint them. ffmpeg's mpegts muxer does synthesise a PCR PID, so the audio arms are remuxed and only the video arm — which already carries the service PCR — is cut with tsp:

# video arm: PID 111 already carries the PCR
tsp -I file src.ts -P filter --pid 0 --pid 100 --pid 111 -O file fx-h264.ts
# audio arms: remuxed so the muxer mints a PCR
ffmpeg -y -i src.ts -map 0:a:0 -c copy -muxrate 400000 -f mpegts fx-legacy.ts
ffmpeg -y -i src.ts -map 0:a:1 -c copy -muxrate 400000 -f mpegts fx-ac3.ts
# then, per arm
tsp --realtime -I file fx-<kind>.ts --infinite -P regulate --pcr-synchronous -O file - \
  | moq --connect <relay> --broadcast t41.<kind>.hang import ts

Validate pcrbitrate on every fixture before use — one without PCR fails for an unrelated reason and looks like a pass.

Happy to turn any of this into a test/ts/ fixture recipe or Rust tests if it's useful, but the quest already lists the cases it wants more specifically than I'd have guessed, so I'd rather not write them unasked.