Dash.js: No support of persistency on Edge

[qchroman]

Good day ladies and gentlemen!

Noticed one interesting thing, for some reason, there is no persistency on Edge although same setup works great on IE.

I've been testing with this page - https://test.playready.microsoft.com/Tool/PlayerHAS.

First, I have tested by opening the above page in Edge directly and entering the following to make two tests:

https://test.playready.microsoft.com/smoothstreaming/SSWSS720H264PR/SuperSpeedway_720.ism/Manifest
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(persist:true)

https://test.playready.microsoft.com/smoothstreaming/SSWSS720H264PR/SuperSpeedway_720.ism/Manifest
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(persist:true,firstexp:30)

First gives a persistent license and further page refreshes and clicks on a Play button start the playback w/o requesting a license. I then cleared media licenses and tried second test. I received a license for 30 seconds.

I then tried the above in dash.js 2.7.0 + mss plugin and they failed. I saw license request being made every time. As I have mentioned, same works fine in IE.

I thought it may be because of MSS format and tried with DASH here ():

https://profficialsite.origin.mediaservices.windows.net/c51358ea-9a5e-4322-8951-897d640fdfd7/tearsofsteel_4k.ism/manifest(format=mpd-time-csf)
https://playready-testserver.azurewebsites.net/rightsmanager.asmx?PlayRight=1&UseSimpleNonPersistentLicense=0

https://profficialsite.origin.mediaservices.windows.net/c51358ea-9a5e-4322-8951-897d640fdfd7/tearsofsteel_4k.ism/manifest(format=mpd-time-csf)
https://playready-testserver.azurewebsites.net/rightsmanager.asmx?PlayRight=1&UseSimpleNonPersistentLicense=0&FirstPlayExpiration=30

But it failed again in Edge.

IE: 11.112.17134.0 / 11.0.70 (KB4230450)
Edge: 42.17134.1.0 / 17.17134

I may be missing something. Or, may be, something needs to be set in a player? I see that MSS uses hasplayer.js under the hood. May be it supports something dash.js doesn't?

I presume CDM already supports it and its the matter of setting a valid flag, or is it only the case with widevine?

Thank you in advance.

BR

[RolandLeFranc]

Microsoft Edge as all Windows 10 applications has support for persistent licenses.

A test using the PlayReady public test server available here http://test.playready.microsoft.com/Tool/PlayerHAS can demonstrate it.

If you experience a particular player systematically requesting a new license when trying to play back content for which a previous license has already been acquired, it could be an issue with this specific player. For example, the player may have logic to proactively require a license whenever playback is started.

We'll contribute to determine the root cause of the issue you're seeing.
-Roland Le Franc with the Microsoft PlayReady team

[qchroman]

@RolandLeFranc, that's exactly why I opened this ticket.

Seeing that MS test player supports persistency and it is a hasplayer which is based on the dash.js player, I thought I would open an issue here asking dash.js community about what I may be missing in my setup and/or what is required for the dash.js to support persistency on Edge.

[qchroman]

@RolandLeFranc, also, thank you for being responsive about this, I really appreciate your help on this question.

[bbert]

Hi,
AFAIK Edge support persistence license but only with PlayReady CDM which is available through MS-prefixed EME API, that is through ProtectionModel_3Feb2014.
MS-prefixed PlayReady CDM is available on IE11 and Edge, but on Edge since both EME versions (3Feb2014 and 21Jan2015) are available, the ProtectionModel_21Jan2015 is used by default.
You can have a look at issue #2478 where I described how to force selecting ProtectionModel_3Feb2014 and then MS-prefixed API without modifying dash.js.
At application level you can try this (disable 21Jan2015 API when MS-prefixed API is available):

if (HTMLVideoElement.prototype.msSetMediaKeys) {
    navigator.requestMediaKeySystemAccess = undefined;
    HTMLVideoElement.prototype.setMediaKeys = undefined;
}

[qchroman]

That's interesting. I will try this today and let you know my results. I thought that unprefixed EME is something newer that should have been implemented by all and should also support persistency through sessionType.

So, If I understand this correctly, if Edge will decide to move away from prefixed API, the persistency will be lost for it? They would need to implement

[qchroman]

Alrighty, doing

if (HTMLVideoElement.prototype.msSetMediaKeys) {
    navigator.requestMediaKeySystemAccess = undefined;
    HTMLVideoElement.prototype.setMediaKeys = undefined;
}

