Configurable key system priority

[MilosRasic]

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

yes

Is your feature request related to a problem? Please describe.

When using Shaka Player for Smart TV platforms, we usually have to deal with platforms that have both Widevine and Playready implemented. This is both a blessing (we can choose) and a curse (both may not work equally well, either because of Shaka Player or device issues). Managing which one to use in which case and on which platform can be annoying, especially when the only way to control this is to include or omit DRM server config.

Describe the solution you'd like

It would be great if we could specify priority for each DRM system so that Shaka could then decide which one of the available systems to use based on that. dash.js has something like that Dash-Industry-Forum/dash.js#3107

It would also be great for resilience if Shaka Player could fall back to another configured system if one fails. Most of us are not aware of all the problems the widely diverse devices on the market may have with one DRM system or the other. Also, DRM servers may have issues at times as well.

Describe alternatives you've considered

Currently we are facing severe issues with mixed DRM and non-DRM content when using Shaka Player with PlayReady on most devices, and will solve this by forcing it to use Widevine only wherever we know it's guaranteed to be supported. However, we still have to use PlayReady for Xbox in the same app.

Additional context
none

[TheModMaker]

There are a few ways you can configure this. First, we'll only use key systems we have a license server for. So if you want to only use Widevine, then only configure Widevine license server. Secondly, we support multi-DRM where we'll only use supported key systems. If the manifest specifies both Widevine and PlayReady, we'll only use the one supported by the platform; although this only happens during startup and we won't switch if it fails later. Thirdly, the preferred way of specifying priority is with the order in the manifest. We'll try the first one, then the second one. This also has the advantage of being cross-player since this is specified in the DASH IOP.

Are these options enough, or is there something more you need?

[MilosRasic]

As I mentioned, we can currently solve this problem by dynamically generating DRM server config. Long-term it would be nice to have some more explicit client-side control over what gets preferred.

[OrenMe]

Want to add to @MilosRasic request.
In new Edge both PR and WV are supported.
Sometimes there are manifests with CENC support with both WV and PR content protection.
In this case if we blindly set both licesne urls then the way Shaka selects the DRM system to use, IIRC, is by order they appear in the manifest.
This means that if WV is first then the less secure DRM system will be chosen.

If we want to overcome this we need to dynamically set the DRM system license url and also know what we need while we don't always have control over the API and DRM systems we work with.

The fact that now Edge Chrumiom has a strange support scheme where it sometimes support both WV and PR and sometimes only WV(Mac, Win7) makes it very difficult.
Adding a way to set the priority will solve this complexity.

[riksagar]

That's funny, I was just about to file a very similar ticket! We just started supporting Xfinity Flex and that supports both PR and WV. We saw that shaka will use whichever ContentProtection is listed first in the mpd. I'd not noticed (or I forgot) that this is a DASH-IF IoP.

While I realize that's not technically a problem it's causing our QA team to complain. They want us to use one drm consistently across all content on a platform. One less variable when investigating issues.

Over the years our content creation toolchain has evolved, hence some manifests have WV before PR while for others it's reversed. Unfortunately our content team didn't think the order of ContentProtection boxes needs to be consistent, and now there's way too much content to reencode.

For a given platform I guess we can remove one of the license server urls - as you suggested - but it seems a bit risky as a general approach. You never know if a device manufacturer will release a new model that drops one or the other DRM. Rewriting the manifest on the fly is also an option - wouldn't be the first time.

[joeyparrish]

I'll tag this as a feature request and rename it accordingly. Here's my proposal for an API:

player.configure({
  drm: {
    preferredKeySystems: [
      'com.microsoft.playready',
      'com.widevine.alpha',
    ],
  },
});

Or:

player.configure('drm.preferredKeySystems', [
  'com.microsoft.playready',
  'com.widevine.alpha',
]);

We would try the key systems in the specified order. If no such configuration is given, we still use the old behavior.

This raises the question of what the behavior should be if a key system not in the preference list has a license server configured. In those cases, I would suggest those key systems be tried in no particular order after the ones in the preferredKeySystems list.

What do y'all think?

[deisenbacher01]

Hello I believe the behavior should be the native, Edge on Windows should use PlayReady by default for the higher security level. David

…

On Mon, Dec 21, 2020 at 4:36 PM Joey Parrish ***@***.***> wrote: I'll tag this as a feature request and rename it accordingly. Here's my proposal for an API: player.configure({ drm: { preferredKeySystems: [ 'com.microsoft.playready', 'com.widevine.alpha', ], },}); Or: player.configure('drm.preferredKeySystems', [ 'com.microsoft.playready', 'com.widevine.alpha',]); This raises the question of what the behavior should be if a key system *not* in the preference list has a license server configured. In those cases, I would suggest those key systems be tried in no particular order after the ones in the preferredKeySystems list. What do y'all think? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3002 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDOMLG5JUDKFCJAO3KDDOTSV65VHANCNFSM4T7QDIGA> .

-- David Eisenbacher

[MilosRasic]

Hello I believe the behavior should be the native, Edge on Windows should use PlayReady by default for the higher security level. David

That would be a sane default, but I'd leave developers with the ability to change priority. There can be reason why someone might want to prefer one DRM system or another. For example, #2759 may be worked around by preferring Widevine in new Edge.

[deisenbacher01]

Hello I was referring to "what behavior should be if a key system not in the preference list has a license server configured" It should be PR on Edge. If a developer sets a DRM then that can override but only if it is set. thank you David

…

On Tue, Dec 22, 2020 at 9:10 AM Miloš Rašić ***@***.***> wrote: Hello I believe the behavior should be the native, Edge on Windows should use PlayReady by default for the higher security level. David That would be a sane default, but I'd leave developers with the ability to change priority. There can be reason why someone might want to prefer one DRM system or another. For example, #2759 may be worked around by preferring Widevine in new Edge. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- David Eisenbacher

[joeyparrish]

I don't think we are likely to hard-code a mapping of preferred key systems for multi-DRM-capable browsers. There are lots of things that affect a choice of key system, including the cost of license services (which may come from a third-party and not the DRM provider). We are not in a position to make those priority decisions for apps.

Also, we need to consider backward compatibility. If a streaming service using Shaka Player is already getting the results they expect, we should avoid changing the behavior in a way that would result in selecting a different key system after a Shaka Player upgrade.

We should make it clear in release notes and docs that this new setting is one that should be set by apps whenever possible, but I don't see how we could reasonably create defaults that wouldn't harm one app or another.

[avelad]

@joeyparrish / @michellezhuogg , I have seen that it is working in the master branch, shouldn't it be included in the 3.2 release? is it finished?

[joeyparrish]

Yes, this is complete.