DASH live shaka player history sample fails with 2.2.4+

[radiantmediaplayer]

Have you read the FAQ and checked for duplicate issues: yes

What version of Shaka Player are you using: 2.2.5

Can you reproduce the issue with our latest release version: yes

Can you reproduce the issue with the latest code from master: not tried

Are you using the demo app or your own custom app: both

If custom app, can you reproduce the issue using our demo app: yes

What browser and OS are you using: Chrome 62 on Windows 10

What are the manifest and license server URIs:
(you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
https://storage.googleapis.com/shaka-live-assets/player-source.mpd

What did you do?
Go to https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-live-assets/player-source.mpd;lang=fr and try to play video - it did not start

What did you expect to happen?
It should start - it works fine with 2.2.3

What actually happened?
Infinite loop of manifest loads + webm chunks but stream never starts (well actually after a minute or so it started but then went to buffering then restarted and so on).

The console logs show repeated pattern of

cannot find segment: currentPeriod.startTime=0 lookupTime=1365636.021333456

[avelad]

I see the same error with other dash streams and i think that is the same issue that #1104

[radiantmediaplayer]

Could be related but this issue is specifically for live DASH streaming (not HLS live which I have not tested yet).

[TheModMaker]

The HLS version of the asset works. The issue may be caused by encoder drift. HLS is immune to encoder drift and the two versions are generated by the same process.

https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-live-assets/player-source.m3u8

[radiantmediaplayer]

If this is an issue with encoder drifting previous versions of Shaka player were able to correct the drift. I have put online examples to replicate the issue:
http://rmp-staging.com/shaka/test223.html
http://rmp-staging.com/shaka/test224.html

I am now able to tell that the issue was introduced in 2.2.4 release. I am testing in latest Chrome for Win 10. If you are seeing the same thing I see you will see that DASH Shaka Player History live stream in 2.2.3 starts and does not show warning logs. The same test with 2.2.4 shows that the stream does not start and warning logs can be found:

cannot find segment: currentPeriod.startTime=0 lookupTime=2397022.5883333683

Testing another live DASH stream (http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd) I can see that both 2.2.3 and 2.2.4 are able to display it correctly.

Our functional tests are not allowing to update to a version above 2.2.3 due to this issue. But if you can confirm this is an issue with the DASH Shaka Player History live stream then we can use another test vector for our tests.

[joeyparrish]

@radiantmediaplayer, thanks for the info! It may not be drift at all. It could be a regression. I'll look into it.

[joeyparrish]

Looks like this change broke it: dcb382e

[joeyparrish]

Ah, it's more subtle than that. The change that "broke" it was a good one, but it has exposed something else.

With that change reverted, the stream starts up at the left-hand-side of the seek range, which is wrong. We should start at the right-hand-side, the end of the seek range, at the live edge, but that isn't available.

So this may be drift, even though it was "working" in v2.2.3, because v2.2.3 was broken in a way that covers up this drift issue.

[joeyparrish]

The stream has drifted. The latest available segment is about 25s before the live edge. When you add that to the presentation delay of 30s, and we've drifted a total of 55s since the stream was started about 33 days ago.

But there is some other issue at work, too. For a stream which is drifting, you'd expect it to start playing eventually, once the playhead had fallen back into a range which was available. In this case, around -25s from the live edge. That isn't happening. The logs from StreamingEngine show that the timestamps it is trying to load don't change if you seek, so StreamingEngine may be stuck somehow on that unavailable timestamp. I need to investigate more.

[joeyparrish]

On a live stream in this failing state, shaka.media.Playhead.prototype.getStartTime_ continues to move forward, and this is what StreamingEngine uses to decide what to stream next when nothing is buffered yet. So the actual video element playhead is not being used, which is why neither seeking nor waiting resolves the issue.

[joeyparrish]

Fix cherry-picked for v2.2.7.

[radiantmediaplayer]

@joeyparrish thanks for fixing this.