didn't help. The dash.js was still selecting the 2015 model because of this inside the protection.js:

if ((!videoElement || videoElement.onencrypted !== undefined) && (!videoElement || videoElement.mediaKeys !== undefined)) {
...

The first if was failing because the onencrypted and mediaKeys were null. After changing to this

if ((!videoElement || videoElement.onencrypted) && (!videoElement || videoElement.mediaKeys)) {
...

I did get the 2014 model detection and playback on Edge and persistency was there. But, after removing your hack and leaving my code as mentioned above, the player was failing with "Object doesn't support property or method 'isTypeSupported'" error. So, I broke it :) Changing IF block places as mentioned in https://github.com/Dash-Industry-Forum/dash.js/issues/2478 helped, but you didn't comment on their questions, so I'm not sure this is the correct way:

Q1) if we change the order of IF blocks, will there be any impact ? i haven't noticed any.
Q2) is the current order of the IF blocks as per design?

Do you have any suggestion on how to force the prefixed API? If no, I will figure something out. Also, please, if you have something to say about my previous assumption, it would be interesting to listen your thought.

Thank you again for your help.

[swenkeratmicrosoft]

Both prefixed and unprefixed fully support persistent licenses. There is no need to force one or the other for your scenario.

The root cause is actually a bug (or intentional feature?) in dash.js in ProtectionModel_21Jan2015.

After creating the key session, the dasj.hs code for this protection model immediately, explicitly, and invariably starts license acquisition. This means it will acquire a license every time even if a persistent license is available.

src\streaming\protection\models\ProtectionModel_21Jan2015.js
function: createKeySession
calls: session.generateRequest

To correctly support persistent licenses, dash.js would need to change to properly request a license only when required as defined by the EME spec.

I hope this helps.

-Sam Wenker with the Microsoft PlayReady team

[bbert]

In ProtectionModel_21Jan2015, indeed we create a key session and then start license acquisition since no MediaKeySession id is provided.
The way to take benefit of persistent license, according to EME spec, would consist in setting MediaKeySystemConfiguration with sessionTypes set to 'persistent-license'. Then once license has been acquired a first time, the MediaKeySession has to be recorded at application level and then reused afterwards in order to (re)open the corresponding MediaKeySession.
That's the way it has been implemented for Widevine CDM (see PR #2451).

I also tested to reopen a PlayReady stream without creating the MediaKeySession. But unsuccessfully, no playback started.

Do we miss something? Can you propose a scenario for which we can inforce persistent license with PlayReady CDM and ProtectionModel_21Jan2015?

[swenkeratmicrosoft]

Similar to Widevine, you do need to reopen the MediaKeySession using the ID of the MediaKeySession on which you originally acquired a license. If you do so but either the Load method fails or playback fails to start, can you send me a link to a public webpage that reproduces the problem? I'll be happy to dig in further to see why the acquired persistent license is not being used for playback. (Of note, the license acquired by the existing dash.js code can be persistent and I've confirmed that it stores a persistent license successfully - the problem is in it reacquiring it and using a new one rather than using the existing one on disk.)

-Sam Wenker with the Microsoft PlayReady team

[bbert]

Please check and try this branch: https://github.com/Orange-OpenSource/dash.js/tree/playready-persistence
Using sample dash-if-reference-player, it tries to reload a MediaKeySession with ID of the session with which the license has been originally acquired.
But then we get an "InvalidAccessError"
Steps to reproduce:
1- load a stream with PlayReady license
2- stop the stream
3- reload the stream (without reloading the page)

[swenkeratmicrosoft]

I'm having trouble reproducing the InvalidAccessError.

Here are the steps I performed.

1. Stand up the sample player using the branch bbert referenced in his last post.
2. Run sample player. Show Options and set DRM KeySystem to com.microsoft.playready.
3. Uncheck "loop".
4. Set content file and license URL to a protected piece of content and a license acquisition URL that yields a persistent license.
5. Click Load. A persistent license is acquired and playback begins successfully.
6. Wait for playback to complete. The content is less than 15 seconds long.
7. Click Load. Playback begins successfully without acquiring a new license.
8. While playback is still running, click Load. Playback restarts successfully without acquiring a new license.
9. While playback is still running, check Loop. At end of playback, playback restarts successfully without acquiring a new license.

