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

Playback freezes at end of video in Edge/IE11 #913

Closed
forbesjo opened this issue Jun 29, 2017 · 6 comments
Closed

Playback freezes at end of video in Edge/IE11 #913

forbesjo opened this issue Jun 29, 2017 · 6 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@forbesjo
Copy link

forbesjo commented Jun 29, 2017

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

What version of Shaka Player are you using:
2.1.4

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

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

What browser and OS are you using:
IE11 and Edge 38.14393.1066.0, Windows 10

What are the manifest and license server URIs:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd (this issue does not happen with other test content)

(you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)

What did you do?
Seek near the end of the video and let the video finish.

What did you expect to happen?
Playback to end and set the player in an ended state

What actually happened?
Playback stops at 633.9008751. Duration is 634.5666666.
End of the video buffer is 634.5666666, end of audio is 634.3547499.

@forbesjo forbesjo changed the title Playback freezes at end of video Playback freezes at end of video in Edge/IE11 Jun 29, 2017
@forbesjo
Copy link
Author

Note that this source has never played through to the end in any version of the Shaka Player. It does in dash.js and native Edge playback.

@TheModMaker
Copy link
Contributor

This is a platform bug. We call MediaSource.endOfStream to indicate that no more content is coming. The browser should update the duration to match the already buffered content, but sometimes it doesn't. In this case, IE/Edge is stopping, waiting for more content.

You may want to file a bug on Edge to fix it. We will look into trying to work around it.

@TheModMaker TheModMaker added type: bug Something isn't working correctly type: external An issue with an external dependency; not our issue; sometimes kept open for tracking and removed needs triage labels Jul 10, 2017
@joeyparrish joeyparrish removed the type: external An issue with an external dependency; not our issue; sometimes kept open for tracking label Aug 10, 2017
@joeyparrish
Copy link
Member

IE and Edge are correctly truncating the duration to the largest of the buffered ranges for audio & video. It's not obviously a platform bug as we previously thought.

@joeyparrish
Copy link
Member

joeyparrish commented Aug 10, 2017

If we comment out setBuffering() in Playhead, the problem disappears. This is called by PlayheadObserver, which calculates when we should or shouldn't be buffering. So PlayheadObserver is sending Player into a buffering state on IE & Edge, when it shouldn't.

In this case, audio SourceBuffer ends at 634.35, video ends at 634.56, and duration is 634.56 (on all browsers). On Chrome, video.buffered is (surprisingly) the larger of the two, while on IE it's the smaller of the two SourceBuffers. This calculation:

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

is therefore true on Chrome and false on IE.

@joeyparrish joeyparrish added this to the v2.2.0 milestone Aug 10, 2017
@joeyparrish
Copy link
Member

In PlayheadObserver, the local value duration is the video duration minus a fudge factor of 0.1 seconds (shaka.media.PlayheadObserver.FUDGE_FACTOR_), but the actual discrepancy for this content is 0.21 seconds.

The real source of truth is mediaSource.readyState, which is 'ended'. Ideally, we would use this instead of comparing buffered ranges to the duration.

@joeyparrish joeyparrish self-assigned this Aug 10, 2017
joeyparrish added a commit that referenced this issue Aug 11, 2017
PlayheadObserver has to know when the stream has been fully buffered.
It did this based on duration and the buffered ranges, but that
required the use of a fudge factor and caused false negatives on IE &
Edge.

Instead, use MediaSource's  readyState attribute to decide when we've
buffered to the end.  This way, IE & Edge do not go into a buffering
state when the discrepancy between audio & video sizes is larger than
an arbitrary fudge factor.

Closes #913

Backported to v2.1.x

Change-Id: I307dce12a883201a88a18bf5b9a84f954a1c5033
@joeyparrish
Copy link
Member

Cherry-picked for v2.1.7.

@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

4 participants