Playback of Axinom multi-key DASH does not request all keys from license server

[sandersaares]

Videos: v7-MultiDRM-MultiKey 1080p and v7-MultiDRM-MultiKey-MultiPeriod 1080p from the Axinom playlist.

The videos are encrypted using different keys for different tracks (or groups of tracks). See https://github.com/Axinom/dash-test-vectors for more info.

Device: Nexus 9 running Android 7

ExoPlayer version: 5600716

Android bug report: report.zip

Actual behavior

Playback fails with the following in the log: E/WVCdm: PolicyEngine::CanDecrypt Key '80399BF58A2140148053E27E748E98C0' not in license.

Inspection of network traffic reveals a single license request. Fiddler logs attached: NetworkLogs.zip

Inspection of the license request indicates that there is a single PSSH with a single referenced key.

message_type:    LICENSE_REQUEST
type:    NEW
request_time:    Thu, 15 Sep 2016 09:39:11 GMT
has_client_id:    true
company_name:    htc
model_name:    Nexus 9
architecture_name:    arm64-v8a
device_name:    flounder
product_name:    volantis
build_info:    google/volantis/flounder:7.0/NRD90M/3085278:user/release-keys
device_id:    B4CEF6073A93
widevine_cdm_version:    v4.0.0-android
oem_crypto_security_patch_level:    0
has_encrypted_client_id:    false
license_type:    STREAMING
request_id:    NEJEODU3MjRFOTZDQTYzRTAxMDAwMDAwMDAwMDAwMDA=
Pssh(s)
key_id1_1:    CHJ4bvnnRl+jok5bDvj6RQ==
provider1:    
content_id1:

Expected behavior

The license request should either contain the PSSHs of all the tracks to decrypt or there should be multiple license requests. Regardless of the mechanism, more than one key is needed to play this video.

In case of the multi-period video, the expectation is that new license requests are made when the 2nd period starts, as appropriate, to obtain the new keys that are used for the 2nd period.

[ojw28]

From my point of view, within a single period, expected behavior is that your license server should respond with all of the keys required to play the content when provided with a request that contains the PSSH for one of the streams. This is how other providers I'm aware of have implemented this. I believe it's achieved due the presence of some kind of content id in the request, which can be mapped server-side onto the required set of keys.

Note that multiple license requests is obviously inefficient and more error prone, so that's not a great solution. A single request containing multiple PSSHs is similarly inefficient if the PSSH data is embedded in the streams rather than being provided in the manifest. If the data is in the manifest then that sounds fairly sensible, but I doubt we'll be supporting it given other providers I'm aware of have adopted the solution described above.

[sandersaares]

DASH-IF IOP v3.3 section 7.7.1 says:

‘pssh’ boxes SHOULD NOT be present in Initialization Segments, and cenc:pssh elements in ContentProtection Descriptors used instead.

MPEG-CMAF latest draft says:

CMAF streaming applications SHOULD signal license acquisition information in the Manifest, and SHOULD NOT duplicate the information in Protection System Specific Header Boxes in CMAF Headers.

Having PSSHs in the manifest is the right way to do it and supported by industry standards. Any content that does it otherwise only has itself to blame for any inefficiency.

I feel it may be unwise to design player features to target merely the present-day implementations of DRM services and content workflows that are not keeping pace with modern industry specifications.

Certainly, expecting behind-the-scenes magic to take care of key transfer seems entirely incorrect - if the device requests key A, there seems little reason to expect that it also receives key B. Any DRM service implementation that does so seems more of a hack than anything standards conforming. I suspect such implementations exist primarily because players are unable to cope with multi key scenarios (chicken, meet egg).

[ojw28]

Thanks for the info!

Having PSSHs in the manifest is the right way to do it and supported by industry standards. Any content that does it otherwise only has itself to blame for any inefficiency.

Aside from the rest of this discussion, I'm not sure that's quite fair given many providers deployed DASH before the IOP included the recommendations to which you refer. I guess this is a problem inherent with situations where you have an extremely general spec being retrospectively constrained. Which is unfortunate!

I feel it may be unwise to design player features to target merely the present-day implementations of DRM services and content workflows that are not keeping pace with modern industry specifications.

This is true. We do need to make any changes in a measured way though. In particular we should not make changes that penalize providers who already use ExoPlayer and who have deployed DASH in a way that now violates the IOPs. It's not realistic to expect content providers to repeatedly adjust their workflows, servers and content every time a new IOP recommendation is introduced, particularly if they have large content libraries that are expensive to re-transcode. There is significant cost and delay involved in practice.

Certainly, expecting behind-the-scenes magic to take care of key transfer seems entirely incorrect - if the device requests key A, there seems little reason to expect that it also receives key B. Any implementation that does so seems more of a hack than anything standards conforming.