Could you provide me with the specific steps you went through using the sample application that led you to the InvalidAccessError (including the content url and license acquisition url)?

Thanks,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

Hi,

you can test the branch https://github.com/Orange-OpenSource/dash.js/tree/playready-persistence here: http://orange-opensource.github.io/dash.js/samples/dash-if-reference-player/index.html

I have also published a screen capture illustrating the InvalidAccessError: http://orange-opensource.github.io/dash.js/edge-persistence.mp4

I have used the smoth streaming test stream SuperSpeedway (http://playready.directtaps.net/smoothstreaming/SSWSS720H264PR/SuperSpeedway_720.ism/Manifest) since I know its license is persistent on IE11.

(please note that stream video is not displayed in the screen capture since it is protected, but I could see the video when making the capture)

[swenkeratmicrosoft]

The MediaKeySessionType being passed to MediaKeys.createSession is "temporary" (or is not being passed - it defaults to "temporary" if not specified).

For more information:
http://www.w3.org/TR/encrypted-media/#dom-mediakeysessiontype

Try changing the code to pass "persistent-license" to MediaKeys.createSession (on all calls). Does that resolve the issue?

Thanks,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

I have already tested, I forgot to mention this, but when we try to create session with 'persistent-license' session types, then we get a "Not supported error".

I have update the sample (http://orange-opensource.github.io/dash.js/samples/dash-if-reference-player/index.html) so that you can test. Please use stream from the list "Smooth Steraming > Super Speedway + PlayReady DRM"

[swenkeratmicrosoft]

Ok, after some investigation, I've found that PlayReady EME on Windows does not officially support persistent licenses when using the (legacy) com.microsoft.playready key system string. In order to use persistent licenses in Edge, the keysystem string "com.microsoft.playready.recommendation" must be used.

Of note, the "...recommendation" key system string will also yield a CDM implementation which much more closely conforms to the current EME spec in general, e.g. conformant error handling.

What are the results if you change your keysystem string to "com.microsoft.playready.recommendation" (for Edge)? Note: IF any non-spec-conformant code was written in dash.js to interoperate with Edge + com.microsoft.playready in particular (due to non-spec-conformant behavior in the CDM that is returned when using com.microsoft.playready is used), those workaround (if any) should be removed.

Thanks,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

!?! Where this "com.microsoft.playready.recommendation" key system is officialy documented?
I haven't found any reference to this key system string on the web!
How can we know about this?

I tried and then yes it works with dash.js. You can check here: http://orange-opensource.github.io/dash.js/samples/dash-if-reference-player/index.html

Why this CDM implementation is not used by default in Edge when using 'com.microsoft.playready' key system string?

[bbert]

BTW, how can we support CustomData with non-prefixed EME versions on Edge?
There was an issue on this topic (#876), but the solution at that time was similar, i.e. using MS-prefixed version of EME.

[swenkeratmicrosoft]

Regarding documentation: To be honest, I was not aware that this keysystem string was undocumented. :) I will investigate why that is the case and what plans for documentation exist.

Regarding the default key system string: Short answer: backward compatibility. Long answer: There are a large number of existing websites that use the com.microsoft.playready key system string and have javascript code which depends on its pre-existing behavior (which does not conform to the W3C Recommendation - it was implemented before said spec was finalized). Microsoft did not want to cause all of those websites to stop functioning by changing the behavior of that existing key system string out from under them. Thus, the com.microsoft.playready.recommendation key system string was introduced to explicitly indicate that it conforms to the W3C Recommendation (18 September 2017) version of the EME spec.

Regarding CustomData: Unfortunately, the final W3C Recommendation for EME explicitly prevents a CDM from supporting anything resembling custom data. Specifically, the Initialization Data definition includes the sentence "Initialization Data MUST be a fixed value for a given set of stream(s) or media data" as shown here:
http://www.w3.org/TR/2017/REC-encrypted-media-20170918/#definitions
Thus, com.microsoft.playready.recommendation does not support custom data. Microsoft recommends using other means to pass additional data to the PlayReady license acquisition server, such as adding HTTP headers to the request or using a different license acquisition URL (e.g. by adding a query string).

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

Can you provide the implementation differences regarding EME spec between the two key systems?

As you may know, most of websites already use some polyfills to manage different EME implementations in the different browsers. For example we have to use polyfill for the same key system com.microsoft.playready to handle EME differences between IE11 and Edge.
So in my opinion, it would be more relevant to update default EME implementation in Edge, as other browsers do.

[bbert]

Thanks for your answer regarding CustomData, I do agree with the recommendation to pass this custom data to the licenser server using other means.

[qchroman]

Good morning, gentleman!

First of all, I want to thank you for working on this issue, for valuable comments and for digging so deep that undocumented features were revealed :)

I wanted to understand what are next steps for dash.js team. @bbert , are you going to update the player to allow saving and loading the session as you did for Widevine, or do you have something else in mind?

Thank you.

[bbert]

Waiting for documentation to deeply understand the differences between the key systems.

But I would say that the solution would simply consist, in ProtectionModel_21Jan2015, in requesting key system access with system string 'com.microsoft.playready.recommendation' when key system is PlayReady.
But the question is: how to ensure backward compatibility with browsers that support ProtectionModel_21Jan2015 EME API and that provide a PlayReady CDM that do not support 'com.microsoft.playready.recommendation' key system string?
Let's see.

[swenkeratmicrosoft]

Regarding public documentation: The Microsoft PlayReady team is working with the Microsoft Edge team to add documentation for the com.microsoft.playready.recommendation key system string. While I don't have a specific timeframe for when this documentation will become available, it will be found on the following site when it does. It is expected that both a blog post and more detailed documentation related to EME will be added (though perhaps not simultaneously) - you can watch for both to become available here: https://docs.microsoft.com/en-us/microsoft-edge/

Regarding differences between the key system strings: Here are the most significant differences between the two of which I'm aware.

com.microsoft.playready.recommendation

Conformance to the W3C EME spec (W3C Recommendation 18 September 2017) is asserted.
Spec: http://www.w3.org/TR/2017/REC-encrypted-media-20170918/
Bugs relating to spec conformance are likely to be fixed.
Bugs not relating to spec conformance are more likely to be fixed.
Persistent licenses are supported.

--- versus ---

com.microsoft.playready

Conformance to the W3C EME spec is NOT asserted. In fact, it is known to be NON-conformant.
Bugs relating to spec conformance are highly unlikely to be fixed to avoid breaking compatibility with existing websites.
Bugs not relating to spec conformance are less likely to be fixed (excluding security bugs).
Persistent licenses are NOT supported.

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

Hello @swenkeratmicrosoft,
Thanks for your feedback.

Another question: is the uuid for 'com.microsoft.playready.recommendation' key system the same as for the 'com.microsoft.playready' key system?

While thinking how to manage the two key systems in dash.js, the solution that I retained is (in ProtectionModel_21Jan2015) to request access to key system 'com.microsoft.playready.recommendation':

• if original key system declared in manifest (and/or protData) is 'com.microsoft.playready'
• AND if MediaKeySystemConfiguration has persistentState set to 'required'

Please check PR #2714 in which I integrated this solution.
The only stream I found that supports persistence is the smooth streaming test stream "SuperSpeedway + PlayReady DRM" (you need to include mss package in your sample page to test it).
I tried some existing DASH streams but I always get the MEDIA_ERR_ENCRYPTED. @swenkeratmicrosoft do you have some DASH+PLAYREADY tests streams that support persistence?

@qchroman Please note that as for widevine you need to implement sessions id storage at application level in order to reload persistent sessions.
Please note also that thanks to PR #2665, you will be able to have MediaKeySessions persistence during the MediaPlayer lifetime.

[swenkeratmicrosoft]

I'm afraid I don't know what you mean by "uuid" for a key system - e.g. I don't see anything in the EME spec regarding a uuid. Could you provide more information?

Regarding additional test content: The PlayReady Test Server allows you to acquire a license for any correctly-formatted content as long as you know the content key. Here's a sample license acquisition URL.

http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(persist:true,contentkey:5B_7D_5B_7D_5B_7D_5B_7D_5B_7D_5B_7D_5B_7D_5B_7D)

The "persist:true," sub-string indicates that you want a persistent license - ommitting it will acquire a non-persistent license instead.
The "contentkey:..." portion indicates the 16 byte AES content key in hex format.

The test server supports quite a few additional properties as well (e.g. you can set the expiration date on the license). For more information, refer to the following link.

http://test.playready.microsoft.com/Server/ServiceQueryStringSyntax

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

for uuid and schemeIdUri please check this page: https://dashif.org/identifiers/protection/

[swenkeratmicrosoft]

Ah, you meant regarding the Dash Industry Forum. That makes sense to me now. :)

