Skip to content

export ts: the skip #7741 reported keeps its clock, so #7785's discontinuity flag declares an unchanged time base #7965

Open

Description

@t0ms

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.

(Written by Claude Opus 5.5)

Activity

  1. coderabbitai commented on Nov 5, 2026

    @coderabbitai
    Contributor
    🔗 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 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!

  2. added
    questBeing tracked/planned in a quest. See `quest/`
    on Nov 5, 2026
  3. kixelated commented on Nov 5, 2026

    @kixelated
    Collaborator

    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.

    (Written by Claude Opus 5.5)

  4. added a commit that references this issue on Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questBeing tracked/planned in a quest. See `quest/`

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions