feat: Add support for Modern EME and legacy Apple Media Keys for FairPlay

[avelad]

Add support for Modern EME and legacy Apple Media Keys for FairPlay
Add more FairPlay documentation

[littlespex]

I'm curious if everyone thinks adding vendor specific code is a good long term approach. Would we add individual utils for every vendor? What about apps that only use Shaka for DASH playback? Can these utils be excluded?

[avelad]

It is a good question, I have done it this way to simplify the life of integrators and because there is almost no duplication, but it can be changed. I would like to hear more opinions

[joeyparrish]

I've heard from developers both inside and outside Google that Shaka's modularity is a concern.

Today, you can compile the player in a way that only includes the modules you care about. But the result is still a monolithic JS binary. Instead, I think many people would like to be able to include a list of composable modules in their application (either to be bundled into the app or to be loaded as separate scripts for development).

So in today's world, you can compile your own custom build of Shaka Player that drops any module you want. No other part of Shaka Player depends on FairPlayUtils, so I think it should be moved from build/types/core to build/types/hls, so that anyone who excludes HLS will exclude FairPlayUtils, as well.

In the future, it would be nice to have runtime modularity instead of build-time modularity, as well as easier granularity for those modules.

An alternative to moving FairPlayUtils out of core would be to move the vendor-specific snippets into documentation. Or perhaps into a "contrib" folder that gets checked by the compiler for type-compatibility, but doesn't get included in any build by default.

I think the easiest thing would be to keep the vendor-specific snippets, but move the module from core to build/types/hls. But I'm open to the other ideas I mentioned, or any other ideas y'all might have.

[joeyparrish]

@littlespex, if the three of us can agree on this issue, I think I'm happy with the rest of the PR.

[avelad]

I don't agree with moving it into HLS, since Fairplay can work with DASH (I'm working on it with some provider) and with src=.

[joeyparrish]

You could always put it into its own group. Individual files can be excluded at build-time, but it's hard to discover the fact that FairPlayUtils is independent enough to be excluded. If it were in its own group, (build/types/fairplay), then people who use the build customization (if there are any other than me) could python build/build.py +@complete -@fairplay.

[avelad]

I agree to create a fairplay (type) folder... but... it would be moving fairplay_utils.js in its entirety, and that means a breaking change, so a 5.0 version would have to be made and I think that's not the best thing right now since It would delay this change too long.

[avelad]

A solution would be to create the group, include it by default, but leave the file in util, what do you think?

[littlespex]

I'm good with leaving the vender specific functions as is and moving the whole feature from core to types.

As for the build time vs run time modularity, embracing ES modules should provide a solution that covers both cases. If the core and all of the modules are compiled separately, the app developer can include the desired modules via static or dynamic imports, and modern bundlers will package the code accordingly.

[avelad]

@joeyparrish @littlespex, I have added a new type, I hope that now the solution will convince you more.

[joeyparrish]

Looks good to me, but waiting to approve until we all agree on the inclusion and placement of the utils.