Bug 197433 – Unprefixed EME with "com.apple.fps.1_0" fails with "The operation is not supported."

• Component: Media
• Status: NEW

[Joey Parrish]

Running the following in the Safari debugger on localhost (a secure origin) fails with "The operation is not supported":

minimalConfig = {videoCapabilities: [{contentType: 'video/mp4; codecs="avc1.42E01E"'}]};
mk = await navigator.requestMediaKeySystemAccess('com.apple.fps.1_0', [minimalConfig]);

But the equivalent calls in the prefixed API works fine:

WebKitMediaKeys.isTypeSupported('com.apple.fps.1_0', 'video/mp4; codecs="avc1.42E01E"')
mk = new WebKitMediaKeys('com.apple.fps.1_0');

As does the unprefixed API with clearkey:

minimalConfig = {videoCapabilities: [{contentType: 'video/mp4; codecs="avc1.42E01E"'}]};
mk = await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [minimalConfig]);

I'm running macOS Mojave and Safari 12.1, so this should work, right?  It's not clear from the error what is wrong or missing.

Has the key system ID changed?  Are there docs on this somewhere that I've missed?

[Radar WebKit Bug Importer]

<rdar://problem/50361384>

[Jer Noble]

(In reply to Joey Parrish from comment #0)
> Running the following in the Safari debugger on localhost (a secure origin)
> fails with "The operation is not supported":
> 
> minimalConfig = {videoCapabilities: [{contentType: 'video/mp4;
> codecs="avc1.42E01E"'}]};
> mk = await navigator.requestMediaKeySystemAccess('com.apple.fps.1_0',
> [minimalConfig]);

The "1_0" vs. "2_0" nomenclature in the prefixed API was necessary because of message passing protocol changes that were subsequently made unnecessary by the Modern EME API; namely, certificates get first-class treatment. Also, the "1_0" protocol only ever worked with HLS-backed video elements, due to the difference initialization data in HLS vs. ISO, something that was also given first class treatment in Modern EME.

> Has the key system ID changed?  Are there docs on this somewhere that I've
> missed?

Yes, you just need to use "com.apple.fps". We're still working on the Modern EME documentation; I apologize that it's not ready yet.

[Joey Parrish]

Thanks, Jer.  But the results are the same with 'com.apple.fps'.  Am I doing something else wrong?

[Joey Parrish]

Created attachment 368678 [details]
Screenshot of com.apple.fps failure

Here's a screenshot

[Jer Noble]

From <https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/avfoundation/CDMFairPlayStreaming.cpp>, CDMPrivateFairPlayStreaming::supportsConfiguration(...).

The first check is that the initDataType is valid. Currently supported initDataTypes for FairPlayStreaming are 'skd' (if you're using HLS-backed media) or 'sinf' (if you're using ISO). We're working on adding 'cenc'.

The 'sinf' initDataType is a UTF-8 encoded JSON string containing one-or-more base64-encoded 'sinf' boxes. This is the same structure you'd get from the prefixed EME APIs.

However, I now see that the "Get Supported Configuration and Consent" algorithm <https://w3c.github.io/encrypted-media/#get-supported-configuration-and-consent> states that check should only be made if the initDataTypes member is non-empty. I'll put up a patch to reflect that.  Meanwhile, you should be able to work around this by passing in 'sinf' to your "minimal configuration".

[Jer Noble]

FWIW, all our internal tests use something like:

var access = await navigator.requestMediaKeySystemAccess("com.apple.fps", [{
    initDataTypes: ['sinf'], 
    videoCapabilities: [{ contentType: 'video/mp4', robustness: '' }], 
    distinctiveIdentifier: 'not-allowed', 
    persistentState: 'not-allowed', 
    sessionTypes: ['temporary'], 
}]);

[Joey Parrish]

Thank you so much.  We'll work toward supporting 'sinf' and unprefixed EME in Shaka Player.