perf: Caching mediaSource support for browser engine

[BrainChen]

We have just derived the repository by the old shaka version and found there seems the same optimization could be implemented on the latest shaka player.

When developing on each web core livingroom platform (Tizen, WebOS, Chromecast, etc.), we found that there takes a long time to parse the manifest between downloading the manifest and downloading the first content segment. After profiling it, we found that there was a frequent function called MediaSource.isTypeSupported in it, up to hundreds or even thousands (the pic attached below). But this situation does not happen on the latest Chrome or Safari.

We concluded that it must be related to the old browser engine (Chromium) that does not do optimization on it.

And we just cached the function call results and let it not calls that API so frequently. The data showed that it did help reduce the start lag by 40% on Chromecast, 15% on WebOS, and 12% on Tizen on average within 2 months.

We think it is constructive and want to share it. And we think the more variants the contents have, the more time they could be reduced on living room apps.

Thanks!

[avelad]

@JulianDomingo, can you test if on chromecast we have this gain?

[github-actions]

Incremental code coverage: 97.56%

[avelad]

@BrainChen You can apply the shaka.media.MediaSourceEngine.isTypeSupported change to media/transmuxer.js and polyfill/media_capabilities.js?. Thanks!

[BrainChen]

@avelad There seems exists cyclic dependencies when I implemented it in media/transmuxer.js. Hence extract this function into a single file.

[BrainChen]

@avelad Emmm, I think the change on polyfill/media_capabilities.js could possibly be conflicted with the unit test as some media types may be cached before and never called again.

[BrainChen]

@avelad Sorry for not obeying the precheck.
But I get puzzled that there is a difference between local build and CI build,
As I face StreamingEngine VOD plays FAILED, SegmentIndex MetaSegmentIndex updates through updateEvery FAILED, TextDisplayer layout using UI line alignment FAILED on my local laptop while the CI was not.

[theodab]

Thank you for your contribution!

[vasanth-fl]

@theodab @avelad @joeyparrish Will this change be cherry-picked to 3.2.16 as well? We would love to have this optimisation available on CAF v3 receiver to improve video start time on Chromecast.

[joeyparrish]

If it cherry-picks cleanly, then yes, I will cherry-pick this to v3.2.x as well as all the other active branches. If not, I'll let you know and you can make a PR against v3.2.x to get it into the next v3.2 release.

[BrainChen]

@vasanth-fl Be aware that some of the old shaka versions, EXTENDED_MIME_PARAMETERS, which is depreciated from the latest one, also work. That could also occupy much call time along with many combinations. We just retained the codecs and removed frameRate, channelsCount, etc. These parameters seem useless on Chromium and some browser engines as they are not the W3C standard.
See more details on:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1227017
• https://w3c.github.io/media-source/#widl-MediaSource-isTypeSupported-boolean-DOMString-type

[joeyparrish]

This did not cherry-pick cleanly to older branches. It was released in v4.3.1 only.

[vasanth-fl]

@BrainChen thanks for the inputs!

@joeyparrish thanks for the note. We will try to analyse and try to make a PR against 3.2.x branch.