Ignore key systems and init data in DASH manifest

[Canta]

• What version of Shaka Player are you using?
  v2.0.7-debug

  • Can you reproduce the issue with our latest release version?
    yes
  • Can you reproduce the issue with the latest code from master?
    yes

• Are you using the demo app or your own custom app?
  https://shaka-player-demo.appspot.com/demo/

• What browser and OS are you using?
  IE11 and Edge

Hi there.

We're having a problem with our VOD DRM setup and Shaka on IE11 or Edge.

You can test it in Shaka's demo (asset custom): https://shaka-player-demo.appspot.com/demo/
Here's a manifest for testing: https://d11gqohmu80ljn.cloudfront.net/637/384415_19d188634f44db3147cbab020fc3c19c/mpds/384415.mpd?cb=1473777901
And here's the playready license server: https://proxy-dev.tbxdrm.com/v1/drm-proxy/playready/tbxnet?contentId=aa07f498-c27d-4ae2-ad02-5c2518504cfa

Problem is:
The asset provides both Widevine and Playready data. But it happens that Widevine pssh data is placed inside the manifest, while Playready's inside the first chunk.
Shaka seems to avoid getting the Playready pssh data because it detects that Widevine's in the manifest, and then it assumes that both pssh are there, which is not the case.

Is there something we could do to force Shaka to check the first chunk when using Playready even when Widevine has its pssh inside the manifest?

Thanks in advance.

[joeyparrish]

Normally, the manifest either contains all necessary init data or none at all. So to make it work with Shaka Player as designed today, you can either:

1. Remove cenc:pssh from the manifest and rely on the PSSH boxes in the media (assuming the media itself contains PSSH boxes for both Widevine & PlayReady)
2. Add a cenc:pssh element for the PlayReady PSSH.

Are either of these options feasible for you?

[Canta]

Thank you very much joey for the quick answer.

Unfortunately, that's what our content provider gives to us; we have no control over the manifest creation.

Dashif player does not have this problem, but it fails with LIVE content (not VOD).
So, our workaround would be to use one player for VOD and the other for LIVE.

We would love to use Shaka for every use case.
Is it feasible to add in the future some configuration in Shaka for this use case?
Maybe some way to conditionally modify the manifest? (We could remove the widevine pssh data when playready is in use).

[joeyparrish]

Let's see what we could come up with to allow you to override this.

I could imagine a new option in the advanced drm configuration that would allow you to specify init data. This would override both manifest and media init data. If we implemented this solution, could you supply the PlayReady init data that is missing from the manifest?

I could also imagine a new option in the dash parser configuration that would ask the parser to ignore the init data from the manifest. For this to solve your problem, the media would have to contain both PlayReady and Widevine init data. Is this the case for your media?

[Canta]

Thing is, we have various providers, and just this one sends the assets proccesed this way. So, is not just a "if IE" or "if Playready", but a series of more complex checks before we could tell Shaka what to do.

That said, I think the second option would work.
As I understand it, the first option would require us to get the data, changing it, and injecting it into shaka. I guess it's technologically possible, but it would require us to implement the logic for detecting and getting the first chunk and then parsing that and converting it to a valid manifest tag, which in sum of the other checks would be really cumbersome.

Given that you're so willing to consider a change in Shaka in order to help us, i'm wondering what could be the problem with just changing the actual behaviour of not checking the first chunk for playready when widevine pssh data is in the manifest. Isn't it simpler? Or this means trouble for somebody?
Anyways, if you consider this to be a problem, then we could work with your second option.

Thanks.

[TheModMaker]

Looking at the manifest you gave, it says it is encrypted only with Widevine, not PlayReady. It contains two <ContentProtection> elements, one for generic MP4 and one for Widevine. If you added another with PlayReady that didn't have a <cenc:pssh> element, Shaka would support it fine.

From our side, we have no way of knowing that this content will work with PlayReady, since the manifest doesn't tell us. We would need to add a configuration option to add additional key systems.

[joeyparrish]

If the manifest doesn't indicate PlayReady support at all, we could offer an option to say "ignore the DRM info in the manifest completely", including key systems. This would treat any DASH manifest with <ContentProtection> as if it signaled no particular key systems and contained no init data.

[joeyparrish]

Sorry, I missed your question earlier:

i'm wondering what could be the problem with just changing the actual behaviour of not checking the first chunk for playready when widevine pssh data is in the manifest. Isn't it simpler? Or this means trouble for somebody?

DASH states that init data in the manifest overrides init data in the content. It's as simple as that. So if we have init data from the manifest, we don't listen for init data from the content. We can offer an option to disregard the manifest init data instead, but this would not be the default.

Does that make sense?

And as my colleague pointed out, the manifest specifies Widevine but not PlayReady, so that's another layer. When we see that information in the manifest, we believe it and we don't try PlayReady. We could optionally ignore this, as well.

For any of this to be effective, your media would have to include PSSH boxes for both Widevine and PlayReady. I examined one of the init segments from your manifest and found that in this case, it does contain both.

[Canta]

Sorry for the delay.

You are correct about the manifest, that was my mistake. And, yes, an option for disregarding manifest data would be very useful for us.

Thank you very much.

[joeyparrish]

I will update the title of the issue. I've marked this feature tentatively for v2.2, but we may be able to cherry-pick it to other branches once implemented.