PlayReady SL3000 support requires com.microsoft.playready.recommendation key system

[markriley9999]

Hi All

I wonder if you can help me.

I want to enable PlayReady SL3000 support. I currently have this working (using the Edge browser), which is a start!

To do this, I am working on the assumption the following 2 steps are carried out by the client.

#1: explicitly set the security level to 3000, either by the setRobustnessLevel("3000") api call or setting videoRobustness (or audio) to "3000" in the key system init data (passed in via setProtectionData api call) - not sure which is preferable.

now the potentially contentious bit...

#2: I believe (and this would appear to be true based on my testing) that I need to request the "com.microsoft.playready.recommendation" key system (not the older 'legacy' (and non EME compliant?!) "com.microsoft.playready key system").

however, I do not see an obvious way to explicitly request this key system - in fact, I only seem to be able to do this indirectly by setting the "persistentState" property which has the useful (intended) side-effect of changing the key system from "com.microsoft.playready" to "com.microsoft.playready.recommendation".

eg here's the dashjs code snippet which does this:
// Patch to support persistent licenses on Edge browser (see issue #2658)
if (systemString === ProtectionConstants.PLAYREADY_KEYSTEM_STRING && configs[0].persistentState === 'required') {
systemString += '.recommendation';
}

there's an interesting reference here:
#2658 (comment)

so, my question is, is there a better way to request the use of the "com.microsoft.playready.recommendation" key system, as it does not feel right to me to rely on a side effect of another property to set this?

the issue seems to exacerbated by the fact that the 2 playready keysystems, ie:
- com.microsoft.playready
- com.microsoft.playready.recommendation
share the same uuid, even though they would appear to behaviourally rather different.

i get the impression from Microsoft that we really should now only be using the com.microsoft.playready.recommendation key system - however, there's a concern that this will cause in-the-field regressions (perhaps with hindsight creating a new uuid would have mitigated this).

i guess one potential pragmatic solution would be to workaround this using the same approach as used to resolve issue #2658, which could look something like this:

    if (systemString === ProtectionConstants.PLAYREADY_KEYSTEM_STRING && (configs[0].persistentState === 'required' || configs[0].videoCapabilities[0].robustness === '3000')) {
        systemString += '.recommendation';
    }

Note: i haven't actually tried this yet!

However, this would only help me for my specific usecase - and will continue to propagate the confusion between the 2 key systems.

Whilst i have investigated this - i can't help but feel that i'm missing something here obvious - as i'm surprised that i'm the only one having this issue!
Anyway, look forward to hearing your thoughts on this.

[Murmur]

We have done this simple test page to try out few scenarios with Playready security level. Use MSEdge for playready testing, you need quite recent PC hardware to have a valid trusted environment blocks.
I'll create a new test content with 4K resolution in few days.

https://refapp.hbbtv.org/dash/test_dashjs_sl3000.html

protData={ 
  "com.microsoft.playready": { 
     "serverURL": "https://license.com/rightsmanager.asmx?..."
      , "priority":1
      , "persistentState": "required", "distinctiveIdentifier": "required" 
      , "videoRobustness": "3000"
      , "audioRobustness": "2000"
  }
  ,"com.widevine.alpha": { "priority":99 }
};

[dsilhavy]

@markriley9999 @Murmur Thank you for the detailed description. We will check this and make a proposal how to move on. As far as I understand com.microsoft.playready.recommendation should be used as the default. We could fallback to com.microsoft.playready if com.microsoft.playready.recommendation is not supported. To my best knowledge there is also com.microsoft.playready.hardware to enforce Hardware DRM, so in theory there are three different system strings.

[dsilhavy]

I added a first draft for a solution in #3859. The idea is described in the PR. Basically, it allows us to define multiple system strings to be applied by priority for the different DRM systems. This is work in progress I did not carefully test this yet, further adjustments might be required. However, any feedback is welcome.

@bbert fyi, maybe you also want to comment

[markriley9999]

i must admit that it's not clear to me as to whether the requirement to use the 'com.microsoft.playready.recommendation' keysystem applies only to the Edge browser or whether it should be applied across all browsers (i assumed the latter...).

does anyone know? is this documented anywhere?

i'm wondering if @swenkeratmicrosoft can clarify. thanks!

[swenkeratmicrosoft]

For key system string:

On Windows, I am unaware of any browser that supports PlayReady except Edge. For Edge, com.microsoft.playready.recommendation is the correct key system string.

If any other browsers support playready, it's up to them what key systems they support and how they support them, e.g. they could decide to implement com.microsoft.playready such that it remaps to com.microsoft.playready.recommendation before it calls into the OS, or they might use com.microsoft.playready.recommendation only and not support com.microsoft.playready at all, or whatever they wish to do. Microsoft has no control over that.

