Player init is very slow (~3s) in Firefox if there are a lot of variant tracks

[Dador]

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

What version of Shaka Player are you using?
nightly (795342d)

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?
Both.

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

What browser and OS are you using?
Firefox 107.0.1 (x86_64-apple-darwin)

What are the manifest and license server URIs?

What configuration are you using? What is the output of player.getConfiguration()?
Defaults from demo app.

What did you do?
Open video with a lot of variant tracks. In my case it's video with 120 variant tracks (30 audio languages * 4 resolutions = 120 variant tracks).

What did you expect to happen?
Video is playable without big delays.

What actually happened?
In Firefox there is big additional delay (around 3 seconds) before video is playable.

My thoughts
Seems like mcap is a bit slow in Firefox and it's called for each variant track (120 times in my case), so takes a lot of time (around 3 seconds in my case).
There is no issue in Chrome as mcap there seems to be very fast.
Gist to compare Firefox and Chrome: https://gist.github.com/Dador/1861acefcabf083e7238031f224bebc6

Issue #4574 and recent PR #4708 are related, but mcap polyfill is not enabled in Firefox. Enabling it for Firefox solves the performance issue but I guess that's a dirty way to solve it?

Maybe some caching could be added (or moved from mcap polyfill) to mediaCapabilities.decodingInfo usage in stream_utils.js?

[theodab]

This sounds like a reasonable idea to me.

[theodab]

I'll leave this open for now because you didn't provide a sample asset, so I can't verify how much the PR helped. If you test this yourself and find the startup time is good now, feel free to close this issue yourself, thanks.

[Dador]

Thank you.

I sent sample URL to email (shaka-player-issues).

Looks like PR didn't helped in my case. There are no cache HITs, log: https://gist.github.com/Dador/c0a3a6bf90f4dcad62c898529671f079 (I added logging for HIT/MISS)
In total it checked mcap 240 times (30 audios * 4 resolutions * 2 DRM options)

I have 30 audios and each audio have slightly different bitrate (you can see it in log), so decodingConfig is unique for each variant track. Cache key in polyfill is more simple, so that's why caching there helped (with forcefully enabled polyfill for Firefox, it checks mcap around 4 times).

[theodab]

I see.
I had considered adding some rounding to the bitrate before turning the config into a cache key, to increase the chance of a cache hit, but I was worried that it would lead to false cache hits. I don't think that making the key any vaguer would be a good idea.

Thinking about it, though, there's another possible optimization.
Looking at the code, most of the results of mediaCapabilities.decodingInfo are only used if the preferredDecodingAttributes configuration value is given one or more preferences. If that configuration value is left as an empty array, it looks like the only parts of decoding info we need are supported and keySystemAccess.keySystem (for DRM content). Those are both values that we don't strictly need to call the real mediaCapabilities.decodingInfo to know.

So maybe we could only call mediaCapabilities.decodingInfo if preferredDecodingAttributes is non-empty.

[avelad]

@Dador Can you test with main branch? Thanks!

[github-actions]

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.