seekRange is too large when not all segments are available

[janouskovec]

Have you read the FAQ and checked for duplicate issues:
Yes.
What version of Shaka Player are you using:
2..2.5
Can you reproduce the issue with our latest release version:
Yes.
Can you reproduce the issue with the latest code from master:
Not tested.
Are you using the demo app or your own custom app:
We are using custom app.
If custom app, can you reproduce the issue using our demo app:
Yes, the issue is reproducible in demo app.
What browser and OS are you using:
N/A
What are the manifest and license server URIs:
(you can send the URIs to [email protected] instead, but please use GitHub and the template for the rest)

<MPD type="dynamic" xmlns="urn:mpeg:dash:schema:mpd:2011" profiles="urn:mpeg:dash:profile:isoff-live:2011" xmlns:cenc="urn:mpeg:cenc:2013" minBufferTime="PT7.000S" timeShiftBufferDepth="PT86460.000S" minimumUpdatePeriod="PT5.000S" availabilityStartTime="2015-01-01T00:00:00.000+00:00" publishTime="2018-01-12T15:47:39.310+00:00" suggestedPresentationDelay="PT7.000S"> <BaseURL>https://st16-4.o2tv.cz:443/ab/43d09f9e0fb4d5f17fc387f787717d45/1515772044894/dna-140-tv-pc-20180112T153000/</BaseURL> <Location>https://st16-4.o2tv.cz:443/ab/43d09f9e0fb4d5f17fc387f787717d45/1515772044894/dna-140-tv-pc-20180112T153000/mpd</Location> <Period start="PT0S" id="1"> <AdaptationSet startWithSAP="1" segmentAlignment="true" id="1101" mimeType="video/mp4" > <SegmentTemplate timescale="90000" media="$RepresentationID$/$Number%06d$.m4s" initialization="$RepresentationID$/IS.mp4" startNumber="0"> <SegmentTimeline> <S t="8613059400000" d="90000" r="998"/> </SegmentTimeline> </SegmentTemplate> <Representation id="1101-365" codecs="avc1.4d401f" width="1024" height="576" sar="1:1" bandwidth="2354000"/> <Representation id="1101-360" codecs="avc1.42c015" width="512" height="288" sar="1:1" bandwidth="736000"/> <Representation id="1101-366" codecs="avc1.4d401e" width="720" height="410" sar="1:1" bandwidth="1304000"/> <Representation id="1101-364" codecs="avc1.42c00c" width="256" height="144" sar="1:1" bandwidth="336000"/> </AdaptationSet> <AdaptationSet startWithSAP="1" segmentAlignment="true" id="1102" mimeType="audio/mp4" lang="ces" > <SegmentTemplate timescale="90000" media="$RepresentationID$/$Number%06d$.m4s" initialization="$RepresentationID$/IS.mp4" startNumber="0"> <SegmentTimeline> <S t="8613059400000" d="90000" r="998"/> </SegmentTimeline> </SegmentTemplate> <Representation id="1102-365" codecs="mp4a.40.5" audioSamplingRate="24000" bandwidth="96000"/> <Representation id="1102-360" codecs="mp4a.40.5" audioSamplingRate="24000" bandwidth="64000"/> </AdaptationSet> </Period> <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-iso:2014" value="https://st16-4.o2tv.cz:443/get-utc-timestamp"/> </MPD>
What did you do?
I played above manifest.

What did you expect to happen?
What actually happened?

Please see the manifest. The segmenttimeline start at time availabilityStartTime+("SegmentTemplate/SegmentTimeline/S@t"/"SegmentTemplate@timescale")=2015-01-01T00:00:00.000+00:00+(8613059400000/90000)=2018-01-12T15:31:00+00:00.
The demo shaka player ignores start of timeline, so left edge of progress bar is equal currentTime-timeShiftBufferDepth attribute.
If currentTime-timeShiftBufferDepth is less than currentTime-segmenttimeline start, the content is seekable under start time of the timeline. The segments not found in this case of course.

We need some API to determine start of the timeline to protect left edge of segmenttimeline in our custom app.

[ondrejpar]

Further info: version 2.0.4 had the following undocummented API to get the start of the timeline:
shakaPlayer.manifest_.presentationTimeline.getEarliestStart();
which worked in uncompiled version only. Playhead used this method to "crop" position when seeking.
Presentation timeline is now accessible using "official" API, but the getEarliestStart method is missing.

[joeyparrish]

TL;DR: Try player.seekRange() for the seekable range of media timestamps.