On non-Windows, there are multiple possibilities for the key system string.

1. If the browser implementation is directly passing the key system string to PlayReady porting kit 3.3 or higher without changes, then the correct key system string is: com.microsoft.playready.recommendation.
2. If the browser implementation is directly passing the key system string to PlayReady porting kit 3.2 or lower without changes, then the correct key system string is: com.microsoft.playready.
3. If the browser implementation is modifying the key system string before passing it into the PlayReady porting kit, I have no way of knowing what modifications they do, so I can't assist with giving you the correct key system string.

For robustness level / hardware DRM:

Edge on Windows should properly map 3000 to hardware DRM. If you're having trouble getting that to work properly, you can also use the key system string com.microsoft.playready.recommendation.3000 (windows only) to force hwdrm for video. If the key system string com.microsoft.playready.recommendation is not supported, you CAN fallback to com.microsoft.playready (or com.microsoft.playready.hardware) for the legacy implementation. However, the legacy implementation has MANY incompatibilities with the EME spec AND we may remove support for it entirely in the future. I strongly recommend against using the legacy implementation under any circumstances.

Again, I can't speak to non-Edge Windows browsers.

For non-windows, the PlayReady porting kit doesn't know what level it is running at - only the OEM implementing the device can determine that. As a result, it is up to the browser to correctly implement the robustness level value to reject robustness level 3000 when it is not supported.

For persistent state:

Unless you have a strong reason not to, I recommend always specifying persistent state as "required".

For distinctive identifiers:

Always specify distinctive identifiers to "required". PlayReady requires distinctive identifiers for all implementations on all platforms.

Hope that helps,

-Sam Wenker with the Microsoft PlayReady team

[Murmur]

Mixing in HbbTV and SmartTV platforms. Everything was clear until .recommendation | SL3000 came into play :)

DashJs on MSE-EME SmartTVs, how do should Playready be initialized for SL3000 mode in SmartTVs, is videoRobustness | persistentState flags necessary etc..

In the old times just give mpdUrl + Laurl and play.

[swenkeratmicrosoft]

My apologies - I had some incorrect information in my previous post.

I've updated it with a lot of details which should hopefully answer your questions.

-Sam Wenker with the Microsoft PlayReady team

[swenkeratmicrosoft]

Here's some additional background and context on this.

The reason for having two key system strings for PlayReady is because Microsoft had major customers requesting EME support long before the EME spec became a recommendation - it was still in draft. As a result, Microsoft implemented com.microsoft.playready based on that draft spec. The EME spec changed substantially after that implementation was released - so much so that there was no way to modify the existing implementation to be compatible with both the final recommendation spec and existing websites - Microsoft had a choice of either breaking existing websites or not being spec compliant, and we chose the latter. Since EME provides no way to specify additional key-system-specific data in the MediaKeySystemConfiguration, we had no choice but to create a new key system string for the new, spec-compliant implementation.

Unfortunately, that does add a bunch of nuance to how playready is used. If you're only dealing with recent Windows OS, recent Edge, and recent third party browsers built on a recent PK and not doing anything unusual with the key system string in their implementations (where "recent" is relative in all cases), it's pretty simple - com.microsoft.playready.recommendation with robustness string 3000 if desired. But as soon as you start factoring in all the combinations of older implementations, things get wonky.

-Sam Wenker with the Microsoft PlayReady team

[dsilhavy]

@swenkeratmicrosoft Thank you for the detailed description.

@bbert @markriley9999 @Murmur I think #3859 offers the required flexibility. We can use different systems strings with that PR, persistentState and distinctiveIdentifier can be set via API as well. What do you think? Also, should we add the logic of #3859 to the older EME versions (2014, 0.1b) as well if possible?

[Murmur]

@dsilhavy @swenkeratmicrosoft I think so #3859 could provide a flexibility without a need to do an obscure configName = MSEdgeVersion < X THEN .playready ELSE .playready.recommendation application level code.

If content owners require a Playready SL3000 then "videoRobustness" : "3000" flag is mandatory in a dashjs protData{} configuration object. This need a modern intel cpu Win10 machine to make SL3000 playable.

Hbbtv-SmartTV implementation details is an another story I need to study more, this genre is also moving to MSE-EME player stack but the browser engine is not always a carbon copy of pc browsers.

[swenkeratmicrosoft]

@Murmur - Correction: It's the graphics card that needs to support SL3000, and modern graphics cards from several vendors (Intel, Amd, NVidia, Arm) support it. An intel CPU is not required (although Intel graphics cards in particular might require an Intel CPU - I'm not sure there).

