shaka-player: Regression in segment time calculation - presentationTimeOffset is added when it should not be

https://github.com/google/shaka-player/commit/20750504fecd4855f2997dcd2eb92a7024dc2bdc appears to have introduced a regression, with the key line in question being https://github.com/google/shaka-player/blame/master/lib/dash/segment_template.js#L324. Possibly more of the logic is suspect - I did not dig deeper beyond finding why the first numbers with my video were off.

As far as I can tell, the function find appears to be there to determine the ~MPD start time in seconds~ segment position of the segment containing periodTime, which is an offset from the start of the period in seconds.

Using presentationTimeOffset in this calculation is incorrect. PTO does not determine anything about the MPD timeline, it says what media timestamp (PTS) corresponds to periodTime = 0. You should only use it for aligning the media timeline with the MPD timeline.

The referenced commit causes any segmentTemplate-using streams with presentationTimeOffset to have segments scheduled at the wrong moments in time.

Still working on getting playable URL for you but I thought I would post immediately as it seemed pretty clear cut to me. Let me know if you want more supporting material and evidence and I am happy to provide.

Example MPD:

<MPD type="dynamic" availabilityStartTime="1970-01-01T00:07:00Z" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash264" timeShiftBufferDepth="PT15M" minimumUpdatePeriod="PT15S" minBufferTime="PT2S" publishTime="2018-01-17T14:49:04.237755Z" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <!--availabilityStartTime is adjusted to add a delay of 00:07:00 to the availability timeline compared to the authoring timeline. Timestamps in period/segment paths indicate authoring time (UTC), not availability time (UTC+delay). Playback uses availability time.-->
  <Period id="p_1516198946762" start="P17548DT14H22M26.762S">
    <!--Starts 2018-01-17 14:21:59.762Z (1,516,198,946,762 ms from epoch) on the authoring timeline.-->
    <!--Starts 2018-01-17 14:28:59.762Z (1,516,199,366,762 ms from epoch) on the availability timeline.-->
    <AdaptationSet segmentAlignment="true" group="1">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track0" mimeType="audio/mp4" startsWithSAP="1" bandwidth="64000" audioSamplingRate="48000" codecs="mp4a.40.2" />
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true" group="2" par="16:9" maxHeight="720" maxWidth="1280" frameRate="30">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track1" mimeType="video/mp4" startsWithSAP="1" bandwidth="3000000" sar="1:1" width="1280" height="720" codecs="avc1.640032" />
    </AdaptationSet>
  </Period>
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="Manifest.mpd" />
</MPD>

The period starts at some point on 2018-01-17. Both the MPD timeline zero point and the media timeline zero point are in 1970. The latter is indicated by presentationTimeOffset. The first segment to be played at period start is number 1.

However, because of the problematic commit, Shaka adds PTO to the first segment, trying to play back something from 2066 instead (it tries to play segment number 379054268 as I post this).