NEW197433
Unprefixed EME with "com.apple.fps.1_0" fails with "The operation is not supported." 
https://bugs.webkit.org/show_bug.cgi?id=197433
Summary Unprefixed EME with "com.apple.fps.1_0" fails with "The operation is not supp...
Joey Parrish
Reported 2019-04-30 13:09:46 PDT
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?
Attachments
Screenshot of com.apple.fps failure (35.58 KB, image/png)
2019-05-01 09:30 PDT, Joey Parrish 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2019-04-30 22:03:27 PDT
<rdar://problem/50361384>
Jer Noble
Comment 2 2019-05-01 07:55:35 PDT
(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
Comment 3 2019-05-01 09:26:49 PDT
Thanks, Jer. But the results are the same with 'com.apple.fps'. Am I doing something else wrong?
Joey Parrish
Comment 4 2019-05-01 09:30:02 PDT
Created attachment 368678 [details] Screenshot of com.apple.fps failure Here's a screenshot
Jer Noble
Comment 5 2019-05-01 10:28:18 PDT
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
Comment 6 2019-05-01 10:47:28 PDT
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
Comment 7 2019-05-08 13:30:47 PDT
Thank you so much. We'll work toward supporting 'sinf' and unprefixed EME in Shaka Player.
Note You need to log in before you can comment on or make changes to this bug.