-Sam Wenker with the Microsoft PlayReady team

[markriley9999]

Hi All

thanks @swenkeratmicrosoft for the background info.
what a fascinating can of worms :)

I think @Murmur summed it up well with
'Everything was clear until .recommendation | SL3000 came into play :)'

Support of PlayReady (+SL3000) via a Browser CDM is on the cusp, in the UK, to being widely supported by embedded TV browsers - so it's important to standardise where possible (which I’m sure that we all agree upon).

I personally have already started to see fragmentation in the (TV) industry where some manufacturers support SL3000 via the 'legacy' keysystem ("com.microsoft.playready") and others via the newer keysystem ("com.microsoft.playready.recommendation").

I think we have an opportunity now (but, which is quickly passing) to standardise on a single keysystem.

I appreciate that @dsilhavy proposal would appear to be very pragmatic and I think functionally will serve our purpose in the context of getting SL3000 to work with DASHJS, so that's good. :)

However, clear guidance to the TV manufacturers (who will then feed this back to embedded browser suppliers - sometimes the same entity) as to exactly which system should be used, for new devices, would be very useful and personally my vote would be not to use the legacy "com.microsoft.playready" keysystem for new devices, ie @swenkeratmicrosoft's recomendation #1:

'1. If the browser implementation is directly passing the key system string to PlayReady porting kit 3.3 or higher without changes, then the correct key system string is: com.microsoft.playready.recommendation.'

I appreciate that we may be stepping outside the remit of DASHJS here (but I guess it is still related...).

look forward to hearing your thoughts! :)

[dsilhavy]

#3859 is merged, thank you all for the feedback. I am converting this to a discussion thread.

[markriley9999]

Many thanks for your help :)

[dsilhavy]

Used the chance to write a blog post as well: https://websites.fraunhofer.de/video-dev/following-the-recommendation-key-system-string-priority-in-dash-js/ :)

[dsilhavy]

As an fyi: I had to revert the system string order to com.microsoft.playready as the default system. I saw multiple "invalid state errors" when trying to update the key session using com.microsoft.playready.recommendation. I am not sure what causes this as it works fine with com.microsoft.playready. We need to investigate this further, I create an issue for this.

Tested with:

• https://d24rwxnt7vw9qb.cloudfront.net/v1/dash/e6d234965645b411ad572802b6c9d5a10799c9c1/All_Reference_Streams/2fc23947945841b9b1be9768f9c13e75/index.mpd
• https://content.uplynk.com/playlist/6c526d97954b41deb90fe64328647a71.mpd?ad=bbbads&delay=25

[swenkeratmicrosoft]

@dsilhavy

If the error is internal to dash.js, I'm afraid I won't be able to help you. However, if the error is coming from the platform / Edge (i.e. EME or Media Element APIs), I can assist you with this investigation if you're able to collect and share trace files from the OS.

Specifically:

1. Download the following zip file. The included executable is signed by Microsoft.
2. Follow the instructions in the included readme to start, stop, and zip up the trace files for the successful scenario (i.e. using com.microsoft.playready)
3. Repeat for the failure scenario (i.e. using com.microsoft.playready.recommendation)
4. You should now have two different zip files. Share them with me via whatever means you find easiest. I can decode them internally and should be narrow down the cause of the error.

https://github.com/microsoft/media-foundation/releases/download/V1/mftracelog.zip

The PlayReady team is very interested in getting people away from using com.microsoft.playready in Edge, so I am happy to assist if I can be of use.

-Sam Wenker with the Microsoft PlayReady team

[dsilhavy]

@swenkeratmicrosoft Thank you for the support. I will get back to you asap. Please note that I will be on vacation until 15th March so my response will be a bit delayed.

[Murmur]

@swenkeratmicrosoft I took liberty to run a full stackrace on my Windows10Edge browser. It would be interesting to know how do we identify the compatible SL3000 win10 machines. My laptop is too low-end hardware?

My Edge fails on video=SL3000,audio=SL2000 test case, see test page and log.zip.
https://refapp.hbbtv.org/dash/test_dashjs_sl3000.html?video=sl3000
https://refapp.hbbtv.org/dash/mftracelog_sl3000_murmur.zip

My Edge is fine playing video=SL2000,audio=SL2000 test case.
https://refapp.hbbtv.org/dash/test_dashjs_sl3000.html?video=sl2000

https://refapp.hbbtv.org/dash/test_dashjs_sl3000.html?video=sl3000
- LaUrl failed
- content has a VIDEO=SL3000, AUDIO=SL2000
- video and audio are using a different KeyID+EncKEY values
- test is using the old protDataConfig dashjs trick to activate .recommendation systemDrm

