[littlespex]

This PR will...

Answer Rob's review on video-dev#8083 by using contiguous as the signal for the PTS anchor, through the remuxer's own isVideoContiguous, and dropping the cross-level consecutive rule. Base is the upstream PR branch, so the diff here is only the simplification. Against upstream master the source change is three lines in generateIS.

Removed: the consecutive field of TransmuxState, the second argument of Remuxer.resetTimeStamp, the presentation-time rule for level switches, and the transmuxer specs that pinned them. Kept: the four remuxer anchoring specs; the level-switch spec now asserts the DTS fallback, that is one composition offset once at a discontinuity that coincides with a switch.

Why is this Pull Request needed?

Rob's two points hold. The sequence-number leg assumed aligned numbering across variants. Across a switch, timeOffset is only as good as alignStream's playlist alignment (it lines up the latest shared discontinuity and lets earlier boundaries fall out of the new playlist's durations), so binding the first PTS to it would turn drift into an overlap or a gap. Same-level discontinuities get an exact start from updateFromToPTS.

Are there any points in the code the reviewer needs to double check?

isVideoContiguous rather than a contiguous parameter on resetTimeStamp:

• It is cleared by resetNextTimestamp, which the transmuxer calls exactly when contiguous is false, and set when video was actually remuxed. So it reads as "contiguous, with previous video to continue from": an audio-only or failed previous fragment falls back to DTS.
• It is the notion remuxVideo already uses for hole and overlap repair, so anchoring and stitching agree.
• No interface change. The cost is implicit state: the decision depends on the transmuxer calling resetInitialTimestamp before resetContiguity before remux. The explicit alternative is resetInitialTimestamp(defaultInitPts, contiguous) and remuxer.resetTimeStamp(defaultInitPts, contiguous), four lines, if that reads better.

timeOffset !== 0 (Rob's suggestion in the second review comment) was built and run in the same harness. On the deltatre stream it gives the same result as isVideoContiguous. In the video-dev#7932 scenario (startPosition: 28.8, pinned level, seek to 0) it anchors the first segment on PTS (initPTS 0.087 instead of 0.020); sn 1 then appends audio at [0, 9.995] but no video and readyState stays 1. With a pinned level there is no track switch, so the video-dev#7700 re-anchor in generateIS never runs, and that is the case 1.6.18 fixed. isVideoContiguous leaves starts and seeks on the DTS anchor.

Testing

1210 unit tests pass, tsc and eslint clean. The deltatre, video-dev#7932 and video-dev#7977 browser checks were run on the first commit's build, which had this exact source change.

Resolves issues:

Follow-up to #9 for video-dev#8083. After review: fast-forward fix/discontinuity-initpts-anchor-8064 to this commit, which updates the upstream PR, then reply to Rob in the thread.

🤖 Generated with Claude Code