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.