2022-02-25T09:44:22 Invoke TestEME async functions
2022-02-25T09:44:22 ready
2022-02-25T09:44:22 DRM: com.microsoft.playready,urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95 (use=true)
2022-02-25T09:44:22 DRM: com.widevine.alpha,urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed (use=false)
2022-02-25T09:44:22 DRM: org.w3.clearkey,urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e (use=false)
2022-02-25T09:44:22 DRM: org.w3.clearkey,urn:uuid:1077efec-c0b2-4d02-ace3-3c1e52e2fb4b (use=false)
2022-02-25T09:44:22 https://refapp.hbbtv.org/videos/00_llama_1080p_v4/drm/manifest_sl3000.mpd
2022-02-25T09:44:22 https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)
2022-02-25T09:44:22 {"com.microsoft.playready":{"serverURL":"https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)","priority":1,"persistentState":"required","distinctiveIdentifier":"required","videoRobustness":"3000","audioRobustness":"2000"},"com.widevine.alpha":{"priority":99}}
2022-02-25T09:44:22 playready:com.microsoft.playready.recommendation supported
2022-02-25T09:44:22 playready:com.microsoft.playready supported
2022-02-25T09:44:22 playready:com.microsoft.playready.hardware supported
2022-02-25T09:44:22 widevine:com.widevine.alpha supported
2022-02-25T09:44:22 clearkey:org.w3.clearkey supported

LaUrl Request:
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><AcquireLicense xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols"><challenge><Challenge xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols/messages"><LA xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols" Id="SignedData" xml:space="preserve"><Version>1</Version><ContentHeader><WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0"><DATA><PROTECTINFO><KEYLEN>16</KEYLEN><ALGID>AESCTR</ALGID></PROTECTINFO><KID>eFYhQzQSNBISNBI0EjQSNw==</KID><CHECKSUM>rmiPczvCWt0=</CHECKSUM><LA_URL>https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==)</LA_URL></DATA></WRMHEADER></ContentHeader><CLIENTINFO><CLIENTVERSION>10.0.16384.10011</CLIENTVERSION></CLIENTINFO><RevocationLists><RevListInfo><ListID>ioydTlK2p0WXkWklprR5Hw==</ListID><Version>11</Version></RevListInfo><RevListInfo><ListID>gC4IKKPHsUCCVhnlttibJw==</ListID><Version>11</Version></RevListInfo><RevListInfo><ListID>Ef/RUojT3U6Ct2jqTCChbA==</ListID><Version>57</Version></RevListInfo><RevListInfo><ListID>BOZ1zT1UnEqfCf5tJOi/kA==</ListID><Version>12</Version></RevListInfo></RevocationLists><LicenseNonce>dwhfy18IR7SxMr7PQvQbWg==</LicenseNonce><ClientTime>1645775063</ClientTime><EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"></EncryptionMethod><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"><EncryptionMethod Algorithm="http://schemas.microsoft.com/DRM/2007/03/protocols#ecc256"></EncryptionMethod><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><KeyName>WMRMServer</KeyName></KeyInfo><CipherData><CipherValue>YJFJbMGJoezGwNFn9EFF1KXfwpHPF/Cs6IKKe9tZs3SDRRrL3nePKlYyEVfKO8WPjf2H9/i/GyO2X4iihKASZfyexrmB0jn+iLblSGSDH6p0GXT60gIAglVDW4ngJxHcALKBeJ1yk7JygdvwUHAUhnYiuLhdCODHA8dkcEXbplU=</CipherValue></CipherData></EncryptedKey></KeyInfo><CipherData><CipherValue>qQleb3ulJS0BWyZJpzz/FRq42hNo6hwfFoYz7gyV/yVAHtp7khrSNkolSze5XgLVvKNpSyLJxyIIOHj6vkPtTbnqBLE4s4wJ4EfAg4bMv2B6szfzvZs8iI6/z16qOWF3baEZNwIsowKWpM2k3Uu9J+7IBDgsDCMNW6qjnRqmonFFzvtQsHtRDY2zmPLotfHtiOoTnDluwUo0adf3Y3vy362Xg4Up6b9+QNYlU2jvtPB6UYP7b6OCzcstTmFgCHhXbn9jwehLY8F2g+fhkvsh63K7nCbtZy4ixRimmMSFhZqzJI5QmydgKyspX2O1rb7zNxWyhmZ0moEEDoEQYODz+0Wczch0gP86OVhowA72bIcyMgWYopLP8fsJD3LAT5uoAxFweCnsopsFWf66eMiJ4AsHUT/tyY31aLj+Mvz7zueQJn7HwTIEmvKaeoXuhAFK8e6Nmz84fhNanOboVQA7HXXEnrKSZWOCOiNVTiV0j3uunrGirLRitc3dmwJuG77csvDrgmYlRT1N65JfuZAPvpTDyWql3IqLWqbjxu7oTWzttQlBHutFGm73IWtj0/Slx3UVDUYsTzh7I1iyu7J8vFYGr2Ru0lQzZYo2GdNXuMMD0+l19o6mF8LiZmMhD7h8LR0BevgvUABF21GvUfnK0io9+LI2r+J+iK4gbdC9K/iX9vGLqzKtZbPxT+pFDw2CEaF/M11jM2dK0/O55dbiZwaAShow more

