Player got stuck when playing multi-period live DASH

[albertcsm]

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)

[albertcsm]

Reproduced with v2.0.5 and latest commit today (3cd2506)

[TheModMaker]

Would it be possible to get a live (playable) version of the manifest so we can test that our fix actually works? You can send it privately if you want (my email is in CONTRIBUTORS and on my profile).

[albertcsm]

Sorry, I am not be able to host the MPD right now.
Maybe I can help verify the fix or I can publish the stream to some external WebDAV server.

[TheModMaker]

It would be really helpful if you could give us something to test ourselves. But in the meantime, can you try the following patch:

diff --git a/lib/dash/mpd_utils.js b/lib/dash/mpd_utils.js
index 7ee7dee..993ef05 100644
--- a/lib/dash/mpd_utils.js
+++ b/lib/dash/mpd_utils.js
@@ -320,12 +320,8 @@ shaka.dash.MpdUtils.fitSegmentReferences = function(
             firstReference.startByte, firstReference.endByte);
   }
 
-  if (dynamic)
+  if (periodDuration == null || periodDuration == Infinity)
     return;
-  goog.asserts.assert(periodDuration != null,
-                      'Period duration must be known for static content!');
-  goog.asserts.assert(periodDuration != Infinity,
-                      'Period duration must be finite for static content!');
 
   var lastReference = references[references.length - 1];

[TheModMaker]

I just pushed a change that might help your problem. I think the problem is that the last segment of the Period before it isn't being adjusted to the end of the next Period. This introduces a gap that makes us try to fetch the wrong Period.

@albertcsm Please try again from master.

[joeyparrish]

We believe this bug has been fixed. Please let us know when you have a chance to test.

[albertcsm]

The problem seems solved in the master branch, thanks.

[joeyparrish]

Thank you for letting us know!