Repository navigation
stream.dash: fix t attr in SegmentTimeline - #7075
Merged
Merged
Conversation
SegmentTimeline.segments only applied an <S> element's explicit @t when the running time was still 0, i.e. on the first segment. A later <S> that carries its own @t signals a gap/discontinuity in the timeline, but its start time was ignored and the segment was placed at the accumulated time instead, producing wrong $Time$ values (and therefore wrong segment requests). Apply @t whenever it is present.
bastimeyer
approved these changes
Sep 2, 2026
bastimeyer
left a comment
bastimeyer
left a comment
Member
There was a problem hiding this comment.
Thanks for the PR.
It's a valid bug, even if discontinuities are not supported by Streamlink. The MPD must be followed correctly, or invalid segment requests will be made, causing actual errors.
The fix and unit test are looking fine...
ISO/IEC 23009-1:2022(E) Section 5.3.9.6.2:
Element or Attribute Name Use Description SegmentTimeline specifies the Segment timeline information S 0..N specifies Segment start time and duration for a contiguous sequence of segments or identical durations, referred to as series in the following.
Note: The S elements are ordered in sequence of increasing values of the attribute@t.@tO this value of this attribute minus the value of the @presentationTimeOffsetspecifies the MPD start time, in@timescaleunits, of the first Segment in the series. The MPD start time is relative to the beginning of the Period.
The value of this attribute shall be equal to or greater than the sum of the previous S element earliest presentation time and the sum of the contiguous Segment durations.
If the value of the attribute is greater than what is expressed by the previous S element, it expresses discontinuities in the timeline.
If not present, then the value shall be assumed to be zero for the first S element and for the subsequent S elements, the value shall be assumed to be the sum of the previous S element's earliest presentation time and contiguous duration. [i.e. previousS@t + @d * (@r + 1)].
bastimeyer
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SegmentTimeline.segmentsonly honoured an<S>element's explicit@twhen the running time was still0:So
@twas applied on the first segment only. In aSegmentTimeline, a later<S t="...">sets a new start time to signal a gap / discontinuity (per ISO/IEC 23009-1). That start time was ignored and the segment was placed at the accumulated time instead, producing wrong$Time$values — and therefore requests for the wrong segments.Example:
<S t="0" d="4000" r="1"/>followed by<S t="10000" d="4000"/>should produce$Time$= 0, 4000, 10000, but produced 0, 4000, 8000.Fix
Apply
@twhenever an<S>carries it, not only on the first segment. Contiguous timelines (no@ton later segments) are unaffected.Test
Added
test_segments_timeline_gapwith a fixture MPD (dash/test_timeline_gap.mpd). Onmasterthe third segment is?t=8000; with this change it is?t=10000. The existing DASH segment tests stay green and ruff is clean.AI-assisted contributions
I used an AI assistant (Claude Code) to help find this and draft the test. I verified it myself — reproduced the wrong
$Time$red→green through the realMPDparser, ran the DASH test suite, and confirmed ruff passes. I understand the change and take responsibility for it.