LaUrl Response, retval 500=Internal Server Error:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Internal service error</faultstring><faultactor>https://prtsprod-rightsmanager-v45.azurewebsites.net/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)</faultactor><detail><Exception><StatusCode>0x8004c600</StatusCode><DebuggingData>Server record locator = 00f24d58-29c3-416e-83c7-9f658928dcef</DebuggingData></Exception></detail></soap:Fault></soap:Body></soap:Envelope>

LaUrl Request:
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><AcquireLicense xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols"><challenge><Challenge xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols/messages"><LA xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols" Id="SignedData" xml:space="preserve"><Version>1</Version><ContentHeader><WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0"><DATA><PROTECTINFO><KEYLEN>16</KEYLEN><ALGID>AESCTR</ALGID></PROTECTINFO><KID>eFYhQzQSNBISNBI0EjQSNg==</KID><CHECKSUM>+9ki7/ttseA=</CHECKSUM><LA_URL>https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)</LA_URL></DATA></WRMHEADER></ContentHeader><CLIENTINFO><CLIENTVERSION>10.0.16384.10011</CLIENTVERSION></CLIENTINFO><RevocationLists><RevListInfo><ListID>ioydTlK2p0WXkWklprR5Hw==</ListID><Version>11</Version></RevListInfo><RevListInfo><ListID>gC4IKKPHsUCCVhnlttibJw==</ListID><Version>11</Version></RevListInfo><RevListInfo><ListID>Ef/RUojT3U6Ct2jqTCChbA==</ListID><Version>57</Version></RevListInfo><RevListInfo><ListID>BOZ1zT1UnEqfCf5tJOi/kA==</ListID><Version>12</Version></RevListInfo></RevocationLists><LicenseNonce>/pb8GxyKtDnasdayDVEuyw==</LicenseNonce><ClientTime>1645775063</ClientTime><EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"><EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"></EncryptionMethod><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"><EncryptionMethod Algorithm="http://schemas.microsoft.com/DRM/2007/03/protocols#ecc256"></EncryptionMethod><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><KeyName>WMRMServer</KeyName></KeyInfo><CipherData><CipherValue>5/bofhIVrRTqFF3ceLDvrTXyjiy6N2fBFMErs7DFRkkyBH3Rnhtp24V2/MG7zITBxre6QS2IcamuYcu1T0N+2b1bcrTri537O8YX1NNnobYIQdwF+o3dRbESeik7dLEhTFKz6UBCsNUx+zdNEPU15lIi9HZUTvu96eWCPg0CfsE=</CipherValue></CipherData></EncryptedKey></KeyInfo><CipherData><CipherValue>XAY1yOf6u0UBHWPO/IBrglXCBzwaFmKDr7TLbxIPsq3m0aAkdBKKHWKPD23W+p4fxQrk4Q5LIk0Hpe7g3yUsQ8W6BhvKqPKTK49KHe5dml+3EuAd12XHy6TBGM4piF8MiFgqUAQ7HbRyVWBJqwz/S/+ICaJr/ctbz9CBjO49L3Kys9KWikfG7WWaOPoA8CYsnRFHOEdEeF9qFrBXaW5eZAV77vgxkMimfMw9wm8X9KxGDJEQWQQnF64Q1Wgr7DvWREQAY2WS4tHWn1lVrchoJadJxH2oJEW+bEwPZMgO+6wSjbf61FnJ7e97r6aaN66VDYCh61ej6D41ojmk4aJs+VrNDXhhMLFbjaUR2qsaXPdP6pPRiC+YVKsisFpOptzoS8x34Zx7BksTJw7Vp5KDCgCixP1sXU2rValz+KIAo+lKfiD9gek6FvPt+BSTtTMD+guY1FY6BqBD0FkEpeG2io8sDdBEOMIrBuhIbalPbxN4aTLB/hpw8VgALAUot107YDM+lfh2r8iOxqtbNdNKUWwh/UPwkeu+Ck+1hosVqmoJEitJt2Jsgi4dRzKJITjpmclFDcPke2m9z6JOo36wMjP0TDRAX6asnD5L5W/EFwAi5fMEejMRMtKB10byNG4HCkKQeMtXAJqg5K9KhWh+YzI7j8ai6CE2bxwONAR0c5NPoY2+lx2lbqJeSgsttUF6aTaDyU/T5I8YhCh4oRINlv4kShow more

