Can't play at the live edge

[ErvinGegner]

• What version of Shaka Player are you using?
  2.0.2

• Can you reproduce the issue with our latest release version?
  Yes

• Can you reproduce the issue with the latest code from master?
  Yes

• Are you using the demo app or your own custom app?
  Custom app

• If custom app, can you reproduce the issue using our demo app?
  Yes

• If custom asset, what manifest and license server URIs?
  http://w9nnd57mi5zm5.cloud.elementaltechnologies.com/out/u/live-dash.mpd

• What did you expect to happen?
  Only one video resolution to be preloaded

• What actually happened?
  All available video resolutions were preloaded, producing a delay of approximately 15 seconds between manifest load finish and actual video start.

Hi everyone, just to add more info I'll say that the situation is the following:
I'm loading mentioned manifest which has 3 different resolutions available (960px, 640px, 480px).
By the looks of it(in network tab) all 3 resolutions are preloaded and buffered and then only one is actually played.
Is there a way to configure desired resolution before/during manifest load? Just to avoid the loading delay or is it something wrong in the manifest itself?

Thanks guys

[joeyparrish]

@ErvinGegner, we don't buffer all resolutions at once. We load the initialization segments of all resolutions so that we can make zero-latency adaptation decisions later. For this content, init segments are between 638 and 733 bytes each. In total, we loaded 2738 bytes of initialization segments in 4 HTTP requests. On my internet connection here at work, this took a total of 377ms.

I noticed that playback took a while to get started, though. Now that it's playing, it's hovering around 31 seconds behind the live edge (-0:31 in the video controls). I jumped to the live edge by clicking on the timecode, but it eventually had to buffer and fall back to -0:04 and again to -0:06.

For some reason, we are unable to play at the live edge. I checked for clock sync issues and found none. I see that the manifest uses minimumUpdatePeriod of 30s, suggestedPresentationDelay of 25s, and minBufferTime of 30s. These don't seem crazy off-hand, so it should work.

We will investigate further.

[ErvinGegner]

Great, thank you for the reply, looking forward to 2.1.0

[joeyparrish]

I found the source of the problem. The Playhead class decides whether we are in a buffering state or not. However, it doesn't account for the live edge, beyond which we can't buffer. This calculation only works for VOD:

var duration = this.video_.duration - fudgeFactor;
var atEnd = (bufferEnd >= duration) || (this.video_.ended);

[joeyparrish]

Separate from the bug in our code, there also seem to be some slight problems with the parameters of your manifest. Even after we have fixed our bug, you should make some changes to improve the performance of your stream.

With a presentation delay of 25s, updating the manifest only every 30s means we do still occasionally underrun. You should make the delay slightly larger than the update period. Either 35s suggestedPresentationDelay and 30s minimumUpdatePeriod or 25s delay and 20s update should do the trick.

Also, you have a minBufferTime of 30s, which is pretty high. We have to make an exception for the live edge, but this parameter is the minimum amount of content that must be buffered before a player starts playback. If the user were to seek backward in the stream, say, 45s, the player would have to buffer 30s ahead before it could play again. This should be reduced to something like 3s or 6s (1 or 2 segments).

[joeyparrish]

We've just pushed a fix for the bug in our code. This should make things much better. You can see the fixed code in the master branch and in our nightly build.

I still recommend some changes to your minBufferTime and to either presentationDelay or minimumUpdatePeriod as outlined above. Please let me know if there's anything else I can do for you.

[ErvinGegner]

@joeyparrish Wonderful I think you've done everything you could on your side so now its my turn to apply configurations as you've recommended.
Thank you for quick response and the overall assistance.

[joeyparrish]

No problem. We are always happy to help.