This seems very use case- and platform-specific. How about something more generic that addresses multiple use cases, including knowing ahead of time which streams can be played (instead of trying the stream and waiting for an error event).

I propose:
* Add a simple event named something to the effect of “usablekeyschange”.
* Add an attribute to MediaKeySession: usableKeyIds.
  - readonly attribute Array<Uint8Array> usableKeyIds; // An array of usable key IDs, which are Uint8Arrays.
* Whenever the set of usable keys in a session changes - whether through a new license, license expiration, output changes, etc. - the CDM will update the usableKeyIds attribute and fire the “usablekeyschange” event.
* When an application receives the “usablekeyschange” event (or at any other time), it checks the usableKeyIds attribute for the usable key IDs.
  - The application should probably stop fetching and providing content requiring any missing key IDs or request a new license.

Content using key IDs not listed in usableKeyIds does not necessarily fail (this would be indicated by an error event), but the application should stop providing such content.

In addition to some of the more obvious use cases, this also addresses some of the use cases associated with the “ready” event (without the ambiguity that led it to be removed).

It could also address things like license expiration (currently a proposed error). The only issue is that there is no indication of why a key ID is not usable. (We might be able to add this later if implementation experience shows that it is really necessary. Or, we can also fire an “error” event.)

I like the proposal very much (as it relates to bug 25218), but I am not clear how this would solve the problem described. 

In Mark's description, the correct KID is available for decrypting and thus would fall into the usableKeyIds array. It is just that the content is being downscaled after decryption due to some platform deficiency. 

Can you explain how you would use the facility you are describing to handle this use case?

I was thinking instead that we could throw an error but have it be non-fatal.

Maybe "usable" isn't the best name. I was trying to provide consistent and expected behavior for the application regardless of the underlying implementation.

In Mark's use case, the application wants to avoid using a stream that is being downscaled on a particular system. On other systems, the stream may not play at all. In both cases, my proposal would tell the application it should start fetching another stream. In the latter case, an error event and waiting event might also be fired.

The proposal also allows the application to know whether the stream can be played ahead of time, allowing either case - especially the error and potential playback delay - to be avoided.

Ah I see -- so you are saying the CDM would remove the KID from the usableKeyIds array and fire the event, but the keyID would actually still be alive and decrypting content. How long would the list of usableKeyIds and the actual set of usable keys be out of sync?