LaUrl Response, retval 500=Internal Server Error:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Internal service error</faultstring><faultactor>https://prtsprod-rightsmanager-v45.azurewebsites.net/rightsmanager.asmx?cfg=(kid:43215678-1234-1234-1234-123412341237,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNw==),(kid:43215678-1234-1234-1234-123412341236,sl:2000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)</faultactor><detail><Exception><StatusCode>0x8004c600</StatusCode><DebuggingData>Server record locator = 4d1f53f5-0aef-47d4-8c2a-ebe20cba46ec</DebuggingData></Exception></detail></soap:Fault></soap:Body></soap:Envelope>

[swenkeratmicrosoft]

@Murmur

According to the trace provided, the key system string being used to initialize PlayReady is com.microsoft.playready. That's both legacy AND software DRM. So, it appears that "the old protDataConfig dashjs trick to activate .recommendation systemDrm" is not working properly.

The key system string should be com.microsoft.playready.recommendation.3000 for HWDRM.

The license acquisition failure occurs because you're requesting an SL3000 license (HWDRM) when the client is running in SL2000 (SWDRM) mode.

Purely for troubleshooting HWDRM-specific issues, it may be easier to make yourself a private dash.js which simply hard-codes that key system string at the point of calling requestMediaKeySystemAccess, but that's your call.

Hope that helps,

-Sam Wenker with the Microsoft PlayReady team

[Murmur]

@swenkeratmicrosoft Ok strange must study this more did nighly build broke SL3000 dashsj config trick.

So we have the following drmSystem values, I am thinking about .recommendation | .recommendation.3000 flags how do things should go?

• com.microsoft.playready = legacy, software drm
• com.microsoft.playready.hardware = legacy, hardware drm
• com.microsoft.playready.recommendation = new, switch between sw drm and hw drm based on a videoRobustness/audioRobustness flags?
• com.microsoft.playready.recommendation.3000 = new, always hardware drm

Hardware drm supports the highest SL3000 security level keys.

[swenkeratmicrosoft]

@Murmur

Yes, that's correct.

Using com.microsoft.playready.recommendation with videoRobustness/audioRobustness is more explicit and more platform-agnostic. Specifying 3000 for video and 2000 audio effectively means "require hardware-backed security for video, but software-backed security for audio is OK".

The com.microsoft.playready.recommendation.3000 key system string is windows-specific (AFAIK). On Windows (ONLY), it implicitly means the exact same thing as 3000 for video and 2000 for audio. This is because hardware-backed security doesn't exist for audio on windows.

I have no idea what com.microsoft.playready.recommendation.3000 would mean on non-windows, if anything at all.

FWIW, on non-windows, hardware-backed security for audio technically exists on one or two platforms, but it's very rare. I'm not aware of any content provider that requires it. That might change in the future if hardware-backed security for audio becomes more common in the market.

Hope that helps,

-Sam Wenker with the Microsoft PlayReady team

[BucherTomas]

@swenkeratmicrosoft
I admit I'm still struggling with what I'm expected to get when querying the EME API in Edge. The aim is to see whether the hardware supports SL3000 type of licence or not.

I tested this on a notebook with a 6th generation of Intel processor and an Intel 620 GPU that should be SL2000 only based on commonly accessible information about minimum requirements for hardware-backed PlayReady playback with Intel GPU, e.g. 7th generation with Trusted Execution Environment (TEE) as the minimum.

The following query contents for com.microsoft.playready.recommendation keysystem via navigator.requestMediaKeySystemAccess() returned successful promise

{
    initDataTypes: ['cenc'],
    persistentState: 'required',
    distinctiveIdentifier: 'required',
    sessionTypes: ['temporary'],
    audioCapabilities: [
      {
        contentType: 'audio/mp4; codecs="mp4a.40.2"'
      }
    ],
    videoCapabilities: [
      {
        contentType: 'video/mp4; codecs="avc1.64001F"',
        robustness: '3000'
      }
    ]
}

My expectation was that it shouldn't. In fact, if I changed robustness to a random string (while I assume the only valid ones are 150, 2000 and 3000), the promise was still successful as opposed to Widevine keysystem where if I change robustness to some random string, the promise fails as I'd expect. If I change keysystem to com.microsoft.playready.recommendation.3000, the promise is successful as well.

