CocoaPod deployment.

[theodab]

We should investigate distribution via CocoaPods.

[jgongo]

@theodab @TheModMaker I've got a working pod that I thought to publish but I have a doubt about this. The pod would contain fat frameworks (stripping automatically managed by Cocoapods) for both debug and release environments, and some reactive extensions to the player. Of course a client of the pod could directly use the Shaka Player without the reactive extensions, they are not mandatory.

In order to generate the fat frameworks I have compiled the Shaka Player Embedded with the prebuilt CDM, which is already distributed in binary form. Shaka Player Embedded has an open source license, but I can't find any license in the prebuilt CDM repository, and you need to be given explicit access in order to download it.

The question is, am I legally allowed to create and publish a pod including binary versions of the Shaka Player Embedded linked with the prebuilt CDM? Is there any problem if I do it?

[joeyparrish]

You are not entitled to redistribute the Widevine CDM. Please refer to the license text that accompanied the binary release of that CDM.

[jgongo]

Ok, then is there any way to distribute a pod of Shaka Player Embedded compiled with the Widevine CDM? You have to configure the EME implementation you will be using before building it, so I guess there's no way to distribute a built version of the player without the accompanying EME implementation.

To be clear, my strategy was to build a fat framework including all the architectures, and then publish it as a zip including my own extensions, using the vendored_frameworks support of Cocoapods. I don't see any other way of doing this, because as far as I know you can only use pods based on source files if you can build the project using Xcode (either the GUI or the CLI), and I don't think you can, can you?

[TheModMaker]

Using the Widevine CDM requires being a Widevine partner and requires signing an NDA (amongst other things). We can't allow just anyone to use it, the CDM is not for public use. Even though Widevine doesn't charge a fee for these things, it is still considered a private and commercial product. So any public deployments of Shaka Player Embedded will not include Widevine support, it will only support clear content (and clear-key).

If there is a way for the CocoaPod to look on the build machine for the library, then we could support that. That would require the user of the CocoaPod to download the CDM themselves. But we can't allow just anyone access to the CDM. That repository you linked to is controlled by limited ACLs.

[jgongo]

Yes, I know, I work for a company which has an agreement with Widevine.

Anyway, in order to add the CDM library the Shaka Player Embedded should have been compiled with the Widevine CDM as the EME implementation, no? Would that library work for clear content if the CDM framework is not present at runtime?

I'm asking this because in that case maybe you could create a pod containing only the Shaka Player Embedded frameworks compiled with the Widevine CDM, and then only distribute those frameworks and force the user to supply the CDM library (supposedly after signing the agreement with Google / Widevine)

[jgongo]

The only other thing I can think of (if you are interested) is to contribute the project used to generate the pod, so other users can use it as a template to use it internally. The project links to the Shaka Player Embedded and prebuilt CDM repositories using git submodules, so only people which already has access to the CDM repository could build the frameworks to distribute them internally using Cocoapods.

[TheModMaker]

Anyway, in order to add the CDM library the Shaka Player Embedded should have been compiled with the Widevine CDM as the EME implementation, no? Would that library work for clear content if the CDM framework is not present at runtime?

Correct, Shaka Player Embedded needs to be built to support Widevine. Unfortunately the way it works now, the CDM is linked during compile-time, so the loader will fail if the CDM isn't found at runtime.

We might be able to create a way for the EME plugin to ignore when the CDM isn't found; but the current way it's setup doesn't allow it. You can look at the current documentation for the current design (slightly wrong after the recent media refactoring). It assumes that the plugin is always available. We could change it to be a function that loads the plugin. That would allow the loading to fail and silently ignore that key system. But it would require changing both the EME plugin system and the Widevine CDM plugin.

I'm not sure if this should be added to v1.0. If it is, we'll delay v1.0 for longer; but not including it would make making changes harder since we need to consider reverse-compatibility.

The only other thing I can think of (if you are interested) is to contribute the project used to generate the pod, so other users can use it as a template to use it internally.

Maybe. Is there a way to mark the CocoaPod as internal so someone doesn't accidentally release it? How would that be easier than just running ./configure and make? What would be the process for someone to use that?

[joeyparrish]

