Why does Chromecast use MediaCapabilities polyfill?

[avelad]

I have seen the following comment:
https://github.com/shaka-project/shaka-player/blob/main/lib/polyfill/media_capabilities.js#L27-L29

Is this due to a particular version of Chromecast? Would it work on other versions (Android TV eg)?

In the internal laboratory that you have, what model of chromecast are you using?

Models: https://en.wikipedia.org/wiki/Chromecast#Model_comparison

[avelad]

Note: chromecast model detection in JS https://gist.github.com/lfalke/bd7eba442eae4d50075ecdf89dc9edf6

[joeyparrish]

We were told by the Cast platform team at one time that the API was present, but not likely to provide meaningful data. I will check to see if that is still the case, or if there are certain firmware versions for which we could rely on the data.

[joeyparrish]

I can't recall who exactly gave us the advice to avoid MediaCapabilities on Cast, but now that I'm digging into this with the team, there are apparently three different implementations. Some devices are Linux-based, some are Android-based, and some are Fuchsia-based. Each has a separate implementation behind MediaCapabilities, so the state of MCap in the Cast ecosystem is unclear.

[avelad]

As far as I know, those based on Android have the word Android in the userAgent, so if we know that for example Androids have a valid implementation, we could enable it for them.

[joeyparrish]

Here's what I've discovered so far from conversations with the Cast and Fuchsia teams:

• Android-based Cast devices use the same implementation as Chrome on Android phones, so the data is meaningful there
• Linux-based Cast devices return smooth: false and powerEfficient: false for everything; supported will always be accurate with respect to the container and codec only; resolution and framerate will be ignored, which can lead to bad decisions; falling back to shaka.polyfill.MediaSource.patchCastIsTypeSupported_ will get proper checks for resolution and framerate, albeit in a non-standard way; don't expect major platform updates or new Linux-based devices
• Still looking for information on the implementation in Fuchsia-based devices
• A fourth category of devices uses a stripped down environment without a true browser; here the MCap APIs exist, but immediately throw when called 😭; this must continue to be banned explicitly unless the MCap implementation can be updated

To continue supporting Linux-based cast devices, we could always have a special MCap polyfill based on cast.__platform__.canDisplayType. Today we have a generic MCap polyfill based on isTypeSupported, plus a cast-specific isTypeSupported polyfill that calls into cast.__platform__.canDisplayType. Since we depend on MCap, polyfilling it directly for Cast without changing isTypeSupported might be a little cleaner.

[avelad]

Determine current behavior of Media Capabilities API on Fuchsia --> https://bugs.chromium.org/p/chromium/issues/detail?id=1169950

[avelad]

After including the Android change, and seeing the status of Fuchsia, I think the question can be closed.