GNOME Bugzilla – Bug 755115
dashdemux: relate wall clock time to timestamps for live streams
Last modified: 2018-11-03 13:40:22 UTC
Currently dashdemux uses the availabilityStartTime to match timestamps of a live stream with the real world clock. It seems this is not a requirement. See "http://live.unified-streaming.com/loop/loop.isml/loop.mpd?format=mp4&session_id=50375". This stream fails to play because it tries to play from the first segment that would correspond to 'now' in the wall clock but the mapping is completely wrong so it never finds such segment. Is there an official way to match timestamps to real world time? Or should we invent a way to do it? Like get the last segment end as 'now' at the beginning of the stream and use that as a base? Ideas?
I suspect the issue with this stream is not the use of "now", but how dashdemux is mapping $time$ when using a SegmentTimeline. If I'm reading the manifest correctly, I don't think it should work. The SegmentTimeline has an explicit repeat count that does not provide sufficient segments to get to "now". My understanding is that for a live stream, availabilityStartTime defines the origin (time=0, segment_number=1). If the segment duration was 2 seconds, startNumber=1 and "now" was 2 hours since availabilityStartTime, the last available segment would be: 2*3600/2 - startNumber = 3599 If timeShiftBufferDepth was 10 minutes, the first available segment would be: 3599 - (10*60) = 2999 To quote the standard: "For @type='dynamic' this attribute shall be present. In this case it specifies the anchor for the computation of the earliest availability time (in UTC) for any Segment in the Media Presentation." Looking at the section of the spec dealing with SegmentTimeline: The value of the @t attribute minus the value of the @presentationTimeOffset specifies the MPD start time of the first Segment in the series. When the SegmentTemplate is in use and the $Time$ identifier is present in the SegmentTemplate@media then - at least one Segment Index (‘sidx’) box shall be present - the values of the SegmentTimeline shall describe accurate timing of each Media Segment. Specifically, these values shall reflect the information provided in the Segment index (‘sidx’) box, i.e. the value of @timescale shall be identical to the value of the timescale field in the first ‘sidx’ box, - the value of S@t shall be identical to the value of the earliest_presentation_time in the first ‘sidx’ box of the Media Segment described in S, - the value of S@d shall be identical to sum of the values of all Subsegment_duration fields in the first ‘sidx’ box of the Media Segment described in S. - The Segment URL for a Media Segment is obtained by replacing the $Time$ identifier by the earliest presentation time obtained from the SegmentTimeline.
So you would consider this stream invalid? I have another one that is similar here: http://bitlivedemo-a.akamaihd.net/mpds/stream.php?streamkey=bitcodin Would your analysis be the same for this one?
These also seem to have similar problems: http://dashif.org/test-vectors/#DSO
I've discussed this stream with a DASH expert that I know. In his opinion the manifest is not valid. The SegmentTimeline is intended to cover the entire timeShiftBufferDepth. The first entry in the SegmentTimeline has a t attribute the defines the first time value in the buffer. So far, so good. However, the problem with the stream is that it has a presentationTimeOffset value, which when subtracted from "now", gives a value that does not exist in the timeline. As defined in the spec: "The SegmentTimeline element shall contain a list of S elements each of which describes a sequence of contiguous segments of identical MPD duration. The S element contains a mandatory @d attribute specifying the MPD duration, an optional @r repeat count attribute specifying the number of contiguous Segments with identical MPD duration minus one and an optional @t time attribute. The value of the @t attribute minus the value of the @presentationTimeOffset specifies the MPD start time of the first Segment in the series." There appears to be insufficient values in the SegmentTimeline. The timeShiftBufferDepth is set to one minute, but there is only 57.6 seconds of segments in the timeline. Also the presentationTimeOffset changes on every refresh, which means the DASH client should be re-basing its timeline every time the manifest is reloaded.
That's also how I understand it. Can you report this for the DASH-IF test vectors here? https://github.com/Dash-Industry-Forum/Test-Vectors/issues
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/300.