We don't ignore S@t. We definitely parse and use it. But we have two parts in our streaming model: the segment index, and the presentation timeline. This is in keeping with the DASH spec.

The presentation timeline is defined by availabilityStartTime, the current time, and timeShiftBufferDepth. This is why the seek range is what it is in Shaka Player.

The segment index is defined in this manifest by SegmentTimeline and S. This is the manifest's map of what segments are available on the server, and their media timestamps.

It sounds like your segments do not align with the presentation timeline, which is a common issue in live DASH streams. In some cases, the encoder/packager puts the wrong information in availabilityStartTime. In others, it's an issue with the server's clock or with the client's clock synchronization config.

And in some cases, it's "drift". The segment index and the presentation timeline get further apart the longer the stream is running. This is really really really common in DASH live streams. So common that we intend to stop trusting availabilityStartTime and derive the live edge from the segment index instead. This is a big change, though, so we haven't been able to work on it yet. If you are interested, you can follow along on this work in issue #999.

Looking at your manifest text, I see:

<MPD type="dynamic"
  timeShiftBufferDepth="PT86460.000S"
  publishTime="2018-01-12T15:47:39.310+00:00"
  availabilityStartTime="2015-01-01T00:00:00.000+00:00>

...

<SegmentTemplate timescale="90000"><SegmentTimeline>
  <S t="8613059400000" d="90000" r="998"/>
</SegmentTimeline></SegmentTemplate>

Assuming publishTime is when you fetched the manifest, the stream had been running for 95,701,659 seconds. The earliest media timestamp is 8,613,059,400,000 / 90,000 => 95,700,660, and the latest media timestamp is 8,613,149,310,000 / 90,000 => 95,701,659. So I don't see any evidence of drift.
(Assuming that publishTime is the time the request was made. I can't confirm this without having access to a manifest URI.)

If you need to know the seekable range of media timestamps, we provide that in player.seekRange(). Have you tried that yet? Does this answer your question?

[ondrejpar]

(I collaborate on this with the original reporter, so I'll ocassionaly add some info here).
player.seekRange always returns start and end values that differ by 86453 seconds - approximately 1 day, which corresponds (roughly) to the timeshift buffer depth. Also, Shaka demo app shows seekbar which is approximately 1 day long, but everything before the "real" start date is not in fact seekable - playback freezes, because the segments aren't found.
What we are trying to achieve is to find out the oldest timestamp usable for seeking.
(@janouskovec will probably need to prepare new MPD, as this one has already expired).

[joeyparrish]

@ondrejpar, if the "real" start date is not now - timeShiftBufferDepth, then it sounds like your timeShiftBufferDepth parameter is incorrect. If 1 day's worth of content is not actually available on your server, then you need to correct your manifest.

[ondrejpar]

Well, in version 2.0.4 this worked much better in our use case: Shaka understood that the earliest media timestamp is 95,700,660 (as you wrote above) and didn't allow to seek before that. Even the seekbar in the demo app did only cover range between that timestamp and now. The seekRange method still returned interval defined by timeshiftBufferDepth (iirc).
Basically, what we need is to get that "earliest media timestamp" using API, because we can't fix the manifest and it can't be computed reliably. It was possible in 2.0.4 using the unofficial API mentioned above (shakaPlayer.manifest_.presentationTimeline.getEarliestStart();).
Is there any way to obtain this information from Shaka player? Even private methods would help at the moment, although it would be great if this would be in the public API. Any help would be much apprectiated :)

[joeyparrish]

Ah, I see. Let me look again. We may be making a mistake in seekRange().

[joeyparrish]

@ondrejpar, can you please provide a manifest URI so that I can reproduce your issue exactly?

[joeyparrish]

You can send manifest URIs to [email protected] if you are not able to share them publicly. Please reference this issue number if you do so.

[ondrejpar]

I can't, but I'll ask @janouskovec to send one (or provide a download link).

[janouskovec]

I sent URL to [email protected].

[joeyparrish]

Confirmed. The seek range is 1 day, but there are only 3000 or so seconds of content in the manifest.

[janouskovec]

if the "real" start date is not now - timeShiftBufferDepth, then it sounds like your timeShiftBufferDepth parameter is incorrect. If 1 day's worth of content is not actually available on your server, then you need to correct your manifest.

I think, that MPD is correct. MPD contains SegementTime and S@t atribute, so "real" start date and availability of segments should be derived from the attribute S@t.

[joeyparrish]

Yes, it's definitely a regression. We will work on a fix.

[joeyparrish]

Cherry-picked for v2.3.3.