[DASH]Floating point error is equal or larger than 0.2 causing video not playable

[wcsiu]

When the start time value at the timeline is large enough, the floating point error due to using binary to represent decimal in machine becomes so large that 0.2 may not be a big enough error buffer(the 0.2 comes from fillUriTemplate in shaka.dash.MpdUtils.). It causes the player fails to play the playlist.
Mpd sample:
http://pastebin.com/jjEDSX29

lib/dash/mpd_utils.js:

shaka.dash.MpdUtils.fillUriTemplate = function(
    uriTemplate, representationId, number, bandwidth, time) {
  if (time !== null) {
    goog.asserts.assert(Math.abs(time - Math.round(time)) < **0.2**,
                        'Calculated $Time$ values must be close to integers!');
    time = Math.round(time);
  }
...

I first saw the error at lib/dash/segment_template.js:

shaka.dash.SegmentTemplate.createFromTimeline_ = function(context, info) {
  goog.asserts.assert(info.mediaTemplate,
                      'There should be a media template with a timeline');
  var MpdUtils = shaka.dash.MpdUtils;

  /** @type {!Array.<!shaka.media.SegmentReference>} */
  var references = [];
  for (var i = 0; i < info.timeline.length; i++) {
    var start = info.timeline[i].start;
    var end = info.timeline[i].end;

    // Note: i = k - 1, where k indicates the k'th segment listed in the MPD.
    // (See section 5.3.9.5.3 of the DASH spec.)
    var segmentReplacement = i + info.startNumber;

    // Consider the presentation time offset in segment uri computation
    var timeReplacement = (start + info.presentationTimeOffset) *
        info.timescale;
...

Example:
start = 164615753.8606333, info.presentationTimeOffset = 0, info.timescale = 10000000, timeReplacement would sometimes be equal to 1646157538606333.2 and it should be 1646157538606333 so the error occurs.

[joeyparrish]

Thanks for the report. We'll look into it.

[torerikal]

Another case which seems to be the same issue as above, is integers too big to be handled by Javascript's number type.

We have a live stream setup where the segment timeline starts with e.g. t="14641133787680667". The number returned from parsing this number is 14641133787680668. This rounding error results in 404 errors when the segment URLs are composed from this offset.

The big numbers in the manifest, is a result of a timescale of 10,000,000, combined with offsets similar to Unix timestamps. In other words, the number of seconds from Jan 1 1970, multiplied by 10 millions, is part of the segment URLs. We are told this can't be changed.

We need a fairly quick workaround, and are considering rewriting Shaka's timeline number handling by integrating with a big integer library, like https://github.com/peterolson/BigInteger.js.

@joeyparrish If you don't see a simpler solution, do you see any issues with this strategy? Performance might be one concern.

[joeyparrish]

We are not interested in a bigint library at this time. You are welcome to make modifications, of course, but that is not a change we would accept in a pull request.

We only support integers as large as can be accurately represented in JavaScript. (After all, this is a JavaScript library.)

I would much prefer to see encoders create content that is compatible with the web platform. There's no reason a manifest should need such a large timescale. I recommend you raise this issue with your encoder vendor. It should be easy to fix, I would imagine.

I would be happy to help you discuss it with your encoder vendor. My email address can be found in CONTRIBUTORS.

Thanks!

[torerikal]

Thanks for sharing the Shaka dev team's stance on this.

Also, thank you for your offer to discuss it with the vendors. In the long run, we will definitely check these complicating factors out with the vendors of the stream infrastructure, and then I might get back to you for a common effort to sort it out.