Is there anything specific in the IOP that states this? I don't think either of the sections quoted above say that key request / response should not work in the way I describe. My understanding is that this is partly scheme specific. In particular, my understanding is that the approach I describe is readily supported by Widevine, but not by PlayReady. The reporter of #968 was able to adjust their Widevine proxy to return all keys. If Widevine provide support for this then it seems reasonable for ExoPlayer to rely on the approach, given Widevine is the de-facto DRM solution for Android devices.

@wvpaf - Could someone from Widevine comment on this also. You're the real experts here. Thanks!

[sandersaares]

Fair point about backward compatibility - that is indeed quite an unavoidable consideration and expecting content to be changed is not something that would make anyone happy. I don't think there is anything with so drastic implications here, though.

I can see two important viewpoints when considering how key acquisition with DASH content should work. One is the format/interoperability aspect. In DASH-IF IOP, there is this statement in 7.6.2.1:

When the default_KID is present on each Adaptation Set, it allows a player to determine if a new license needs to be acquired for each Adaptation Set by comparing their default_KIDs with each other, and with the default_KIDs of stored licenses. A player can simply compare these KID strings and determine what unique licenses are necessary without interpreting license information specific to each DRM system.

and this in 7.6.2.3:

With cenc:default_KID indicated in the mp4protection ContentProtection Descriptor on each Adaptation Set, clients can determine if that key and this presentation is not available to the viewer (e.g. without purchase or subscription), if the key is already downloaded, or which licenses the client SHOULD download before the @availabilityStartTime of the presentation based on the default_KID of each AdaptationSet element selected.

In my eyes, these do imply the behavior I described, though it is certainly not explicit. I will also raise this topic in DASH-IF - perhaps we can clarify the guidelines on this point.

The other viewpoint is the DRM architecture one. From the viewpoint of a DRM service provider, it is desirable to separate the concepts of key management, DRM systems and entitlement business logic. This leads to a cleaner architecture and allows solutions to be built in more flexible, interoperable and future-proof ways.

An imaginary (actually not very imaginary) DRM architecture would consist of:

• A key service that generates, manages and exports keys.
• A entitlement service that decides which end-users are authorized to view which pieces of content and maps this to sets of keys.
• A set of DRM technology specific license services that take license requests, checks for authorization, gets the keys from the key service and exports them, together with any constraints (e.g. expiration HDCP etc), in the form of licenses.
• An authorization service that either provides authorization tokens or acts as a proxy (or something even more innovative) to prove to the license services that incoming requests for keys are authorized.

That is a pretty complex arrangement (and one of many ways to do it, for sure) that requires a fair bit of separation of concerns to design and implement in a sensible way. Intrusions of "custom business logic" like "for Widevine, actually ignore the key IDs in the request and just use the content ID" just serve to fragment and overcomplicate the picture.

Furthermore, viewing the situation from the viewpoint of a simple Widevine proxy makes it all seem trivial to implement in the proxy. However, that is not at all how any multi-DRM architecture operates - we do not live in a world where a solution can only target Widevine. Modern solutions need to be flexible and interoperable and free from DRM-technology-specific logic. Indeed, the very fact that a Widevine proxy is required is a significant roadblock to making good use of DRM (which, thankfully, various service providers are fixing by offering this as a service - but that comes back again to the negative ecosystem implications of having to embed custom business logic).

It is true that the entire world of DRM remains to this day highly scheme-specific and full of proprietary logic. It is difficult to change this but definitely worthwhile - an open and interoperable ecosystem makes it possible to serve premium content to the widest possible audience without exorbitant cost.

[ojw28]

Fair point about backward compatibility - that is indeed quite an unavoidable consideration and expecting content to be changed is not something that would make anyone happy. I don't think there is anything with so drastic implications here, though.

There's also client compatibility to think about. I'm not sure there's a way to efficiently support your proposed behavior on existing Android devices. Specifically, I'm not sure it's possible to avoid having multiple DRM sessions and multiple separate key requests with the way MediaDrm and the Widevine CDM are implemented currently. IIRC the number of concurrent MediaDrm sessions is also quite limited on some of the first devices that got MediaDrm support.

Intrusions of "custom business logic" like "for Widevine, actually ignore the key IDs in the request and just use the content ID" just serve to fragment and overcomplicate the picture.

This is unarguably true, but pragmatically it's important to weigh up how much it really matters. Is it really a huge burden, or in practice is it an hour or two of work and an annoyance that it's not an elegant solution? By all means get some clarification on the issue, but in the short and medium term (possibly even long term if existing clients cannot easily support your expected behavior), I suspect you'll end up having to accept how things are done currently and take the complexity hit on the serving side.

[wvpaf]

Any other questions or actions? Or can this be closed?

[sandersaares]

From my perspective, we are looking at undesirable and non-interoperable behavior by the player here, as described above. However, if this is by design then of course there may not be much reason to keep it open.

The topic is currently under discussion in DASH-IF with regard to clarifying the expectations in a further version of the Interoperability Points specification. It may take some time for the topic to be thoroughly processed, though.