Shaka player seek behaviour in safari browser

[akash-kush9]

Have you read the FAQ and checked for duplicate open issues?
Yes

If the problem is related to FairPlay, have you read the tutorial?
Yes

What version of Shaka Player are you using?
4.7.13

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

Can you reproduce the issue with the latest code from main?
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?
Not sure

What browser and OS are you using?
Safari 17.5 / MacBook Pro Sonoma 14.5

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
Cannot share client related details

What configuration are you using? What is the output of player.getConfiguration()?
const options = {
drm: {
advanced: {
"com.widevine.alpha": {
serverCertificate: serverCertificate,
videoRobustness: "SW_SECURE_DECODE"
},
"com.microsoft.playready": {
videoRobustness: "SW_SECURE_DECODE"
},
"com.apple.fps.1_0": {
serverCertificate: serverCertificate,
videoRobustness: "SW_SECURE_DECODE"
}
},
servers: {
"com.widevine.alpha": getLicenseKeyUrl(),
"com.microsoft.playready": getLicenseKeyUrl(),
"com.apple.fps.1_0": getLicenseKeyUrl()
},
retryParameters: {
timeout: 0, // timeout in ms, after which we abort; 0 means never
maxAttempts: 5, // the maximum number of requests before we fail
baseDelay: 1000, // the base delay in ms between retries
backoffFactor: 3, // the multiplicative backoff factor between retries
fuzzFactor: 0.5 // the fuzz factor to apply to each retry delay
}
},
manifest: {
retryParameters: {
timeout: 0, // timeout in ms, after which we abort; 0 means never
maxAttempts: 5, // the maximum number of requests before we fail
baseDelay: 1000, // the base delay in ms between retries
backoffFactor: 3, // the multiplicative backoff factor between retries
fuzzFactor: 0.5 // the fuzz factor to apply to each retry delay
}
},
streaming: {
rebufferingGoal: 1,
bufferBehind: 6,
bufferingGoal: 10,
durationBackoff: 1,
ignoreTextStreamFailures: true,
startAtSegmentBoundary: false,
useNativeHlsOnSafari: sessionObj?.drmType !== "none",
retryParameters: {
timeout: 0, // timeout in ms, after which we abort; 0 means never
maxAttempts: 5, // the maximum number of requests before we fail
baseDelay: 1000, // the base delay in ms between retries
backoffFactor: 3, // the multiplicative backoff factor between retries
fuzzFactor: 0.5 // the fuzz factor to apply to each retry delay
}
},
abr: {
enabled: true,
restrictions: abrRestrictions
}
};

What did you do?
Play Some encrypted content with Nth start position, i.e player.load(url,startPosition)

What did you expect to happen?
Video will load from the seeked position and start play from that position without any issues/unnecessary delays. (Working as such on chrome)

What actually happened?
For safari browser, the video is seeked to nth position but before the correct segment is played, initial frame of video can be seen. It will in state of freeze for 2-3 seconds then next frame of nth position will be displayed and after 1-2 seconds playback will continue from the nth position.

Are you planning send a PR to fix it?
No

[avelad]

try to change manifest.hls.useSafariBehaviorForLive = false

[akash-kush9]

With that above mentioned change i think it helped with the initial frame which didn't last that long but the nth position frame is still seen for 2-3 seconds before playback starts, was that the intended behaviour ?

Is there no way to ensure nothing is seen until playback can be ready to play from nth position?

[akash-kush9]

Is there any streaming/manifest property that can help in safari with the initial frame @avelad ?
And wait until playback is ready to play, just like chrome?

[avelad]

I'm sorry, I was wrong, I didn't realize that you're using Fairplay ... try with streaming.useNativeHlsForFairPlay = false but... You have to read the tutorial carefully for FairPlay with MSE; not all providers may support it.

[akash-kush9]

I am using shaka 4.7.13, when i tried adding useNativeHlsForFairPlay under streaming option.
Invalid config, unrecognized key .streaming.useNativeHlsForFairPlay

[avelad]

4.7 is no longer maintained, and 4.8 today we will release the latest version and discontinue it, please try 4.9.x. Thank you!

[akash-kush9]

One more thing, i have 2 type of videos, encrypted video as main content and unencrypted video as trailer. assigning false for encrypted doesn't start the playback, i can see the .mpd file is downloaded but no fragments are downloaded.

But upgrading version to 4.9.11 does seems to help with the playback a lot for most asset. Is there any change that could explain this behaviour?

[avelad]

There are many changes, so it is possible, right now I can't tell you what change can affect this.

[akash-kush9]

When set to true shakaplayer we let native player play the video, so if i still see the first frame of video. Can i assume native player is doing that and not much can be controlled from shaka player or us. So this will be default and final behaviour on the playback behaviour?

[avelad]

We cannot control the native behavior, only use the native player or MSE, sorry!