Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DASH live shaka player history sample fails with 2.2.4+ #1105

Closed
radiantmediaplayer opened this issue Nov 3, 2017 · 11 comments
Closed

DASH live shaka player history sample fails with 2.2.4+ #1105

radiantmediaplayer opened this issue Nov 3, 2017 · 11 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@radiantmediaplayer
Copy link

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
Copy link
Collaborator

avelad commented Nov 3, 2017

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

@radiantmediaplayer
Copy link
Author

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

@michellezhuogg michellezhuogg added the type: bug Something isn't working correctly label Nov 4, 2017
@michellezhuogg michellezhuogg added this to the v2.3.0 milestone Nov 4, 2017
@TheModMaker
Copy link
Contributor

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
Copy link
Author

radiantmediaplayer commented Nov 15, 2017

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
Copy link
Member

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

@joeyparrish joeyparrish self-assigned this Nov 21, 2017
@joeyparrish joeyparrish changed the title DASH live shaka player history sample fails with 2.2.5 DASH live shaka player history sample fails with 2.2.4+ Nov 21, 2017
@joeyparrish
Copy link
Member

Looks like this change broke it: dcb382e

@joeyparrish
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Fix cherry-picked for v2.2.7.

joeyparrish added a commit that referenced this issue Nov 27, 2017
There are two ways Playhead should be able to recover from a drifting
stream:

1. Wait until the initial position is available
2. Seek to another position

Neither of these was working.  For one, we couldn't detect seeks
before content was loaded.  For another, we were constantly updating
the initial streaming position, so a drifted stream would never catch
up to our expectations.

This fixes both issues so that a drifting stream can at least recover.

Relates to issue #999 (drift tolerance)

Closes #1105

Change-Id: I8d2eedcff25b92b42ecd2e1f361d45ecbddd26ba
@radiantmediaplayer
Copy link
Author

@joeyparrish thanks for fixing this.

shaka-bot pushed a commit that referenced this issue Nov 28, 2017
On Edge & IE, the timing of "loadedmetadata" and "timeupdate" events
is different, and exposed a race condition in the fix for #1105.
This solves the race by canceling any pending "early seek" handling
once "loadedmetadata" fires.

A fix for the fix of issue #1105

Change-Id: I5587a72e12c6b28beb0b3ea36f2665a0f1e39f08
joeyparrish added a commit that referenced this issue Nov 28, 2017
On Edge & IE, the timing of "loadedmetadata" and "timeupdate" events
is different, and exposed a race condition in the fix for #1105.
This solves the race by canceling any pending "early seek" handling
once "loadedmetadata" fires.

A fix for the fix of issue #1105

Change-Id: I5587a72e12c6b28beb0b3ea36f2665a0f1e39f08
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

6 participants