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

Safari fails to load at startTime #2267

Closed
alexandercerutti opened this issue Dec 2, 2019 · 5 comments · Fixed by #2271
Closed

Safari fails to load at startTime #2267

alexandercerutti opened this issue Dec 2, 2019 · 5 comments · Fixed by #2271
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@alexandercerutti
Copy link
Contributor

alexandercerutti commented Dec 2, 2019

Hi,
before labeling this as a bug, I preferred to open a question issue to discuss this (maybe I'm doing something wrong?).

We are moving to using Shaka also on Safari. My situation is as follows: our player can have some cases:

  • Starts at 0;
  • Starts at N;
  • Content ends and, on seeking back, we reload the content (due to Ads Engine, we have to detach Shaka).
  • Contents stops (due to midroll) and on resume, we have to reload the content at specific position.

On Chrome it works all fine (with Dash).
On Safari, it starts always at 0, even if we pass at player.load() a startTime value N (any number).
To "fix" this, we had to use a "trick", that we were using also without Shaka: MediaFragments.

I attach you what I had to do:

let streamUrlWithTime = streamSourceURL;

if (this.startTime && playbackInfo.mimeType !== "application/dash+xml") {
        /**
         * There was once upon a time, a duration parameter
         * applied to #t=<startTime>,<duration>
         * But then it has been discovered its incompatibility
         * with Chrome on iOS. Therefore it was removed
         * for the sake of mental sanity.
         */
        streamUrlWithTime += `#t=${this.startTime}`;
}

return this.player.load(streamUrlWithTime, this.startTime, playbackInfo.mimeType).then(() => {
    // after load...
});  

Where streamSourceURL is just an M3U8 / HLS Url of a non-live content, and playbackInfo is just some metadata we obtained from our content server. MimeType is application/x-mpegUrl. We are sure that this.startTime has a value.

I'd like to understand if this is a known problem in Safari (for Shaka), or if I'm doing something wrong.
What I saw is that, on Safari, an HLS content starts at 0 because the duration is not available yet.
If I breakpoint "slowly" after .load, it works fine, probably because Safari is able to get the duration and then we "unlock the breakpoint".

I'm using Shaka 2.5.6

Let me know.
Thank you!

@alexandercerutti alexandercerutti added the type: question A question from the community label Dec 2, 2019
@TheModMaker
Copy link
Contributor

By default, on Safari, we use native src= playback. There may be a bug in our handling of startTime with src=. It looks like we should support it, but maybe native HLS doesn't work the same.

You can disable this and use normal MSE playback (the same as Chrome), set the streaming.useNativeHlsOnSafari configuration to false.

@alexandercerutti
Copy link
Contributor Author

alexandercerutti commented Dec 2, 2019

@TheModMaker Thank you for your reply.

I just tried as you said, with streaming.useNativeHlsOnSafari => false, but I received error 4023, HLS_REQUIRED_ATTRIBUTE_MISSING, with data: ["BANDWIDTH"].

@matvp91
Copy link
Contributor

matvp91 commented Dec 2, 2019

What I've done before is set'ing video.currentTime when the duration is available. Where other browsers allow to set the currentTime before the asset has enough data to play, that's unfortunately not the case for Safari.

if (isSafari && startPosition) {
  function setStartPosition() {
    mediaElement.removeEventListener('durationchange', setStartPosition);
    mediaElement.currentTime = startPosition;
  }
  mediaElement.addEventListener('durationchange', setStartPosition);
}

If I'm not mistaken, when Shaka uses src=, it no longer has control over the buffer, thus fetching segments at a specific position in a stream would not work.

@avelad
Copy link
Member

avelad commented Dec 3, 2019

I created the PR #2271 to resolve it!

joeyparrish pushed a commit that referenced this issue Jan 3, 2020
@joeyparrish joeyparrish added type: bug Something isn't working correctly and removed type: question A question from the community labels Jan 3, 2020
@joeyparrish joeyparrish added this to the v2.6 milestone Jan 3, 2020
joeyparrish pushed a commit that referenced this issue Jan 15, 2020
@joeyparrish
Copy link
Member

These changes have been cherry-picked for v2.5.8.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 3, 2020
@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

Successfully merging a pull request may close this issue.

6 participants