Description
I have a multiple-period DASH stream produced by a proprietary encoder.
When playing it in Shaka, I found that the player got stuck occasionally at period boundaries. The loading circle keep spinning and the browser keep retrieving the manifest regularly, but there is no attempt to download the segment files.
After briefly digging in the Shaka code, I found the issue is likely caused by error in floating point manipulation. Shaka uses the start time of last-period and the presentation time of last segment to find the next period and segment to play. However, when it compare the time values, minor error introduced in floating point manipulation would cause it to miss the correct period/segment. Then Shaka will keep waiting for segment in the last period which is already over.
Here is the screenshot for Chrome's debug console. The "findPeriodContainingTime_" function should return period 12, but it didn't due to the small error in the time value passed to the function.
Here is the sample manifest, the player has problem loading period "13":
multi-period-stuck-floating-error.mpd.txt
The same issue happens on at least the following functions:
- https://github.com/google/shaka-player/blob/master/lib/util/stream_utils.js#L513
- https://github.com/google/shaka-player/blob/master/lib/media/segment_index.js#L78
My MPD has a timescale of 1000, but I guess the same problem would occurs with any timescale > 1, since floating point errors happen even when there is only a few significant digits, e.g. 0.1 + 0.7 = 0.7999999999999999 < 0.8
I did a quick workaround to compensate for 1ns when comparing time values, and the stuck no longer happen. So I guess Shaka should compensate for floating point errors when it lookup the period/segment with computed time values.
Shaka: master checkout from github (40a92b6)
Chrome: 56.0.2924.28 beta (64-bit)