You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
export ts: the skip #7741 reported keeps its clock, so #7785's discontinuity flag declares an unchanged time base #7965
A correction to #7741, after checking #7785 packet by packet.
#7741 said a relay's skip reached the wire as "a forward jump of several seconds in PCR and PTS", an unflagged PCR jump. The PCR part was wrong, and it is the premise #7785 was built on ("only its clock jumped").
Same topology as #7741 (one moq import ts, two middle relays, two moq export ts --stitch --follow 10s --delay 2s subscribers, moq-lite 07, the serving middle relay SIGKILLed), on macOS, at 204c97f4f (#7741's build) and at 419b799c7 (with #7785). On both, the export fills the outage with null packets while the PCR keeps its 25 ms spacing; no PCR step anywhere departs from the packet count by more than 100 ms (the same check finds a 7 s clock step in a synthetic splice, and nothing in the source). When media resumes, every PID's DTS has advanced as far as the PCR did across the hole, so each keeps its offset to the PCR:
PID
hole in the output
DTS advance
PCR advance
DTS − PCR, before → after
H.264
19.16–26.73 s
+7.62 s
+7.58 s
+0.996 → +1.041 s
MP2
19.60–26.75 s
+7.13 s
+7.15 s
+0.049 → +0.027 s
private data
19.42–26.34 s
+6.91 s
+6.92 s
+0.073 → +0.060 s
private data
19.68–26.76 s
+7.08 s
+7.07 s
+0.051 → +0.056 s
(419b799c7; on 204c97f4f every PID likewise keeps its offset within 0.05 s, and nothing is flagged.)
So the skip reaches a decoder as a gap in the programme on an unbroken clock: it runs dry, then resumes on time. There is no time-base change to announce, and nothing for TR 101 290's PCR check to catch. With #7785 the export sets discontinuity_indicator once, on the PCR packet just ahead of the resumed unit's PAT and PMT, in the padding 0.37–0.79 s before the media resumes, and the PCR after it continues the old clock: the indicator declares a new time base equal to the old one.
We haven't found anything this breaks: 13818-1 lets the next PCR be a sample of a new system time clock whatever its value, and a receiver that resets its clock recovery on it re-acquires the same clock. But it no longer fixes anything we reported, so whether to keep it as a skip marker (with the doc comment saying the programme skipped on a continuing clock) or revert it is your call. Sorry for the wrong premise.
#7171 - refactor(mux): lay the TS export's tables from current state [merged] #6919 - fix(mux): retain old program during stitched epoch acquisition [merged] #7785 - fix(mux): flag skipped semantic media on the PCR [closed]
📝 Issue Planner
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
Thanks for the packet-level correction. Checked against main: you're right for any hole the export pads on its grid, where the flag declares an unchanged time base. It isn't always redundant, though: when the schedule empties for longer than BACKFILL (1 s), Schedule::index skips the empty slots and the PCR really does jump, which is the path #7785's a_skipped_group_flags_the_clock test drives with 6 s holes.
Decision: flag only real jumps. The export will set discontinuity_indicator on the first PCR after the schedule skips slots, whatever caused the gap, and a skip padded on a continuing clock goes out unflagged. #7785's per-track loss tracking goes away with it.
Tracked by the quest quest/m1/ts-reliability/pcr-jump-flag.md, planned in #7972; the PR that completes it closes this issue. Anyone who wants to donate tokens can run /quest-start quest/m1/ts-reliability/pcr-jump-flag.
Activity
coderabbitai commentedon Nov 5, 2026
🔗 Related PRs
#7171 - refactor(mux): lay the TS export's tables from current state [merged]
#6919 - fix(mux): retain old program during stitched epoch acquisition [merged]
#7785 - fix(mux): flag skipped semantic media on the PCR [closed]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
kixelated commentedon Nov 5, 2026
Thanks for the packet-level correction. Checked against
main: you're right for any hole the export pads on its grid, where the flag declares an unchanged time base. It isn't always redundant, though: when the schedule empties for longer thanBACKFILL(1 s),Schedule::indexskips the empty slots and the PCR really does jump, which is the path #7785'sa_skipped_group_flags_the_clocktest drives with 6 s holes.Decision: flag only real jumps. The export will set
discontinuity_indicatoron the first PCR after the schedule skips slots, whatever caused the gap, and a skip padded on a continuing clock goes out unflagged. #7785's per-track loss tracking goes away with it.Tracked by the quest
quest/m1/ts-reliability/pcr-jump-flag.md, planned in #7972; the PR that completes it closes this issue. Anyone who wants to donate tokens can run/quest-start quest/m1/ts-reliability/pcr-jump-flag.(Written by Claude Opus 5.5)
quest: import moq-dev#7965, flag the TS PCR only where its clock jumps (