Less than optimal Javascript arithmetic leading to bad segment request URLs

[TobbeEdgeware]

Javascript has a limitation in the numbers it can represent since all numbers are stored as double-precision floats. In particular, there is a biggest integer that can be accurately represented and it is 2**53 - 1 (Number.MAX_SAFE_INTEGER).

This needs to be considered when delivering live media. In particular, when using the Smooth Streaming default timescale of 10 000 000 the maximum timestamp corresponds to 28.5 years.
This should be enough in most cases, but with the most common live Smooth Streaming offset (availabilityStartTime for DASH), the UNIX Epoch 1970-01-01, the timestamp becomes bigger than the MAX_SAFE_INTEGER and precision is lost.

In particular, this may lead to incorrect URLs when SegmentTimeLine is used, since additions of timestamps and durations don't give the exact timestamp of the next segment.

Some players have extended their calculations using a bigint library, but that has been discussed for Shaka player before (#383), and decided not to be implemented.

We ran into this problem with our live output, but could not change the timescale away from 10 000 000 due client behavior. Instead, we changed the availabilityStartTime to 2000-01-01, which reduced the arithmetic precision needed down to 53 bits. This removed our playback problem in dash.js which uses standard Javascript integer arithmetic.

However, on shaka player we still see a problem, and we have tracked that down to the use of floating-point calculations as startTime is scaled by dividing with the timescale in mpd_utils.js and then multiplied with the timescale in segment_template.js to arrive at the timeReplacement value to be used in the segment URI.

We don't ask to change bigint arithmetic, but we think that there should be a slight change to loose as little precision as possible by keeping unscaled timestamps and use integer arithmetic. We are preparing a pull request, and hope that it is welcome?

#####################

• What version of Shaka Player are you using?
  2.0.5

  • Can you reproduce the issue with our latest release version?
    Yes

  • Can you reproduce the issue with the latest code from master?
    Yes

• Are you using the demo app or your own custom app?
  Demo

• What browser and OS are you using?
  Any, but Chrome and OS X is one example

• What did you do?
  Tried to stream our own live content. No external test stream available right now.

• What did you expect to happen?
  Content should play

• What actually happened?
  Content did not play properly because of missing segments. Server log showed inaccurate timestamps in media URLs

[TheModMaker]

A PR for this would be welcome. The idea for the linked PR looks good, just make sure that all the tests still pass.

[TobbeEdgeware]

We should not write that this introduces extra latency, because segments are still generated directly when we have the corresponding data. For HLS, one should notice no difference.
It is rather a possible shift between incoming media time and outgoing media time, to make sure that we don't generate DASH segments too late according to wall-clock.

[joeyparrish]

@TobbeEdgeware, this issue has been closed for 11 months, and I can't find any mention of the word "latency" in this thread until you brought it up. It also doesn't appear in the commit that fixed the issue.

Did you mean to comment on some other issue?

[TobbeEdgeware]

@joeyparrish I'm terribly sorry. The remark was for another project, and somehow I had this old page open and typed it here by mistake. The ticket should remain closed.

[joeyparrish]

Okay, cool. Just making sure. No harm done!