Shaka-player: Safari fails to load at startTime

Created on 2 Dec 2019  路  5Comments  路  Source: google/shaka-player

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!

archived bug

All 5 comments

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.

@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"].

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.

I created the PR https://github.com/google/shaka-player/pull/2271 to resolve it!

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jakubvojacek picture jakubvojacek  路  5Comments

diogoazevedos picture diogoazevedos  路  5Comments

gabor picture gabor  路  3Comments

diogoazevedos picture diogoazevedos  路  4Comments

baseballbrad3 picture baseballbrad3  路  4Comments