Yes, everything from that standpoint is the same for 'com.microsoft.playready.recommendation' versus 'com.microsoft.playready'.

-Sam Wenker with the Microsoft PlayReady team

[karlg-arris]

@swenkeratmicrosoft

There is also a key system available on some devices - 'com.microsoft.playready.hardware' that enables SL3000 support.

Is there a similar update there (e.g. 'com.microsoft.playready.hardwarerecommendation' ) so that latest EME and SL3000 can be supported?

[swenkeratmicrosoft]

Yes. For com.microsoft.playready.recommendation, you can request Hardware DRM (i.e. SL3000) as follows.

In any MediaKeySystemMediaCapability for a video codec for which you desire Hardware DRM (SL3000), simply specify robustness="3000", and the EME API in Edge will respond per spec based on whether it's supported for that codec.

https://www.w3.org/TR/encrypted-media/#dom-mediakeysystemmediacapability-robustness

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[karlg-arris]

@swenkeratmicrosoft

Thanks! Yes that helps a lot.

[qchroman]

Good day all,

I was just wondering about the process on this case on the dash.js side. Are there any drafts of implementing persistency for PR?

Thank you very much in advance.

[epiclabsDASH]

@qchroman, the only effort I am aware regarding persistency is the one @bbert (thanks!) did in the past. Any help, collaboration related with this topic would be appreciated.

