IE/Edge: Player does not jump start gap; hangs indefinitely

[johnBartos]

Have you read the FAQ and checked for duplicate open issues?:
Yes. Opened as a followup to #1061

What version of Shaka Player are you using?:
2.3.2

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

Can you reproduce the issue with the latest code from master?:
Did not try

Are you using the demo app or your own custom app?:
Reproducible in the demo and JW (which we install via npm)

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

What browser and OS are you using?:
IE 11, Microsoft EdgeHTML 14.14393

What are the manifest and license server URIs?:
https://s3.amazonaws.com/bob.jwplayer.com/%7Ealex/107415/dash/dash2.mpd

What did you do?
Start playback

What did you expect to happen?
Playback begins; either the start gap is jumped or the stream is buffered with no gap (as is the case with FF/Chrome)

What actually happened?
The media element stalls in readyState 1; media is buffered at about 1.5s

[theodab]

Reproduced. Yeah, looks like this is a problem again.

[TheModMaker]

@theodab I doubt this is related to gap jumping. This seems like a media or platform problem.

The fact that the content starts at 1.5 seconds seems really weird. I might expect it to be 0.2 seconds because of PTS/DTS confusion, but 1.5 seconds is really large. It seems more like Edge is just rejecting the first segment we append.

[TheModMaker]

Is the buffer start closer to 1.7 seconds? I notice that the second keyframe of the video is at 1.708 seconds. So what may be happening is we somehow remove the first frame of the video (which is the keyframe), and the browser removes until the next keyframe.

[johnBartos]

@TheModMaker IIRC It was at ~1.56

[joeyparrish]

The buffer starts at 1.5416 on Edge. On Chrome and Safari, it starts at 0. I can't account for the difference yet, but it seems to be specific to the way Edge interprets the content. I'm going to do some more digging.

[joeyparrish]

Whatever the root of the issue at the platform level, enabling gap jumping for "large gaps" or increasing the tolerance of "small gaps" works around the issue.

Here are some examples of how to set those configurations:

// Increase the size of the gaps that Shaka Player will automatically jump:
player.configure({
  streaming: {
    smallGapLimit: 2.0,
  },
});

// Alternately, instruct Shaka Player to jump all gaps automatically:
player.configure({
  streaming: {
    jumpLargeGaps: true,
  },
});

[joeyparrish]

The first period's first video segment has a timestamp of 0.083 seconds according to the manifest. The first period's first audio segment has a timestamp of 0 seconds. The manifest contents look sane in terms of timestamps and presentationTimeOffsets.

[joeyparrish]

Artificially reducing the presentationTimeOffset by as little as 1 microsecond fixes the timestamp on Edge. I expect that the bug is caused by a rounding error in Edge's media stack that causes the first key frame to be removed, along with the rest of the GOP. The difference in the timestamps of the first two key frames is 1.541 seconds, which accounts for the discrepancy.

[joeyparrish]

I have archived this content at a URL we control so that it is sure to outlive the MS Edge bug report I'm working on. Here's a quick repro URL:

https://v2-3-2-dot-shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/_bugs/1281/dash2.mpd;lang=en-US;play;build=uncompiled

[joeyparrish]

Here's the bug I filed on Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/16134130/

[joeyparrish]

Working around the initial gap is not enough. We have to work around another gap at around 60 seconds. For that, I find that I have to reduce the start of the append window.

[joeyparrish]

Workaround cherry-picked for v2.3.3.

[johnBartos]

@joeyparrish Thanks for the in-depth analysis and fix 👍

[joeyparrish]

Happy to help!

[joeyparrish]

Closing this stale external (non-Shaka) issue. In particular, Edge is completely different now, so this is likely no longer valid.