import ts corrupts a multi-program transport stream without an error, and export ts rebuilds only one program #4353

Summary

Feeding a real MPTS to moq import ts does not produce an error on current main. With the programs
on independent clocks, which is how they arrive from separate encoders, the output timeline is
scrambled and most of one program is lost. With the programs on a common clock the video survives,
but audio has multi-second holes and most SCTE-35 sections are lost. The publisher exits 0 in both
cases and logs nothing about it. On either build, the exporter emits one program: a PAT with one
entry and one PMT listing every elementary stream. The carried SDT and EIT still describe the other
services, so the service layer contradicts itself.

The importer already scopes itself to single-program input in a comment (below), so this is not a
request for MPTS support as such. The ask is that an MPTS fails loudly, or is reduced to one program
on purpose, rather than being corrupted without a word.

Input

A 60 s MPTS built with TSDuck from three single-program clips: three programs, each with its own PMT,
PCR PID and elementary streams, plus one PAT and one SDT listing all three, and EIT present/following
for each. Clean at source: 0 continuity errors, and every PCR within 13 ticks (pcrverify).

It comes in two variants. In the first, the clocks are independent: program 1's PCR starts near
25,631 s and the other two near 3 s. In the second, programs 2 and 3 are re-timed by stream-copy remux
so that all three start within 0.82 s of each other.

What happens

On main (2b689c24), independent clocks

The publisher runs to the end and exits 0. The subscriber receives 15.6 MB, where the common-clock
variant delivers about 86 MB:

Program 2 arrives whole, on its own timeline. The rest is re-timed across clocks:

• PCR on PID 111 jumps by more than 5 s thirteen times, and spans 60,970 s for a 60 s input.
• Program 3's video arrives stamped on program 1's clock (about 25,641 s).
• Audio and teletext PTS land at values that exist nowhere in the source: 39,780 s, 76,897 s and
  83,968 s, against source clocks near 25,631 s and 3 s.

The only warnings, both from the subscriber:

WARN moq_mux::container::consumer: current group evicted; skipping to next buffered group track="1.avc3" group=1 error=Hang(Moq(Old))
WARN moq_mux::container::consumer: current group evicted; skipping to next buffered group track="7.avc3" group=0 error=Hang(Moq(Old))

On main, common clock (two runs)

The publisher exits 0 and video is intact on all three programs. The rest is not:

• SCTE-35: 1–2 and 4–7 packets per PID reach the egress, against about 60 at source.
• Program 1 audio: its MP2 PID carries 5,408 and 6,376 packets, against 9,688 when program 1
  is sent alone through the same build. In the second run the PTS show eight holes of 2.7–4.1 s,
  each about 0.45 s shorter than the last. AC-3 on program 1 shows nine holes, and program 3's MP2 three (0.8–1.8 s).
• EIT: the carriage rate moves a long way from source: +139 % in one run and −76 % in the other.

No warning is logged while any of this happens; the only warnings come at teardown.

Control: program 1 alone through the same build, extracted with
tsp -P zap 1 --stuffing --eit, is clean. Its SCTE-35 arrives (57 of 60 packets per PID), audio has
no holes, the EIT rate is within 9 % and PCR intervals stay at or below 25 ms. The losses need
several programs in one input.

On 0.12.1 (ffa5b81b)

With independent clocks the publisher aborts about 2 s in, in two runs out of two:

WARN moq_net::model::resume: no route can serve the rest of this group group=0 frame=17 err=transport: frame timestamp is below the live edge
Error: frame timestamp is below the live edge

With a common clock it completes without the losses above. This is a better outcome than main's,
because it fails, but the error does not say that the input has more than one program.

The exporter, on both builds

Whenever enough survives to export, the output looks like this:

PAT: program 1 -> PMT 100                (source: 1 -> 100, 2 -> 512, 3 -> 768)
PMT 100: program 1, PCR PID 111
  ES 111, 121, 123, 131, 141, 142, 143, 529, 785, 786

PMT PIDs 512 and 768 do not appear, and PIDs 529 and 785 carry no PCR. The SDT and EIT are carried
verbatim, so they still list services 2 and 3, which the PAT no longer has.

Why, as far as I can read it

• One section clock. Private sections and SI snapshots are stamped with last_pts
  (rs/moq-mux/src/container/ts/import.rs). Every program's video writes that one field, and the
  comment on it states the limit:

  /// SPTS scope: one clock for the whole input. Under MPTS every program's video
  /// advances it, so a cue could be stamped with another program's PTS.
  

  On 0.12.1 the alternation between program clocks trips TimestampRewind on the section and SI
  tracks, which is the abort.

• Re-anchoring and one broadcast clock. Between the two builds, import.rs gained per-stream
  re-anchoring below the live edge (fix(moq-mux): every TS elementary stream re-anchors below the live edge #3997) and publication on the broadcast clock (feat(cli): publish stdin imports on the broadcast clock #4122). My reading,
  which I have not verified by bisecting, is that one or both now treat a jump between program clocks
  as a wrap or restart and re-anchor rather than fail. That would explain the independent-clock
  output, and possibly the audio and SCTE-35 losses on a common clock, where the clocks still differ
  by up to 0.82 s.

• One program record. record_program_identity keeps the first non-zero entry in the PAT. The
  PAT arm then adds every PMT PID to pmt_pids, so the elementary streams of every program become
  tracks of one broadcast. The exporter builds its PAT and PMT from that single record
  (table: vec![ProgramAssociation { .. }] in export.rs).

Reproducer

• Fixture recipe:
  make-real-mpts.sh
  (TSDuck 3.44 and ffmpeg). Set P2_OFFSET/P3_OFFSET for the common-clock variant; the values
  are in the script header.
• Rig:
  t10-moq.sh
  runs relay, export ts to file, and import ts fed once at source rate by
  tsp -P regulate --pcr-synchronous.
• Grader:
  t10-grade.py
  grades each program for PAT, PMT, SDT, EIT, continuity, PCR and every elementary stream.

make-real-mpts.sh mpts3.ts 60
BIN=<dir with moq and moq-relay> t10-moq.sh mpts3.ts out mpts
t10-grade.py mpts3.ts out/egress.ts

Any two programs whose clocks start far apart should reproduce the independent-clock case. The
second program does not need audio or SI.

What would help, from where I sit

In rough order of cost; the first alone would close the silent part:

1. Refuse an MPTS explicitly. When the PAT lists more than one program, exit with an error that
   says so, before anything is published. tsp -P zap <program> in front of import ts already
   gives a clean single-program feed. All three programs came through intact that way on 0.12.1,
   and program 1 again on main, so a refusal costs users nothing but a pipeline stage.
2. Or select one program. A --program <n> option that routes one program's PMT and drops the
   other programs' PIDs would make the reduction deliberate instead of accidental. It would also give
   one broadcast per program, which is what the catalog model supports today.
3. If MPTS belongs in scope: one section clock per program, keyed by the PMT that lists the PID,
   and one program record per PMT in the catalog, so the exporter can rebuild the PAT and every PMT.
   Only this one preserves the multiplex, and it is plainly the largest.

For whichever you choose, a regression test in the shape of the existing import tests: a synthetic
input with two programs whose video clocks start far apart. It should either fail with an error
naming the second program, or publish two programs that export as two.