Open bastimeyer opened 1 year ago
There are multiple different bugs:
seconds
attribute of the timedelta
/Duration
object (period.duration
or root.mediaPresentationDuration
) so it doesn't get the actual total seconds. A fix should be fairly simple.
BaseURL@availabilityTimeOffset
).
TimelineSegment
objects, so it generates segment URLs with nonsense data in the segment template.it looks like there's an issue with the duration and repetitions of the individual
TimelineSegment
objects, so it generates segment URLs with nonsense data in the segment template
https://livesim.dashif.org/livesim/segtimeline_1/testpic_2s/Manifest.mpd
Video timeline throughout a full hour:
<SegmentTemplate initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/t$Time$.m4s" timescale="90000">
<SegmentTimeline>
<S d="180000" r="150" t="151084412280000" />
</SegmentTimeline>
</SegmentTemplate>
Video timeline shortly after an hour mark has passed:
<SegmentTemplate initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/t$Time$.m4s" timescale="90000">
<SegmentTimeline>
<S d="180000" r="149" t="151084415160000" />
<S d="180000" r="12" />
</SegmentTimeline>
</SegmentTemplate>
For some reason, this results in invalid segment time values (from the t
attribute of the second S
element). I'm not sure if this is an issue with the stream itself. I haven't seen any timeline issues of that kind in other streams.
ISO/IEC 23009-1:2022(E):
SegmentTimeline.S@t
this value of this attribute minus the value of the
@presentationTimeOffset
specifies the MPD start time, in@timescale
units, 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 subsequentS
elements, the value shall be assumed to be the sum of the previousS
element's earliest presentation time and contiguous duration [i.e.previous S@t + @d * (@r + 1)
].
I didn't understand if it was fixed, therefore I will write. On the latest version, the problem still persists. There is no such problem in version 5.3.1 and below
2023-06-03 10:31:53.920 spawn: [stream.ffmpegmux][debug] Starting copy to pipe: /tmp/streamlinkpipe-58710-1-7969 2023-06-03 10:31:53.921 spawn: [stream.ffmpegmux][debug] Starting copy to pipe: /tmp/streamlinkpipe-58710-2-9202 2023-06-03 10:31:53.923 spawn: [cli][debug] Pre-buffering 8192 bytes 2023-06-03 10:31:54.059 spawn: [stream.dash][debug] video/mp4 segment 280520676: downloading (2023-05-03T14:27:38.018000Z / 2023-06-03T10:31:54.059020Z) 2023-06-03 10:31:54.060 spawn: [stream.dash][debug] video/mp4 segment initialization: completed 2023-06-03 10:31:56.430 spawn: [stream.dash][error] video/mp4 segment 280520676: failed (Unable to open URL: https://d-oc.akamaized.net/exp=1685874713~acl=%2f*~id=4dfaf8ad-1c35-4b19-9b5b-1a1a4f4ea46b~data=hdntl~hmac=d2842b34edf7c525c580a3351e797942cd57e16428170085803af82/dash/live/2093751/219026-241038/exchange219026ucqhi_219026_8000/hR6vqitMW/media_video_8000-280520676.m4s (404 Client Error: Not Found for url: https://d-oc.akamaized.net/exp=1685874713~acl=%2f*~id=4dfaf8ad-1c35-4b19-9b5b-1a1a4f4ea46b~data=hdntl~hmac=d2842b34edf7c525c580a3351e797942cd57e16428170085803af82/dash/live/2093751/219026-241038/exchange219026ucqhi_219026_8000/hR6vqitMW/media_video_8000-280520676.m4s)) 2023-06-03 10:31:56.432 spawn: [stream.dash][debug] video/mp4 segment 280520677: downloading (2023-05-03T14:27:44.018000Z / 2023-06-03T10:31:56.431691Z) 2023-06-03 10:31:56.578 spawn: [stream.dash][error] audio/mp4 segment 280520676: failed (Unable to open URL: https://d-oc.akamaized.net/exp=1685874713~acl=%2f*~id=4dfaf8ad-1c35-4b19-9b5b-1a1a4f4ea46b~data=hdntl~hmac=d2842b34edf7c525c580a3351e797942cd57e16428170085803af82/dash/live/2093751/219026-241038/exchange219026ucqhi_219026_3000/hR6vqitMW/media_audio_3000-280520676.m4s (404 Client Error: Not Found for url: https://d-oc.akamaized.net/exp=1685874713~acl=%2f*~id=4dfaf8ad-1c35-4b19-9b5b-1a1a4f4ea46b~data=hdntl~hmac=d2842b34edf7c525c580a3351e797942cd57e16428170085803af82/dash/live/2093751/219026-241038/exchange219026ucqhi_219026_3000/hR6vqitMW/media_audio_3000-280520676.m4s))
Without knowing the actual DASH manifest, this log output is useless. It's just showing the failed segment download attempts and the timestamp when it tried to access them. It's also not showing whether this is a dynamic stream or not. This thread is about dynamic DASH streams only.
Without knowing the actual DASH manifest
Where can I write to you to send a link?
Open a new issue with all the required details. If the stream URL can't be shared publicly, then you can find the infos on my GH profile for sending it to me privately. There is no guarantee though that I will take a look at this any time soon though, because I'm busy with much more important stuff right now.
Checklist
Streamlink version
Latest build from the master branch
Description
There's a bug in the DASH stream's segment generator where invalid segment URLs get yielded for dynamic streams at certain times. This affects dynamic streams with a segment-timeline (DASH IF test stream - fails reliably), and also ones without a segment-timeline (steamcommunity.com - had a failure once, second log output).
Apparently, this issue does only occur at times near the full hour mark, so this indicates that something must be wrong with the time/number offset calculations.
4607 is related (or maybe the same), but
presentationTimeOffset
is not present here...I haven't made any actual debugging efforts yet, but the issue was already present in 5.3.0 and earlier, before my recent code refactorings of the DASH stream parser.
The (first) log output is from an additional commit based on the branch of my PR #5199 which I'm going to submit after that PR was merged. This will add
--dash-manifest-reload-attempts
with default value of 3, similar to--hls-playlist-reload-attempts
, and it's very much needed for that specific test-stream URL, because connections get aborted by the server all the time, so manifest reloads need a certain number of retry attempts. That's unrelated to this issue though.Also unrelated to this specific issue is the muxer thread issue from the log below where it waits for 60s (
--stream-timeout
) for the copy-to-pipe threads to terminate, which they don't because their read() calls stall due to the missing data. That needs separate fixing.Debug log