Media Foundation Rendering Capabilities section in edge://gpu does state on my notebook that PlayReady Hardware DRM disabled: false, though.

I guess the system thinks it is capable of processing SL3000 licenses? Does or does not the system need to provide TEE for hardware-backed PlayReady then? Does it fall to TPM in that case?

Is it actually correct that PlayReady CDM does not validate supported values in robustness?

And just to make sure, is it reliable that genuine legacy SL2000 device + robustness 3000 in navigator.requestMediaKeySystemAccess() should fail in the promise as Widevine CDM does with HW_SECURE_DECODE robustness on SW_SECURE_DECODE-capable device?

Thank you for shedding more light on these questions.

[swenkeratmicrosoft]

Due to an Edge bug that they have not prioritized, the "robustness" string is somewhat unreliable. Instead, use com.microsoft.playready.recommendation.3000 on Windows Edge.

The hardware you are using has a TEE with hardware-backed playready and can currently process SL 3000 licenses, so the promise is expected to succeed on it. The promise is expected to fail on a system without it. The request for PlayReady HWDRM support using com.microsoft.playready.recommendation.3000 is expected to be reliable.

The WideVine CDM makes different decisions than PlayReady to determine support for HW_SECURE_DECODE, so they may return success while PlayReady returns failure or vice-versa even on the same machine.

Furthermore, whether you get success or failure may change in the future if the system state changes (e.g. windows update, updated driver, updated browser, etc) or even because there's a bug in the firmware or driver which makes HWDRM unreliable. The success/failure state is always based on the current system state, not just on the physical hardware.

In other words, you should consider the results of the specific query being used to always be more accurate than any publicly available information.

If you'd like to provide me with a trace using the following instructions, I'm happy to look at it to be absolutely certain that you are getting expected behavior on your system. Here are the instructions:

• Reboot your machine.
• Download the following zip file and unzip it:
  https://github.com/microsoft/media-foundation/releases/download/V1/mftracelog.zip
• Launch mftracelog.exe from the appropriate architecture directory.
• Select "Simple" and "Full Traces". (This is NOT the default.)
• Click "start tracing"
• Launch the web browser in question and reproduce the behavior.
• Click "stop tracing"
• Zip the resultant files and share them with me, e.g. using OneDrive.

Out of curiosity, have you attempted the PlayReady WWA JS Sample application from the Microsoft Store with one of the pieces of content that uses SL 3000?

Finally, whether any specific website or application chooses to use HWDRM, regardless of support, varies widely. Some do additional checks before deciding whether to use HWDRM; others never use it no matter what.

Hope that helps,

-Sam Wenker with the Microsoft PlayReady team

[BucherTomas]

@swenkeratmicrosoft
Thank you for the detailed explanation and for the suggestion to compare the behavior with the PlayReady WWA JS Sample app, honestly it doesn't bring complete clarity to the problem.

As I don't have at my hand a player yet that would correctly handle the required keysystem, here https://devs.origin.cdn.cra.cz/log/mftracelog.zip is a trace from me running just the com.microsoft.playready.recommendation.3000 against navigator.requestMediaKeySystemAccess(), which returns successful promise. Peeking at the generated etl file, I'm seeing just com.microsoft.playready.hardware listed, so hopefully it's going to be sufficient for your analysis.
This was obtained on a desktop machine with a Skylake-gen Intel CPU (so similar to my previously described notebook) and a Pascal-gen Nvidia GPU with fairly recent drivers. Edge://gpu here also states that HW PlayReady is not being blocked. Since the promise was successful and based on what you've explained, I'd think that SL3000 license would be usable.

However, setting the license in the PlayReady sample app on that machine to 3000, setting the "Turn on HWDRM" checkbox to enabled (the log in the app even confirmed that HWDRM is being used) and testing a couple of encrypted streams there resulted in playback failures. By changing the license back to 2000, all streams became immediately playable again.

We thought of using the query result to find and leverage the keysystem with highest security available on given system to set the player environment to com.microsoft.playready.recommendation.3000 keysystem for any license type including SL3000 if the hardware supports it, com.microsoft.playready.recommendation keysystem for hardware unable to support SL3000 license and filter out tracks from the stream that require this license. And as a last resort set com.microsoft.playready anywhere else where neither are supported.

This test doesn't prove that this approach is usable if the query provides different hints than what would actually happen later with a real PlayReady license.

What are your thoughts about this, please?

[swenkeratmicrosoft]

@BucherTomas According to the trace, you are not passing com.microsoft.playready.recommendation.3000 into RMKSA. You are passing com.microsoft.playready.hardware.

