High Media Start Up on Shaka 4.x

[jaskarancodes]

Have you read the Tutorials?
Yes

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

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

NA

What version of Shaka Player are you using?
4.3.0

What browser and OS are you using?
WebOS and Tizen (All Models year 2017 onwards)

Please ask your question
Team, we recently migrated from Shaka 2.5.10 (main) to Shaka 4.3.0 (8a10a95). Post upgrading, we are seeing an increase in start lag of about 2.5s on Tizen and WebOS platforms. From our observations, the start lag seems to be higher on DRM contents and even higher on multi-key DRM contents as compared to Shaka 2.5.10. Need some suggestions on the most optimal way to reduce the media start-up time. We are using the following player configuration for the Shaka 4.3.0 player

{
  "abr": {
    "enabled": true,
    "defaultBandwidthEstimate": 1500000,
    "useNetworkInformation": false
  },
  "mediaSource": {
    "forceTransmux": false
  },
  "preferredAudioChannelCount": 2,
  "streaming": {
    "maxDisabledTime": 0,
    "bufferingGoal": 16,
    "rebufferingGoal": 3,
    "bufferBehind": 8,
    "lowLatencyMode": true,
    "ignoreTextStreamFailures": true,
    "stallThreshold": 3,
    "retryParameters": {
      "maxAttempts": 3,
      "timeout": 30000,
      "connectionTimeout": 30000,
      "stallTimeout": 15000
    }
  },
  "manifest": {
    "availabilityWindowOverride": 840,
    "retryParameters": {
      "maxAttempts": 3,
      "timeout": 30000,
      "connectionTimeout": 30000,
      "stallTimeout": 15000
    },
    "hls": {
      "sequenceMode": false,
      "ignoreManifestProgramDateTime": false,
      "useSafariBehaviorForLive": false
    }
  },
  "drm": {
    "retryParameters": {
      "maxAttempts": 3,
      "timeout": 30000,
      "connectionTimeout": 30000,
      "stallTimeout": 15000
    }
  },
  "subtitle": {
    "useNative": false
  },
  "quality": {
    "maxBandwidth": 20000000
  }
}

[joeyparrish]

There may be a performance regression. We will need to look into it.

I see you have tried v4.3.0, which is out of date. Can you try the latest v4.7 release? (Currently v4.7.9, but v4.7.10 will be out in the next couple days.) There have been many performance-related PRs since v4.3.

[jaskarancodes]

@joeyparrish Unfortunately, moving to 4.7.9 version would be difficult for us to incorporate. I'll review the changelog for 4.7.9, meanwhile if you have anything specific in mind we can look at, do let us know.

[joeyparrish]

We just released v4.7.10. I also cherry-picked everything I could into v4.3.14 (since v4.3 is our current LTS branch), but many changes did not apply in that branch.

If v4.3.14 doesn't help, you will need to move to a newer feature branch in order to get the necessary changes. You can find our branch maintenance policy here: https://shaka-project.github.io/maintenance/shaka-player.html#branch-maintenance-policy and our list of currently-maintained branches here: https://github.com/shaka-project/shaka-player/blob/main/maintained-branches.md

And if none of these things help, we will need to do additional work, which would land in main first and be cherry-picked to active branches afterward.

But you have to understand that we aren't going to dive into a performance issue in v4.3.0, which is already 15 months old and 14 bugfix releases out of date. It's not practical. You at least have to try v4.3.14 (latest bugfix for the branch you're on) and v4.7.10 (latest release overall) before we will dig deeper, in case your issue has already been fixed in the 15 months since v4.3.0 came out. Thanks!

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

[Strongbow19]

One thing we noticed is that usage of mediaCapabilities.decodingInfo API for filtering manifest is causing extra time. For content with a lot of variants, etc 100+, it could be quite a burden for LR device. (If 5ms each, then we end up spending 500ms)

Is there any suggestion on how to improve over this part?

[Strongbow19]

I checked latest main branch and I found related code only gets more complicated by adding support for multi codec/mimeType variant.

After checking polyfill for mediaCapabilities and I think at least for LR, there could be some room for performance improvement. Trying to reduce the calls to API, by inferring result of one variant from another.
For LR devices (other than tizen), where polyfill is used, we can see that if two variant have same audio codec, video codec, and key system, then their result will be the same.
For web, where native API is used, if two variant only differ in framerate, then maybe we can assume that the if a higher frame rate variant can be played smoothly, then a lower frame rate one should also run smoothly. Group variants and take the advantage of their similarity.

Also needs to add a config to control this, so that can switch between compatible mode and performance mode.

categoryCache=new Map();
for(const variant of variants) {
	// if key is a counter/random number, then execute for all variants, 	a compatible mode versus a performance mode
  	const categoryKey = buildKey(variant);

  	if(categoryCache.has(categoryKey)) {
		variant.decodingInfo= categoryCache.get(categoryKey)
 	 }else {
		const res = MediaCapability.getDecodingInfo(variant);
		// if it's supported or smooth
		if(shouldCache(res)) {
                   categoryCache.set(categoryKey, res)
                }
	}
}

[Strongbow19]

@shaka-bot reopen

[avelad]

@Strongbow19 are you interested on send a PR to fix it?

[shaka-bot]

@jaskarancodes Does this answer all your questions? If so, would you please close the issue?

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.