[re-jim]

We just need streams/license servers that support persistence in order to validate the PR?

EZDRM have some publicly available:

asset: http://wvm.ezdrm.com/demo/stream.mpd
widevine license server: http://widevine-dash.ezdrm.com/proxy?pX=BF9CEB
playready license server: https://playready.ezdrm.com/cency/preauth.aspx?pX=3F3BB5

[swenkeratmicrosoft]

For PlayReady, we have a public test server for both content and licenses. I recommend using it. Here's a couple direct links to a variety of content including license acquisition URLs to use.

http://test.playready.microsoft.com/Content/Content2X
http://test.playready.microsoft.com/Content/Content3X

For license acquisition, simply changing the string "persist:false" to "persist:true" in the license acquisition URL listed at the top of the page will give you persistent licenses.

You can also use the server to get licenses with all sorts of other license properties, e.g. expiration dates. In fact, if you don't care about leaking the content key (i.e. it's test content), you can literally get a license for ANY PlayReady content from test.playready.microsoft.com by providing it the content key as part of the URL. Here is the full documentation, if you're interested.

http://test.playready.microsoft.com/Server/ServiceQueryStringSyntax

URLs for LA will always be formatted like the following where the "..." in parentheses is replaced with the syntax described on the above link.
http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(...)

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

I have updated PR #2714 to provide sample test streams that support licence persistency on Edge.

Before merging, we need to clarify some point:
@swenkeratmicrosoft, do you know if there is any difference in the EME API between the default supported version on Edge by dash.js, i.e. the one supported by the ProtectionModel_21Jan2015, and the one that conforms to the W3C Recommendation of 18 September 2017?

In order to ensure backward compatibility and in order to use by default the keysystem 'com.microsoft.playready.recommandation' on browsers that support it (i.e. that supports 18 September 2017 EME version), that would preferable to rely on the EME spec difference.
Instead of using 'com.microsoft.playready.recommandation' when persistentState is required as I did in PR #2714

[swenkeratmicrosoft]

The 'com.microsoft.playready.recommendation' conforms to the W3C Recommendation of 18 September 2017 and was never released without conforming to that spec. Any other key system string related to PlayReady does _not_ conform to that spec (and, in fact, has significant, incompatible differences). So, you can determine whether the ProtectionModel_21Jan2015 uses the spec-compliant EME implementation simply by looking at what key system string it uses.

I strongly recommend moving to 'com.microsoft.playready.recommendation' for all cases in the Edge browser if at all possible regardless of getting perfect compatibility; the old PlayReady key system string has known issues and bugs which will not be fixed, is non-spec-conformant, is not being updated with any new functionality, etc. If compatibility is critical, I suggest providing a way for a website to "opt-_out_" of com.microsoft.playready.recommendation so that all new websites will default to it - old websites can then take a trivial update to explicitly request the old keysystem string.

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