Yes, if your company has an agreement with Widevine, you can certainly integrate the Widevine CDM with your own products and release the resulting binaries to your end-users. But distributing the CDM publicly for others to link to is not currently permitted.

So you should look into private pods: https://guides.cocoapods.org/making/private-cocoapods.html

[jgongo]

Maybe. Is there a way to mark the CocoaPod as internal so someone doesn't accidentally release it?

No, there's no way to mark it as "internal". The only difference between a private and a public pod is the repository where you publish it. If you want to make it public you have to register to trunk and publish there. For a private pod you just publish it to your own private repository.

I guess you can't accidentally release it, because in order to do so you have to register, and use different commands (pod trunk instead of pod repo). Too many accidents... 😄

How would that be easier than just running ./configure and make? What would be the process for someone to use that?

You usually have different environments where you want to test... simulator, device, debug, release... configuring, making and manually importing the created frameworks can be a pain. Using Cocoapods I have a pod with two subspecs, debug and release, that can be declared as dependencies in different targets. In addition each subspec contains a fat framework containing all the available architectures. Cocoapods takes care of stripping unneeded architectures so every device automatically receives just the architecture that needs.

For example, you could declare two targets with a dependency to the pod (in case you want to have debug support):

target 'MyApp-Debug' do
  pod 'ShakaPlayerEmbedded/Debug`
end

target 'MyApp' do
  pod 'ShakaPlayerEmbedded/Release`
end

and then you could run those targets wherever you want (simulator, physical device) without having to think about which framework to build, where to put it... You just would have to use the scheme and device switcher in Xcode and everything would be managed automatically.

[jgongo]

So you should look into private pods: https://guides.cocoapods.org/making/private-cocoapods.html

Thanks for the suggestion, we are already using them 😄

[isaacroldan]

Hi everyone, sorry to revive this topic from some months ago, but I'd like to know how to build the fat framework with all architectures, @jgongo do you have a script to do it? Is this something you could share? I'd appreciate it 🙇

Testing in both simulator and device is a bit of a pain without a fat framework :/

[jgongo]

Hi @isaacroldan unfortunately I'm no longer working in this project and I can't publicly share the code (it belongs to my previous employer and I no longer have access to it). Anyway the process is quite simple. This is what I did:

• Create a new private pod (For example CDM)
• Add the original CDM repository as a git submodule
• Whenever there is a new release of the CDM:
  • Run a process to generate a development fat framework and a release fat framework, which are generated inside the private pod. This can be easily done with the xccodebuild --create-xcframework, or you can use the action I created in this fastlane PR
  • Commit the generated framework
  • Generate a new version of your internal pod

If you use the action the fat frameworks could be generated like this:

create_xcframework(
  frameworks: [
    'ios/cdm_player/cdm/release/arm64-iphoneos/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/release/armv7s-iphoneos/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/release/armv7-iphoneos/widevine_cdm_secured_ios_tmux.framework'],
  output: 'frameworks/release/widevine_cdm_secured_ios_tmux.framework')


create_xcframework(
  frameworks: [
    'ios/cdm_player/cdm/dev/arm64-iphoneos/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/dev/armv7s-iphoneos/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/dev/armv7-iphoneos/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/dev/i386-iphonesimulator/widevine_cdm_secured_ios_tmux.framework',
    'ios/cdm_player/cdm/dev/x86_64-iphonesimulator/widevine_cdm_secured_ios_tmux.framework'],
  output: 'frameworks/dev/widevine_cdm_secured_ios_tmux.framework')

And then you could have two subspecs in your podspec including these generated frameworks as vendor frameworks:

  s.subspec 'Release' do |release|
    release.vendored_frameworks = 'frameworks/release/widevine_cdm_secured_ios_tmux.framework'
  end

  s.subspec 'Dev' do |dev|
    dev.vendored_frameworks = 'frameworks/dev/widevine_cdm_secured_ios_tmux.framework'
  end

You can use the CDM/Dev subspec for development purposes, and it will work in both devices and simulators. If you want to release your product you have to use the CDM/Release subspec.

[jgongo]

@isaacroldan The create_xcframework action hast just been accepted and included in fastlane 2.172.0 (not yet uploaded to RubyGems, but I guess it won't take long), in case you are interested.