A signalled backward TS discontinuity ends the import: republish the rest as a new broadcast in the same process

[t0ms]

What happens

Since #4543, every TS rewind ends the import, flagged or not. #4543 names the follow-up: "whether
callers such as moq import srt should republish automatically belongs to the broadcast epoch
line". The epoch line's gateways quest mints an epoch per incoming connection, so an encoder that
redials becomes a clean takeover. A rewind inside one connection, or inside one pipe into
moq import ts, is not covered by anything.

I measured it on dev at 9a80e875 (the importer is unchanged at the current tip) with a local
relay. The source is a 72 s off-air capture (H.264, MP2, AC-3, teletext), with the event at 30 s,
PCR-paced for 60 s. The SRT caller is srt-live-transmit, which redials by default, as encoders do.
The --linger column is dev with #4504 cherry-picked, because #4504 is on main and not yet on
dev. "Stall" is the longest gap at the subscriber's output.

Event at 30 s	import ts from a pipe	import srt, subscriber without linger	import srt, export ts --linger 10s
PCR/PTS/DTS 1 s back, discontinuity_indicator set	import exits 1	gateway ends the session, the caller redials within 25 ms, the subscriber exits 1	resumes; 1.38 s and 1.14 s stalls (two runs)
Encoder restart: timebase to 1 s, CC reset, flagged	import exits 1	same	resumed with a 1.46 s stall in one of two runs; in the other, the returned broadcast published no catalog within 10 s (not reproduced, cause unknown)
PCR/PTS/DTS 30 s forward, flagged	carries on	not measured cleanly	carries on; 0.45 s stall

Each rewind fails with frame timestamp is below the previous group's start. main carries all three.

Why it matters

A signalled backward discontinuity is legal TS (discontinuity_indicator, ISO/IEC 13818-1
§2.4.3.5). It is also routine in contribution. An upstream encoder restarts, or a source is switched
behind an SRT gateway, IRD or router that keeps its own connection up. A playout server loops. None of
these makes a new SRT connection or a new process.

On dev, each one ends a pipe-fed moq import ts for good, and there is nothing to redial. Through
the gateway, the SRT path recovers in about 1.1 to 1.5 s, but only because the caller happens to
redial after the gateway hangs up. That is the caller's behaviour, not something the gateway
provides. On a long-running feed, events like these are a matter of when, not whether.

Ask

When the TS importer meets a rewind that the stream signals (a discontinuity_indicator on the PCR
PID at the time-base change), moq import ts and moq-srt should end the current broadcast cleanly
and publish the rest of the same input as a new one, in the same process and connection. Once the
epoch line lands, that new broadcast is a new epoch. Unsignalled rewinds can stay fatal under #4543's
rule. This is the automatic republish #4543 deferred, limited to the one case the stream declares
itself.

Forward discontinuities already publish with break markers, so the backward case is the only
signalled time-base change that still costs the feed.

[kixelated]

Planned in #4587 as quest/m1/broadcast-epoch/ts-restart.md, part of the broadcast epoch line and requiring its Origin quest.

Decision: a rewound time base is new content, so it is always a new broadcast at a fresh epoch path, never a continuation of the old name. The rewind must be signalled (discontinuity_indicator on the PCR PID with the next PCR behind the last). decode then stops and reports it. The caller finishes the old broadcast cleanly, publishes a new one under a fresh epoch, and calls import.restart(broadcast), which carries over only the PAT/PMT layout and the bytes not yet consumed, so there's no wait for the next PSI repetition. ts::Programs restarts per program.

This covers moq import ts and moq-srt, single-program and Program::All. Unsignalled rewinds stay fatal under #4543. It's a moq-mux API break, so the PR targets dev, and it closes this issue.

(Written by Claude Opus 5.5)