Add support for ISO Common Encryption 'cbcs' Protection Scheme

[hober]

See the pull request https://github.com/w3c/encrypted-media/pull/392 for details.

[mwatson2]

Is your proposal that support of 'cbcs' be mandatory for EME compliance ? If not, don't we need some kind of capability discovery ?

[ddorwin]

Yes, if ISO BMFF protection schemes other than 'cenc' are to be supported/registered, we need some way to feature detect the protection scheme. As noted in https://github.com/w3c/encrypted-media/issues/149#issuecomment-189497503:

This group has decided that all encrypted "video/mp4" uses [ISO Common Encryption and the 'cenc'] protection scheme.

This issue is really independent of EME, and the solution for identifying such streams should be independent of EME as well.

Since different protection schemes are really incompatible file formats that happen to share a common structure, they should probably have a different MIME subtype (unless someone wants to push through an RFC for adding an encryption format parameter).

[dwsinger]

I am a little puzzled as to how the group can 'decide' something contra-factual; MP4 is a general purpose container and can support a wide variety of codecs and encryption schemes, alas.

If you want to know (a) that the file contains encrypted content and (b) what the scheme is and (c) what the underlying codec is, then one would do either 1) what DASH does; declare in the manifest what the codecs parameter is, as if it were unencrypted, and have a separate parameter that says "this content is encrypted using XXXX scheme" or 2) we have a proposal to define the sub-parameters of e.g. encv as the 4CC of the scheme, followed by the 4CC of the underlying format and its sub-parameters. Then the codecs string would read codecs="encv.cbcs.avc1.402567" (I made up the last bit).

Would #2 help?

[ddorwin]

I meant in the context of this spec, as defined in the registry. That is also how implementations and authors are using it with this spec. We can define other values or signals, but we can't change the meaning of just "video/mp4" without breaking compatibility.

Where is the proposal you mention in (2)?

[dwsinger]

The proposal #2 is on the table in the MPEG file format group. Comments/support/opposition would be welcome. Can the registry say that ";codecs=encv.cenc" may be assumed if the codecs parameter is not present? (Just floating an idea here)

[ddorwin]

I moved discussion of the proposal in (2) to #400.

[jernoble]

Please note that Google has shipped the following change to the EME specification in Chrome 69: https://github.com/WICG/encrypted-media-encryption-scheme/blob/master/explainer.md

[xhwang-chromium]

To clarify, it has been implemented in Chromium and available behind a flag (but NOT enabled by default) since Chromium 69. The official blog post is at https://developers.google.com/web/updates/2018/08/chrome-69-media-updates#encryption_scheme

For completeness, the proposal is at https://github.com/WICG/encrypted-media-encryption-scheme/blob/master/explainer.md

Recently the TAG review has been requested at https://github.com/w3ctag/design-reviews/issues/322