Could you send me a sample webpage that I can visit in Edge that reproduces the problem?

[BucherTomas]

@swenkeratmicrosoft this is what I tested with https://devs.origin.cdn.cra.cz/play/persistentstatepr3000.html

[swenkeratmicrosoft]

@BucherTomas - Your source code is incorrect. RMKSA should return the expected failed promise with fixed source code.

Your source code:

navigator.requestMediaKeySystemAccess('com.microsoft.playready.recommendation.3000', configs).then(
  function (access) {
    return access.createMediaKeys();
  }).then(
    function (mediaKeys) {
      log("Created cdm.");
    },
    function (ex) {
      log("Failed to create cdm; " + ex);
    }
  );

Fixed source code:

navigator.requestMediaKeySystemAccess('com.microsoft.playready.recommendation.3000', configs).then(
    function (access) {
        access.createMediaKeys().then(
            function (mediaKeys) {
                log("Created cdm.");
            },
            function (ex) {
                log("Failed to create cdm; " + ex);
            }
        )
    },
    function (ex) {
        log("Failed to RMKSA; " + ex);
    });

Every time you have a "then", you should have two functions, one for success and one for failure. If you only have one function, it always enters it even on failure.

[BucherTomas]

@swenkeratmicrosoft Thank you for the correction, I've updated the original test url.

The promise result ("Created cdm" log) is still the same on the same machine, though, it doesn't fail.

It does fail correctly when I connect to the machine via remote desktop and therefore lowering security level but it was doing that even with the original script as it logged the error on the createMediaKeys level before, but the same error message "Unsupported keySystem or supportedConfigurations" is shown in that case.

Unfortunately, I still haven't once and for all verified whether this sort of check is reliable since playback with a SL3000 license is impossible on this machine.

Do you perhaps see other result on your end when using our or similar test url on older hardware?

[swenkeratmicrosoft]

@BucherTomas

The answer is no, we've never seen this behavior on any hardware nor have we had it reported internally or externally in the past. Ok. The next step is to figure out whether sl3000 is actually supported on the machine but you're getting an unrelated error when attempting playback with the PlayReady sample app. Could you follow the tracing instructions previously provided and attempt playback of content #6 (H264_VideoOnly_1080p) in the WWA JS Sample and share the result? (Obviously, "Launch the web browser" would be replaced with "Launch PlayReady WWA JS Sample, check the Turn on HWDRM box, select content #6, and click Play").

Thanks,

-Sam Wenker with the Microsoft PlayReady team

[BucherTomas]

@swenkeratmicrosoft

Thank you for the guidelines. I think we're getting somewhere.

There was an error on my side where I somehow forgot that audio track doesn't support SL3000 and I tested wrongly in the WWA JS sample app CENC streams including audio. However, the available license does not take that into account as both video and audio are either encrypted with the same key so the same rules apply for that given KID or they are not but the license url cannot be modified in the app to reflect that.

If I do test solely with video-only streams then yes, I can play them at SL3000 level. Good! This is finally aligning for me with what the RMKSA query reports.

If I may take this opportunity, let me run the following by you:

1. we query the support for com.microsoft.recommendation.3000, the promise is succesful
2. we serve to such a system a stream with 3 KIDs
3. we provide PlayReady license(s) requiring SL3000 restriction for the HD KID and for the other two KIDs (one for audio track) just regular SL2000 restriction

Everything should be accepted here and playable under that keysystem, is that correct?

As I said before, in systems not supporting com.microsoft.recommendation.3000 we'll need to filter out in our player those tracks from the stream incompatible with system requirements in the license. And the same is true in general, not just if the keysystem is unsupported.

For the sake of completeness, here https://devs.origin.cdn.cra.cz/log/mftracelogsl3000.zip is the mftracelog from the session with successful SL3000 playback on my machine in the WWA JS sample app. I'm not seeing any keysystem listed in it, though, but maybe I'm looking in wrong places.

Thank you again.

[swenkeratmicrosoft]

@BucherTomas

Everything you said is correct and is exactly how we designed SL3000 scenarios to work end-to-end.

I've also confirmed with the provided trace that HWDRM is actually being used with an SL3000 license.

One last thing to keep in mind: You will not actually get SL3000 security unless the actual AES content keys used to encrypt the content are different between streams (not just the KID). It's technically possible for a license server to issue licenses with different KIDs with the same content key (where the streams are encrypted with that same key). If you do that, you are effectively downgrading all streams to SL2000 security for all streams even though you are issuing an SL3000 license for one of them.

I'm glad I was able to help, and feel free to reach out with any future questions or concerns.

Regards,

-Sam Wenker with the Microsoft PlayReady team