(In reply to Joe Steele from comment #4)
> Ah I see -- so you are saying the CDM would remove the KID from the
> usableKeyIds array and fire the event, but the keyID would actually still be
> alive and decrypting content.
Yes.

> How long would the list of usableKeyIds and
> the actual set of usable keys be out of sync?

In the downscaling case, indefinitely I guess.

Maybe something like satisfiedKeyIds would be better.

In my usecase, the streams could all have the same key. So informing the application that a given key id cannot be used (without restrictions) won't give the application sufficient information to take meaningful action.

Resolution seems to be the single most important property of a stream that can cause it to be handled in special ways by DRM systems (based on combining resolution with things that are not stream properties like license policy and output characteristics such as HDCP).

A generic solution would be great (this is why I posted this as a use-case without  detailed solution proposal). 

One direction to generalize would be to think in terms of stream properties which are causing failure or non-optimal handling of the stream. However, I think resolution is presently the only such property and there are good reasons (avoiding complexity) to resist extending such behaviors to other stream properties.

(In reply to Mark Watson from comment #6)
> In my usecase, the streams could all have the same key. So informing the
> application that a given key id cannot be used (without restrictions) won't
> give the application sufficient information to take meaningful action.

This issue was raised during the April 1 telecon. The proposal is to use a fake key ID as a proxy for the policies you wish to check.

(In reply to David Dorwin from comment #7)
> (In reply to Mark Watson from comment #6)
> > In my usecase, the streams could all have the same key. So informing the
> > application that a given key id cannot be used (without restrictions) won't
> > give the application sufficient information to take meaningful action.
> 
> This issue was raised during the April 1 telecon. The proposal is to use a
> fake key ID as a proxy for the policies you wish to check.

That's and additional and unnecessary requirement on the DRM - to support and track multiple Key Ids. Presently there are DRM systems which do not support multiple keys or key ids for the same session.

Alternatively, this whole question could be thought of one that applies more generally to MSE rather than just EME. There may be reasons other than DRM restrictions where the resolution / color depth / frame rate etc. of the output is restricted (particularly, physical device capabilities) and the application may be interested in knowing that it could optimize by switching to a different stream without impacting the quality presented to the end-user.

(In reply to Mark Watson from comment #8)
> (In reply to David Dorwin from comment #7)
> > (In reply to Mark Watson from comment #6)
> > > In my usecase, the streams could all have the same key. So informing the
> > > application that a given key id cannot be used (without restrictions) won't
> > > give the application sufficient information to take meaningful action.
> > 
> > This issue was raised during the April 1 telecon. The proposal is to use a
> > fake key ID as a proxy for the policies you wish to check.
> 
> That's and additional and unnecessary requirement on the DRM - to support
> and track multiple Key Ids. Presently there are DRM systems which do not
> support multiple keys or key ids for the same session.

That's unfortunate. That's going to break interop for a lot of other use cases too, so I'd rather focus on fixing that. In the meantime, maybe two sessions can be used in that case or the CDMs around those DRMs can handle the second key ID.

There are also DRM systems that don't support downscaling - something that is much more complex than supporting multiple key IDs.

We're going to have to fix CDM limitations or make compromises (i.e. not the perfect API) somewhere to achieve interop.

> Alternatively, this whole question could be thought of one that applies more
> generally to MSE rather than just EME. There may be reasons other than DRM
> restrictions where the resolution / color depth / frame rate etc. of the
> output is restricted (particularly, physical device capabilities) and the
> application may be interested in knowing that it could optimize by switching
> to a different stream without impacting the quality presented to the
> end-user.

That might make sense along with other TBD feature detection capabilities or on MSE's getVideoPlaybackQuality(). However, even if the results of CDM policies were exposed this way, the application would have to play the content (and possibly fail) to find out the results. My proposal allows the application to get an answer before a potentially un-playable frame is processed.

I moved my proposal from comment #1 to bug 25409 since it addresses multiple scenarios, including the subject of that bug. It could still be the solution for this use case as well.

(In reply to David Dorwin from comment #10)
> I moved my proposal from comment #1 to bug 25409 since it addresses multiple
> scenarios, including the subject of that bug. It could still be the solution
> for this use case as well.

I think the proposal of bug 25409 is a good one, but I don't think it adequately addresses this use-case.

Requiring content that might be subject to restrictions such as downscaling to have a different key id, even a 'fake' one, is arbitrary and introduces a new system requirement (multiple key ids embedded in content) to address a limitation of a single platform (HTML).

In general we should be able to play any and all content that is compatible with the byte-stream specification, including CENC for the ISO BMFF case. We should not introduce additional requirements on the byte-stream unless absolutely necessary.

I'd be interested, though, in whether this is in fact an MSE requirement ? There could be other reasons why the UA might want to hint to the application that it should switch to a lower-resolution stream.

(In reply to Mark Watson from comment #11)
...
> Requiring content that might be subject to restrictions such as downscaling
> to have a different key id, even a 'fake' one, is arbitrary and introduces a
> new system requirement (multiple key ids embedded in content) to address a
> limitation of a single platform (HTML).
> 
> In general we should be able to play any and all content that is compatible
> with the byte-stream specification, including CENC for the ISO BMFF case. We
> should not introduce additional requirements on the byte-stream unless
> absolutely necessary.

To clarify, the fake key ID does not need to be in the media resource ("content" and "byte-stream" above). It would only need to be in a session. Since it is fake, the same fake key ID could always be provided for all content.

(In reply to David Dorwin from comment #12)
> (In reply to Mark Watson from comment #11)
> ...
> > Requiring content that might be subject to restrictions such as downscaling
> > to have a different key id, even a 'fake' one, is arbitrary and introduces a
> > new system requirement (multiple key ids embedded in content) to address a
> > limitation of a single platform (HTML).
> > 
> > In general we should be able to play any and all content that is compatible
> > with the byte-stream specification, including CENC for the ISO BMFF case. We
> > should not introduce additional requirements on the byte-stream unless
> > absolutely necessary.
> 
> To clarify, the fake key ID does not need to be in the media resource
> ("content" and "byte-stream" above). It would only need to be in a session.
> Since it is fake, the same fake key ID could always be provided for all
> content.

Ok, then I am not sure how the 'fake key ID' idea is supposed to work. Assuming there is no impact on the content, then if every bitrate indicates the same key id in the CENC structures (PSSH, TENC) where does the 'fake' id appear and how does the CDM know that this id is a synonym for the one in the media files ?

(In reply to Mark Watson from comment #13)
> (In reply to David Dorwin from comment #12)
> > (In reply to Mark Watson from comment #11)
> > ...
> > > Requiring content that might be subject to restrictions such as downscaling
> > > to have a different key id, even a 'fake' one, is arbitrary and introduces a
> > > new system requirement (multiple key ids embedded in content) to address a
> > > limitation of a single platform (HTML).
> > > 
> > > In general we should be able to play any and all content that is compatible
> > > with the byte-stream specification, including CENC for the ISO BMFF case. We
> > > should not introduce additional requirements on the byte-stream unless
> > > absolutely necessary.
> > 
> > To clarify, the fake key ID does not need to be in the media resource
> > ("content" and "byte-stream" above). It would only need to be in a session.
> > Since it is fake, the same fake key ID could always be provided for all
> > content.
> 
> Ok, then I am not sure how the 'fake key ID' idea is supposed to work.
> Assuming there is no impact on the content, then if every bitrate indicates
> the same key id in the CENC structures (PSSH, TENC) where does the 'fake' id
> appear and how does the CDM know that this id is a synonym for the one in
> the media files ?

Since the proposal in bug 25409 does not rely on media data, the fake key ID does not need to be a synonym for any of the streams. It is simply a proxy for a set of policies the license server has associated with that key ID. The application must know the implications of that key ID being usable or not, just as it would need to know the meaning of the originally proposed event.

(In reply to David Dorwin from comment #14)
> (In reply to Mark Watson from comment #13)
> > (In reply to David Dorwin from comment #12)
> > > (In reply to Mark Watson from comment #11)
> > > ...
> > > > Requiring content that might be subject to restrictions such as downscaling
> > > > to have a different key id, even a 'fake' one, is arbitrary and introduces a
> > > > new system requirement (multiple key ids embedded in content) to address a
> > > > limitation of a single platform (HTML).
> > > > 
> > > > In general we should be able to play any and all content that is compatible
> > > > with the byte-stream specification, including CENC for the ISO BMFF case. We
> > > > should not introduce additional requirements on the byte-stream unless
> > > > absolutely necessary.
> > > 
> > > To clarify, the fake key ID does not need to be in the media resource
> > > ("content" and "byte-stream" above). It would only need to be in a session.
> > > Since it is fake, the same fake key ID could always be provided for all
> > > content.
> > 
> > Ok, then I am not sure how the 'fake key ID' idea is supposed to work.
> > Assuming there is no impact on the content, then if every bitrate indicates
> > the same key id in the CENC structures (PSSH, TENC) where does the 'fake' id
> > appear and how does the CDM know that this id is a synonym for the one in
> > the media files ?
> 
> Since the proposal in bug 25409 does not rely on media data, the fake key ID
> does not need to be a synonym for any of the streams. It is simply a proxy
> for a set of policies the license server has associated with that key ID.
> The application must know the implications of that key ID being usable or
> not, just as it would need to know the meaning of the originally proposed
> event.

Ok, let me check I understand how this would work:

The license would contain the key and its true key ID, matching the key ID in the content files. The license would also contain policy for resolution restrictions and one or more 'fake' key IDs corresponding to different resolution levels. The client side of the app knows these fake Key IDs correspond to resolution levels.

The new API would expose the key IDs, both the fake ones and the real one (or possibly just the fake ones ?). The CDM would signal changes in resolution restrictions as changes in the usable key IDs.

Did I get this right ?

Seems like a real kludge where the key IDs are being abused to represent different policies that may or may not be applied. The fake Key Id is really a 'policy identifier' and the 'usablekeyschange' is being abused to indicate a policy change.

(In reply to Mark Watson from comment #15)
> Ok, let me check I understand how this would work:
> 
> The license would contain the key and its true key ID, matching the key ID
> in the content files. The license would also contain policy for resolution
> restrictions and one or more 'fake' key IDs corresponding to different
> resolution levels. The client side of the app knows these fake Key IDs
> correspond to resolution levels.

They really correspond to policies, which the application may further map to resolution levels.

> The new API would expose the key IDs, both the fake ones and the real one
> (or possibly just the fake ones ?).

All key IDs would be exposed - the CDM doesn't know about fake key IDs. In the downscaling case, the real key ID would always be "usable".

> The CDM would signal changes in
> resolution restrictions as changes in the usable key IDs.

Yes, The CDM would indicate whether the whether all of the reasons to restrict resolution are false (fake key ID is listed as usable) or not (fake key ID not listed as usable)

> Did I get this right ?
> 
> Seems like a real kludge where the key IDs are being abused to represent
> different policies that may or may not be applied. The fake Key Id is really
> a 'policy identifier' and the 'usablekeyschange' is being abused to indicate
> a policy change.

In the single key ID case, it is. This is really a case of using a general purpose API (bug 25409) for a specific use case.

EME relies on and exposes a few basic concepts, including sessions and key IDs. It doesn't expose policies, robustness, resolutions, etc. Even if we wanted to expose those, it would be difficult to get consistent definitions/behavior. A fake key ID seemed like the best way to use the existing common primitives to address this specific use case.

(In reply to David Dorwin from comment #16)
> (In reply to Mark Watson from comment #15)
> > Ok, let me check I understand how this would work:
> > 
> > The license would contain the key and its true key ID, matching the key ID
> > in the content files. The license would also contain policy for resolution
> > restrictions and one or more 'fake' key IDs corresponding to different
> > resolution levels. The client side of the app knows these fake Key IDs
> > correspond to resolution levels.
> 
> They really correspond to policies, which the application may further map to
> resolution levels.
> 
> > The new API would expose the key IDs, both the fake ones and the real one
> > (or possibly just the fake ones ?).
> 
> All key IDs would be exposed - the CDM doesn't know about fake key IDs. In
> the downscaling case, the real key ID would always be "usable".

The CDM would need some way to associate the right fake IDs with the right files. Since we do not have the fake IDs embedded in the files, this can only be through the CDM understanding indications in the license that say 'this key ID is for files with resolution < X' together with the resolution indications in the file.

> 
> > The CDM would signal changes in
> > resolution restrictions as changes in the usable key IDs.
> 
> Yes, The CDM would indicate whether the whether all of the reasons to
> restrict resolution are false (fake key ID is listed as usable) or not (fake
> key ID not listed as usable)

It's not necessary boolean. Sometimes you may be restricted to SD and sometimes to HD.

> 
> > Did I get this right ?
> > 
> > Seems like a real kludge where the key IDs are being abused to represent
> > different policies that may or may not be applied. The fake Key Id is really
> > a 'policy identifier' and the 'usablekeyschange' is being abused to indicate
> > a policy change.
> 
> In the single key ID case, it is. This is really a case of using a general
> purpose API (bug 25409) for a specific use case.

Seems like you are assuming a particular 'ideal' approach in which each stream has a separate Key Id and then working backwards to say that if that is not the case the CDM and application need to 'fake out' that ideal approach.

But it is very awkward, which suggests to me that this general mechanism, whilst potentially useful for other things, isn't right for this usecase.

> 
> EME relies on and exposes a few basic concepts, including sessions and key
> IDs. It doesn't expose policies, robustness, resolutions, etc. Even if we
> wanted to expose those, it would be difficult to get consistent
> definitions/behavior. A fake key ID seemed like the best way to use the
> existing common primitives to address this specific use case.

Applying restrictions is one of the things DRMs commonly do and restrictions based on stream properties is a common class of restrictions. I think more promising would be to look at general ways of specifying stream properties that might be restricted (media queries ?) and also looking at whether there are non-DRM reasons that restrictions might be applied (output capabilities?). Again, this could fit better into MSE if there are non-DRM reasons for such restrictions.

A few clarifications inline.

(In reply to Mark Watson from comment #17)
> The CDM would need some way to associate the right fake IDs with the right
> files. Since we do not have the fake IDs embedded in the files, this can
> only be through the CDM understanding indications in the license that say
> 'this key ID is for files with resolution < X' together with the resolution
> indications in the file.

The CDM doesn't care about files. It only cares about whether the policies associated with the key IDs can be met. It is up the the application/license server to communicate what those policies mean.

The CDM just says, "I would [not] play content that uses this key ID." IIUC, the resolution restriction is applied because the policy for higher resolutions cannot be met. Resolution limitations are a symptom of something else.

> It's not necessary boolean. Sometimes you may be restricted to SD and
> sometimes to HD.

The application and license server will have this information. The application is going to need this information anyway to select an appropriate stream (unless you assume that the CDM is going to tell you "please only give me content that has a resolution of <= M x N"). The CDM just tells you whether a policy can be met. If you want, you can get fancy with any number of policies and key IDs.

(In reply to David Dorwin from comment #18)
> A few clarifications inline.
> 
> (In reply to Mark Watson from comment #17)
> > The CDM would need some way to associate the right fake IDs with the right
> > files. Since we do not have the fake IDs embedded in the files, this can
> > only be through the CDM understanding indications in the license that say
> > 'this key ID is for files with resolution < X' together with the resolution
> > indications in the file.
> 
> The CDM doesn't care about files. It only cares about whether the policies
> associated with the key IDs can be met. It is up the the application/license
> server to communicate what those policies mean.
> 
> The CDM just says, "I would [not] play content that uses this key ID." IIUC,
> the resolution restriction is applied because the policy for higher
> resolutions cannot be met. Resolution limitations are a symptom of something
> else.

This is what I mean by abusing key ids to represent policies. Those seem such different things that it makes no sense to use one to represent the other.

> 
> > It's not necessary boolean. Sometimes you may be restricted to SD and
> > sometimes to HD.
> 
> The application and license server will have this information. The
> application is going to need this information anyway to select an
> appropriate stream (unless you assume that the CDM is going to tell you
> "please only give me content that has a resolution of <= M x N"). The CDM
> just tells you whether a policy can be met. If you want, you can get fancy
> with any number of policies and key IDs.

I was wondering if there was a way to use media queries to discover the output capabilities and be notified of changes in those, whether DRM related or not.

This solution seems overly complex to me. This would require a license server change to support a purely client side interaction. 

"Outputs changed" seems like a good general event to me, e.g. downscaling, Miracast'ing, HDCP enabled, etc. I can definitely see the application wanting to have this information. Do we need to define explicitly what the event looks like? Or can we have a high-level event with a context-specific modifier (or set of modifiers) like "downscaling"?

If there is not an explicit path for this, it would be far easier to abuse the keyrequest/update() mechanism to report this kind of information.

The goal is to avoid wasting bandwidth, CPU, battery, etc. when the client is unable to display the full resolution of the stream it is being provided. In this specific case, this is due to policy restrictions.

Maybe there is a more general performance/bandwidth optimization issue that should be solved in a general (non-EME-specific) way. For example, the HTMLMediaElement or MediaSource object could have a way to optionally provide guidance on max (and min) resolution during playback.

Such a feature might be used where high resolutions may not make sense, such as on certain devices, while on a cell network, or while on battery (especially when doing software decoding and/or the battery is low). Applications can detect or imply some of these conditions (i.e. screen size, ISP) but not all of them.

Here is the end of the mail thread on www-style:

http://lists.w3.org/Archives/Public/www-style/2013Mar/0717.html

Seems this ended not with dis-interest but with a rejection of the entire MSE model where the JS is in charge of bitrate selection.

I reposted the question to the www-style list on the basis that, since the last discussion, the industry has chosen the MSE approach in preference to the approach advocated on www-style 18 months ago: http://lists.w3.org/Archives/Public/www-style/2014Sep/0205.html

Discussion on www-style concluded [1] that media queries was not the right way to handle the resolution restrictions arising from downscaling.

There already exist tools which can be used to determine physical display resolution and thus influence bitrate choice on that basis.

For the dynamic, content-related, case of HDPC-driven downscaling, we should define something EME-specific.

My original suggestion was to define an event specifically for this case of resolution restrictions. There are two subcases depending on whether downscaling is supported:
(a) resolution restricted and downscaling supported (playback continues)
(b) resolution restricted and downscaling not supported (playback stops)

We also have the alternative of requiring that different policies be associated with different key ids (fake ones if necessary) and indicating the status with respect to each policy through the usable key ids mechanism. Thus, there would be a key id associated with the policy that 'requires HDCP x.y for resolution z'. That key id would be marked as unusable to indicate that resolution z cannot be supported. Whether there is downscaling or the playback is stopped might be indicated by a key status or just by the fact of whether playback is continuing or not.

This alternative could work, but it seems rather complex and the fake key ids seem awkward. I also do not like the application responsibility for the linkage between fake key id and policy: it does not seem that this could be done in a keysystem-independent way (some keysystems may support applications specifying the 'fake key id <-> policy' correspondance at the server side, but others might have it hard-coded into the CDM). To address this - since resolution restriction is IIUC the only example of a restriction leading to a desire to switch streams - I wonder if we should expose the resolution restriction explicitly with the key status ?



[1] http://lists.w3.org/Archives/Public/www-style/2014Nov/0373.html

It seems that downscaling and "output-not-allowed" are alternative implementations for handling a key whose output requirements cannot be met. Applications should behave the same in both cases - do not fetch content that requires such a key. In the former, this wastes bandwidth and client resources. In the latter, playback will stop. In theory, we wouldn't even need to differentiate them because the "waiting for a key" logic would indicate a not-allowed key was used.

If there is a preference for differentiating the two cases, I propose adding the following to MediaKeyStatus:
"downscaled" - The key is not currently usable to decrypt media data at full quality (e.g. resolution) because its output requirements cannot currently be met. Media data decrypted with this key may be presented at a lower quality (in resolution or other factors).

We can then add a non-normative note that applications should avoid using media data that uses keys whose status is "output-not-allowed" or "downscaled".

(In reply to David Dorwin from comment #25)
> It seems that downscaling and "output-not-allowed" are alternative
> implementations for handling a key whose output requirements cannot be met.
> Applications should behave the same in both cases - do not fetch content
> that requires such a key. In the former, this wastes bandwidth and client
> resources. In the latter, playback will stop. In theory, we wouldn't even
> need to differentiate them because the "waiting for a key" logic would
> indicate a not-allowed key was used.
> 
> If there is a preference for differentiating the two cases, I propose adding
> the following to MediaKeyStatus:
> "downscaled" - The key is not currently usable to decrypt media data at full
> quality (e.g. resolution) because its output requirements cannot currently
> be met. Media data decrypted with this key may be presented at a lower
> quality (in resolution or other factors).
> 
> We can then add a non-normative note that applications should avoid using
> media data that uses keys whose status is "output-not-allowed" or
> "downscaled".

I am reaching out internally for more context here, but my gut feeling is that we would want to differentiate. 

My thinking is that we will have applications that work in environments that do not support downscaling. In that case the "downscaled" status would tell the app to get a lower res stream, while the "output-not-allowed" status would tell the app to display an error message, possibly indicating to the user how they can correct the problem.

We need to differentiate. In the downscaling case, the app will switch to downloading a lower quality stream but will probably play out all the content it has already downloaded. In the not-allowed case, there's no option to play out the already downloaded content.

As noted above, though, I still feel this mechanism for indicating restrictions is a hack, since there is an assumed architecture behind it that distinct policies require distinct key ids. In practice we have a single key / key id and the downscaling policy is triggered by a property of the content (its resolution).

So, this solution forces us to associate multiple key ids with the same key in order to express the distinct policies. Worse, the association of policy to key ids is done in a completely undefined way (which will thus probably differ between CDMs).

It would be cleaner, now that the CSS discussion has concluded this is not a subset of a more generic requirement, to simply have explicit output protection events.

Another approach would be to make the key status more detailed: so that the downscaling / non-allowed status would specify the maximum resolution not subject to that policy. This would also avoid the awkward additional key ids.

The suggestion of imposing more semantics on key ids and the opposition to having a downscaling notifications seems weird to me. We have an author representative (Mark) and an implementor representative (Joe) asking for this. Per http://www.w3.org/TR/html-design-principles/#priority-of-constituencies their concerns should trump specifier convenience and theoretical purity.

I see agreement that we should differentiate. I also agree with Joe's (comment 26) and the Mark's (first paragraph of comment #27) description of usage.
At a minimum, that means adding "[output-]downscaled" to MediaKeyStatus as I proposed in comment 25. This is consistent with how we decided to support output protection (HDCP) errors.


Mark's objection to a MediaKeyStatus value seems to be that they have policies that differ by resolution rather than key ID. I would expect this to be rare in practice. The current solution supports both mechanisms.

Key IDs are a first-class and normative concept in EME. Policies, output protection, and resolution are not. If we expose resolution information, it's logical to want to expose HDCP versions and other policy details.

The current solution is based on an existing first-class concept and provides a clear and simple mechanism for applications to get the information that only the CDM has. For example, "The output protection policy for key ID X cannot be met. Therefore, the CDM will {block playback | downscale video} if media data with that key ID is encountered." Given this information, the application knows it should avoid/stop fetching streams that use key ID X. In the former case, the application may need to fetch a new stream for the current playback location.

Applications can then build complex logic upon this basic functionality, using different key IDs if necessary. If necessary, the application can obtain additional information, such as associated policies or a mapping of key ID to stream (some type of mapping of policy to stream is necessary in any solution), from the server.

By contrast, an event or other more specific mechanism would likely be complex and/or be restricted in the scenarios it can support. For example, it would need to support reporting multiple resolutions with different behaviors (blocked and downscaled), report which policies/keys are affected, and report this information without having played the content (see below). This would also add interoperability risk because client implementations would need to expose all this data, which may not be consistently available or implemented in various CDM implementations.

The current simple mechanism minimizes the API surface and allows authors to build complex applications with whatever policy combinations they wish.


(In reply to Mark Watson from comment #27)
> So, this solution forces us to associate multiple key ids with the same key
> in order to express the distinct policies.
How much of a burden is this the extra key ID? I don't think there is actually any association - you would always use the same key ID for the "high resolution" policy.

> Worse, the association of policy
> to key ids is done in a completely undefined way (which will thus probably
> differ between CDMs).
How is it undefined? As with "real" key IDs, the application and its server set policies for the key and the CDM reports whether they are enforcable.
> 
> It would be cleaner, now that the CSS discussion has concluded this is not a
> subset of a more generic requirement, to simply have explicit output
> protection events.
One important goal of the current solution was to allow the status to be exposed without trying (and potentially failing) to play content. Thus, adding an event that is fired when content is downscaled or cannot be output is insufficient.
While  a downscaling event may work for your single-key use case, it seems it would either not be extensible to more complex cases or require a lot more complexity to support them.

Ok, let's agree on "downscaling" as a new key status.

Nevertheless, pls see comments below. In summary, we can't require that the policy associated with a key id is independent of content properties. It's already very common to have policies that are content property dependent. So, key status can change as content properties change.

This means that you can't learn that content will be downscaled until you feed some content in, but we can live with that for the moment (I believe there are other reasons why that is the case anyway).

If, instead, we wanted the key status to be content-independent, we'd need the status to be a map of resolution -> status.

(In reply to David Dorwin from comment #29)
> 
> Mark's objection to a MediaKeyStatus value seems to be that they have
> policies that differ by resolution rather than key ID. I would expect this
> to be rare in practice. The current solution supports both mechanisms.
> 

I don't think this will be rare. It will be common to have a single key / key ID with a policy that says, for example, that different HDCP versions are needed for different resolutions.

However, I agree that the "downscaling" / "not allowed" key statuses can work for this use-case: the application will need to know what the resolution constraints are and work downwards in resolution until a working stream is found. 

> Key IDs are a first-class and normative concept in EME. Policies, output
> protection, and resolution are not. If we expose resolution information,
> it's logical to want to expose HDCP versions and other policy details.

I'm not sure that follows: I'm interested in having the relationship between resolution and key status exposed, to avoid the trial-and-error. That doesn't mean the full mechanics of that relationship are needed (e.g.HDCP details), only that I can see which resolution maps to which status at the current time. But in advance of UHD there is only one other resolution to try, so I'm happy to punt on this for now.

> 
> The current solution is based on an existing first-class concept and
> provides a clear and simple mechanism for applications to get the
> information that only the CDM has. For example, "The output protection
> policy for key ID X cannot be met. Therefore, the CDM will {block playback |
> downscale video} if media data with that key ID is encountered." Given this
> information, the application knows it should avoid/stop fetching streams
> that use key ID X. In the former case, the application may need to fetch a
> new stream for the current playback location.

I don't think we can assume that a single Key ID has a simple met / unmet policy, independent of content properties like resolution. The status must indicate the action being taken for the media data available at the present time (for that key ID) and may change if the properties of the media change.


> 
> (In reply to Mark Watson from comment #27)
> > So, this solution forces us to associate multiple key ids with the same key
> > in order to express the distinct policies.
> How much of a burden is this the extra key ID? I don't think there is
> actually any association - you would always use the same key ID for the
> "high resolution" policy.
> 
> > Worse, the association of policy
> > to key ids is done in a completely undefined way (which will thus probably
> > differ between CDMs).
> How is it undefined? As with "real" key IDs, the application and its server
> set policies for the key and the CDM reports whether they are enforceable.

If you are using separate keys with separate policies and the policies are all content-independent and the CDM supports such multiple keys in one session, then everything is fine.

But there are CDMs that support only a single key or only a single key at a time. And there are CDMs that support content-dependent policies. These CDMs would probably need modification to expose multiple key ids associated with the same actual key, corresponding to splitting up the policy by content property such as resolution. How that is done - what those extra key ids would be etc. is undefined (CDM-specific).

We need first-class support for the case of policies that are dependent on content properties, since this is going to be common. The proposed key status values do provide this, albeit in a limited form.

> > 
> > It would be cleaner, now that the CSS discussion has concluded this is not a
> > subset of a more generic requirement, to simply have explicit output
> > protection events.
> One important goal of the current solution was to allow the status to be
> exposed without trying (and potentially failing) to play content.

That's a good goal, but it is not supported by the proposed key status values, since there is no way to expose the content-dependent aspects of the policy for a single key id.

> Thus,
> adding an event that is fired when content is downscaled or cannot be output
> is insufficient.
> While  a downscaling event may work for your single-key use case, it seems
> it would either not be extensible to more complex cases or require a lot
> more complexity to support them.

In the telecon today, we agreed to add a "output-downscaled" value to MediaKeyStatus.
Minutes: http://www.w3.org/2015/01/20-html-media-minutes.html#item10

There are some interoperability issues raised in comment 30. I will file separate issues in GitHub.

https://github.com/w3c/encrypted-media/commit/61450e0c5279772451360733b23161aa92ecb63e adds "output-downscaled" to MediaKeyStatus.

(In reply to Mark Watson from comment #30)
> Ok, let's agree on "downscaling" as a new key status.
> 
> Nevertheless, pls see comments below. In summary, we can't require that the
> policy associated with a key id is independent of content properties. It's
> already very common to have policies that are content property dependent.
> So, key status can change as content properties change.

The key status should not change based on the content. The key status indicates the status of the key based on the license and environment (i.e. HDCP or time).

For example:
* A key that does not require HDCP is always valid (assuming it has not expired, etc.).
* A key that requires HDCP is valid if HDCP is enabled and either output-downscaled or output-not-allowed (depending on the client implementation) otherwise.

In the case where a single content key is used for all streams, the first key (the real one) would always report valid, and the second (fake) key would report whether the output protection policies for higher resolutions can be met.
> 
> This means that you can't learn that content will be downscaled until you
> feed some content in, but we can live with that for the moment (I believe
> there are other reasons why that is the case anyway).

The above design enables you to determine whether content will be downscaled without feeding it in. This was an important part of the design as it allows applications to determine which streams to download without having to have already downloaded streams that will trigger an output protection status update/event/error. This was the subject of Bug 25409 ("Allow applications to detect whether a key is usable before using it to decrypt content"), which led to keyStatuses (via usableKeyIds).

The intended behavior could probably be better explained in the spec. I filed https://github.com/w3c/encrypted-media/issues/22. Suggestions welcome.
> 
> If, instead, we wanted the key status to be content-independent, we'd need
> the status to be a map of resolution -> status.

I don't see why. The application just needs to map key IDs to streams. (Resolution is actually irrelevant unless it's used to select streams, but that is an implementation detail of the application.)
> 
> (In reply to David Dorwin from comment #29)

> > (In reply to Mark Watson from comment #27)
> > > So, this solution forces us to associate multiple key ids with the same key
> > > in order to express the distinct policies.
> > How much of a burden is this the extra key ID? I don't think there is
> > actually any association - you would always use the same key ID for the
> > "high resolution" policy.
> > 
> > > Worse, the association of policy
> > > to key ids is done in a completely undefined way (which will thus probably
> > > differ between CDMs).
> > How is it undefined? As with "real" key IDs, the application and its server
> > set policies for the key and the CDM reports whether they are enforceable.
> 
> If you are using separate keys with separate policies and the policies are
> all content-independent and the CDM supports such multiple keys in one
> session, then everything is fine.
> 
> But there are CDMs that support only a single key or only a single key at a
> time. And there are CDMs that support content-dependent policies. These CDMs
> would probably need modification to expose multiple key ids associated with
> the same actual key, corresponding to splitting up the policy by content
> property such as resolution. How that is done - what those extra key ids
> would be etc. is undefined (CDM-specific).

I filed https://github.com/w3c/encrypted-media/issues/23 for the more general and problematic issue of CDMs only supporting a single key. If you think there are additional interoperability issues or undefined behavior, please file additional issue(s).
> 
> We need first-class support for the case of policies that are dependent on
> content properties, since this is going to be common. The proposed key
> status values do provide this, albeit in a limited form.
> 
> > > 
> > > It would be cleaner, now that the CSS discussion has concluded this is not a
> > > subset of a more generic requirement, to simply have explicit output
> > > protection events.
> > One important goal of the current solution was to allow the status to be
> > exposed without trying (and potentially failing) to play content.
> 
> That's a good goal, but it is not supported by the proposed key status
> values, since there is no way to expose the content-dependent aspects of the
> policy for a single key id.

It is supported as I explained above. It is definitely not supported if we rely on the properties of content processed by the CDM to change the status.

(In reply to David Dorwin from comment #33)
> (In reply to Mark Watson from comment #30)
> > Ok, let's agree on "downscaling" as a new key status.
> > 
> > Nevertheless, pls see comments below. In summary, we can't require that the
> > policy associated with a key id is independent of content properties. It's
> > already very common to have policies that are content property dependent.
> > So, key status can change as content properties change.
> 
> The key status should not change based on the content. The key status
> indicates the status of the key based on the license and environment (i.e.
> HDCP or time).
> 
> For example:
> * A key that does not require HDCP is always valid (assuming it has not
> expired, etc.).
> * A key that requires HDCP is valid if HDCP is enabled and either
> output-downscaled or output-not-allowed (depending on the client
> implementation) otherwise.
> 
> In the case where a single content key is used for all streams, the first
> key (the real one) would always report valid, and the second (fake) key
> would report whether the output protection policies for higher resolutions
> can be met.

I'll look more closely at the other bug you've filed, but as I've said above, I really don't think the fake key id is a good approach: It's an abuse of the key id concept for something which is really a 'slice' of a policy associated with a single key id and I think it will be difficult to specify interoperably. We need something better.

'output-downscaled' associated with a single key id works fine with 'binary' content-specific policies (e.g. one policy for HD, one for SD) since the content provider knows what that policy is and can infer that downscaling only applies to HD, for example. It doesn't work so well for 'output-not-allowed'.

There are going to be content-specific policies associated with a single key id, so there is ultimately a need for the CDM to slice the policy and indicate the status of each slice against the key id in question. We could require the slices to be ordered (in a content-provider-specified way) and then we just need to indicate a sequence of statuses with the key id.

Anyway, we can address this in the other bug, but we may still need a short-term solution for the binary policy associated with 'not allowed' status (HD not allowed, SD allowed).

> > 
> > This means that you can't learn that content will be downscaled until you
> > feed some content in, but we can live with that for the moment (I believe
> > there are other reasons why that is the case anyway).
> 
> The above design enables you to determine whether content will be downscaled
> without feeding it in. This was an important part of the design as it allows
> applications to determine which streams to download without having to have
> already downloaded streams that will trigger an output protection status
> update/event/error. This was the subject of Bug 25409 ("Allow applications
> to detect whether a key is usable before using it to decrypt content"),
> which led to keyStatuses (via usableKeyIds).
> 
> The intended behavior could probably be better explained in the spec. I
> filed https://github.com/w3c/encrypted-media/issues/22. Suggestions welcome.
> > 
> > If, instead, we wanted the key status to be content-independent, we'd need
> > the status to be a map of resolution -> status.
> 
> I don't see why. The application just needs to map key IDs to streams.
> (Resolution is actually irrelevant unless it's used to select streams, but
> that is an implementation detail of the application.)
> > 
> > (In reply to David Dorwin from comment #29)
> 
> > > (In reply to Mark Watson from comment #27)
> > > > So, this solution forces us to associate multiple key ids with the same key
> > > > in order to express the distinct policies.
> > > How much of a burden is this the extra key ID? I don't think there is
> > > actually any association - you would always use the same key ID for the
> > > "high resolution" policy.
> > > 
> > > > Worse, the association of policy
> > > > to key ids is done in a completely undefined way (which will thus probably
> > > > differ between CDMs).
> > > How is it undefined? As with "real" key IDs, the application and its server
> > > set policies for the key and the CDM reports whether they are enforceable.
> > 
> > If you are using separate keys with separate policies and the policies are
> > all content-independent and the CDM supports such multiple keys in one
> > session, then everything is fine.
> > 
> > But there are CDMs that support only a single key or only a single key at a
> > time. And there are CDMs that support content-dependent policies. These CDMs
> > would probably need modification to expose multiple key ids associated with
> > the same actual key, corresponding to splitting up the policy by content
> > property such as resolution. How that is done - what those extra key ids
> > would be etc. is undefined (CDM-specific).
> 
> I filed https://github.com/w3c/encrypted-media/issues/23 for the more
> general and problematic issue of CDMs only supporting a single key. If you
> think there are additional interoperability issues or undefined behavior,
> please file additional issue(s).
> > 
> > We need first-class support for the case of policies that are dependent on
> > content properties, since this is going to be common. The proposed key
> > status values do provide this, albeit in a limited form.
> > 
> > > > 
> > > > It would be cleaner, now that the CSS discussion has concluded this is not a
> > > > subset of a more generic requirement, to simply have explicit output
> > > > protection events.
> > > One important goal of the current solution was to allow the status to be
> > > exposed without trying (and potentially failing) to play content.
> > 
> > That's a good goal, but it is not supported by the proposed key status
> > values, since there is no way to expose the content-dependent aspects of the
> > policy for a single key id.
> 
> It is supported as I explained above. It is definitely not supported if we
> rely on the properties of content processed by the CDM to change the status.

The enum has been added. Discussion continues in https://github.com/w3c/encrypted-media/issues/22.