Conditional support of encryption mode

[johnsim]

@joeyparrish has begun to address this issue here: https://github.com/WICG/encrypted-media-encryption-scheme/blob/master/explainer.md. There are four modes of common encryption, ‘cbcs’, ‘cbc1’, ‘cenc’ and ‘cens’. A UA may support ‘cbcs’ but not ‘cenc’ – but it is also true it might only support ‘cbcs’ applied to a particular media profile/codec – so it is the combination of encryption mode and media type that needs to be asked about – the same problem as with Supplemental Data.

[chcunningham]

Sounds good to me. I'm adding a "keySystemConfiguration" to MediaCapabilities in PR #101. Will do similar for encryption mode. @joeyparrish is this something your implementing in rMKSA for Chrome?

[scottlow]

@chcunningham It doesn't appear that this ever landed. Is this still on your todo list? Happy to help here if needed!

[chcunningham]

@scottlow, this is still on my list. Its easy to implement, but I recently realized the dictionary current shape doesn't support it well (cc: @mounirlamouri).

In EME, MediaKeySystemEncryptionScheme is added to the MediaKeySystemMediaCapabilitiy alongside robustness and contentType.

dictionary MediaKeySystemMediaCapability {
DOMString contentType = "";
DOMString robustness = "";
MediaKeyEncryptionScheme? encryptionScheme = null;
};

In MC, we already had audio and video contentType described in the Audio|VideoDecodingConfiguration dictionary, so we opted to just add the robustness string from the EME dict to our MediaCapabilitiesKeySystemConfiguration as audio|videoRobustness. Now that the EME dict also includes encryptionScheme I want to reconsider the pattern of audio|video* prefixed attributes ... its ugly.

Here's a strawman that moves in the direction of bucketing audio and video things more logically. Thoughts?

dictionary MediaCapabilitiesKeySystemConfiguration {
required DOMString keySystem;
DOMString initDataType = "";
TrackKeySystemConfiguration audioKeySystemConfig;
TrackKeySystemConfiguration videoKeySystemConfig;
MediaKeysRequirement distinctiveIdentifier = "optional";
MediaKeysRequirement persistentState = "optional";
sequence sessionTypes;
};

dictionary TrackKeySystemConfiguration {
// Open to making this default to something else if empty is really troublesome.
DOMString robustness = "";
EncryptionScheme? encryptionScheme = null;
};

[scottlow]

Agreed with wanting to move away from audio/video prefixes as the EME dict grows. This seems like a sound change to me! @mounirlamouri, do you have any other thoughts here?

[mounirlamouri]

I don't have a strong opinion between prefixing and creating a new dictionary but maybe if we create a dictionary, it could be audio and video. No need to add KeySystemConfig prefix.

It would look like:

{
  type: 'media-source',
  audio: {
    [...]
  },
  video: {
    [...]
  },
  keySystemConfiguration: {
    audio: {
      robustness: ...,
      encryptionScheme: ...,
    },
    video: {
      robustness: ...,
      encryptionScheme: ...,
    }
  }
}

[chcunningham]

Thats fine with me. I'll send a PR shortly.

[chcunningham]

"Shortly"... sorry about the wait. I started coding this up and discovered the reason Chrome hasn't shipped the current proposal (from the explainer) is due to some ergonomics concerns. I'm working to get those published and sorted out. Expect another update by EOW.

[chcunningham]

Ok, so the issues are published (were already actually) here https://github.com/WICG/encrypted-media-encryption-scheme/issues (those filed by David are what we're spinning on internally).

One of those has a PR already
WICG/encrypted-media-encryption-scheme#12

Some of the others have a harder path forward. I'm told Joey will try to squeeze some time in for this next week.

[joeyparrish]

It looks like encryptionScheme would be added to KeySystemTrackConfiguration. Is that accurate?

[mounirlamouri]

That's correct :)

[joeyparrish]

The PR for EME encryptionScheme just landed today:

w3c/encrypted-media#457
https://w3c.github.io/encrypted-media/