@swenkeratmicrosoft thanks for your response. I would agree to move to 'com.microsoft.playready.recommendation' for Edge, but the problem is that dash.js adapts to the available API but not to user agent. dash.js never checks user agent in source code.
Hence my question about a way to determine if 'com.microsoft.playready.recommendation' key system is available without checking for user agent.

A solution would consist in requesting key system access for both key system strings 'com.microsoft.playready.recommendation' and 'com.microsoft.playready' when PlayReady protection ('com.microsoft.playready') is signaled either in manifest and/or in initialization data/segment.

Any opinion?

[bbert]

@swenkeratmicrosoft actually, if "old PlayReady key system has known issues and bugs which will not be fixed, ...", then I would suggest that it is up to Edge browser to be updated so to that 'com.microsoft.playready' addresses the correct CDM that conforms to the spec.
If compatibility is critical for old websites, it is up to those websites to update to conform to spec.

Keeping compatibility for both key systems is not so easy and suitable regarding current players implementations.

[swenkeratmicrosoft]

@bbert

Unfortunately, changing com.microsoft.playready to conform to the spec would break Netflix, Amazon Prime, and numerous other major websites for _weeks_. The amount of code changes required to move key systems for those websites is _very_ significant. It is simply an untenable solution.

I would suggest the following:
If the manifest and/or init data segment requests com.microsoft.playready, check whether com.microsoft.playready.recommendation is available, use it if so, fallback to com.microsoft.playready otherwise. Then, allow the website to explicitly say "I want com.microsoft.playready even if .recommendation is available" so that legacy websites can opt-in.

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[bbert]

@swenkeratmicrosoft

_"Unfortunately, changing com.microsoft.playready to conform to the spec would break Netflix, Amazon Prime, and numerous other major websites for weeks."_
Have you communicated about the new CDM to these major companies so that they can prepare migration?

And this is the same for dash.js users. If we do propose using .recommendation key system we can not guarantee the proper functioning of dash.js with this new key system. Since we still don't know the differences in CDM implementations.

Regarding your suggestion: _"check whether com.microsoft.playready.recommendation is available, use it if so, fallback to com.microsoft.playready otherwise"_:
Checking wether com.microsoft.playready.recommendation can be achieved only in a asynchronous way (using requestMediaKeySystemAccess()), so this is not adapted.

The only acceptable solution for the time being, as a first step, is eventually to propose an API in dash.js to allow website to specify using .recommendation key system. Then it is up to website to check if .recommendation key system is available: "I want com.microsoft.playready.recommendation since I know it is available"

[swenkeratmicrosoft]

Yes, we've communicated the new CDM to the major companies so that they can migrate to it. TBH, we'd love to completely remove support for the old key system string if it were at all possible. Unfortunately, while we have excellent reasons for websites to migrate, those websites don't have real motivation - they say "our site works, why should we change?" So, we're in a catch-22 - we can't remove support without breaking the sites for our end-users, and they don't want to spend the money to move as long as they're not broken. We've been trying to encourage them by only adding new functionality for the new key system string (and intentionally _not_ fixing bugs in the old one), but it's slow-going.

-Sam Wenker with the Microsoft PlayReady team

[bbert]

OK. I am surprised that Netflix, Amazon and co don't want to spend the money to move towards new key system.
Anyway, as you said, we can encourage using new key system by putting forward its new functionalities, such as license persistency.
So, for the time being, I would keep integration of new .recommendation key system as I did in PR #2714:
"I want to use license persistency for PlayReady (on Edge browser):
=> then I set the sessionType to be "persistent-license" in input protection data for 'com.microsoft.playready' key system
=> then dash.js, if sessionType is set to "persistent-license", automatically use '.recommendation' key system (as we know that only this key system supports persistency)."

If everyone agree on that reasoning, we can merge PR #2714

[re-jim]

I agree (does my vote matter?)

[turbidwater]

Any update on this? I would love to see this issue resolved, especially if it is just waiting on a PR to be merged. Thanks!

[epiclabsDASH]

Already merged. Thank you very much everyone for the feedback and big thank you to @bbert for the implementation of persistency on Edge

[turbidwater]

Excellent! Thanks! We will check it out.