Improvement of segment timeline $Time$ accuracy #702
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR solves #690.
With the following SegmentTimeline snippet
the second segment erroneously gets the wrong timestamp
5369174663790087 because it is calculated as
and results in an HTTP 404 error when requesting the segment using the$Time$ .mp4 segment.
By avoiding, the division by 10000000 a more accurate calculation can be done:
5369174623790086 + 40000000 = 5369174663790086
This is fixed in the PR by storing the unscaled values
unscaledStart
andunscaledPresentationOffset
and using them for generating thetimeReplacement
for the segment request URL.A lot of other calculations use times scaled to seconds as before, but since they don't need to be fully accurate, no change is needed.
Unfortunately, we haven't found a good way to add a unit or functional test for this PR, but no existing tests are broken. The fix solves the issue we have seen and makes our streams play in shaka player as they do in dash.js. We don't have reliable public URL, though.