PlayReady SL3000 asset testing

[bobcampbell-resillion]

In testing instance *) there's test task "2.9 AVC 1080p video/License override method, SecurityLevel 3000"
*) https://refapp.hbbtv.org/testing/catalogue/index_mse-eme.php (MSE-EME)
*) https://refapp.hbbtv.org/testing/catalogue/index_html5.php (HTML5/HbbTV 2)

Testing the asset is on-going. No working combination has been found yet. Progress tracked in this ticket.

Not even Xbox One Browser worked. Exact version etc. information to be added

[jpiesing]

Some references ...

Microsoft documentation https://testweb.playready.microsoft.com/Tool/Hwdrm
Somewhat related discussion in dash.js Dash-Industry-Forum/dash.js#2658
Shaka player discussion on hardware DRM shaka-project/shaka-player#818

[jpiesing]

I half remember a discussion that the current content may not comply with this PlayReady requirement;

From https://docs.microsoft.com/en-US/windows/uwp/audio-video-camera/hardware-drm

[juhajoki]

yes, use of SL3000 is not applicable for audio.
I hacked a version with clear audio: https://refapp.hbbtv.org/videos/02_gran_dillama_1080p_25f75g6sv5/drm/manifest_playready-clearaudio.mpd
And added that as test 2.10 in the testing instance.

[vodlogic]

@juhajoki could you provide any update on the testing of SL3000 please? Did you manage to get any playback working with the clear audio?

[juhajoki]

After testing 19 recent platforms, we have 9 working platforms and 10 non-working ones.

[markriley9999]

Hi
i'm just sanity checking the SL3000 assets on an Edge browser and i'm seeing server 500 errors when requesting the licence, eg:
https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:header,sl:3000,persist:false,contentkey:EjQSNBI0EjQSNBI0EjQSNg==)
(i can play back the non SL3000 PR assets in the browser, and also the browser in question reports support of SL3000 via the https://testweb.playready.microsoft.com/Tool/Hwdrm page).

So i'm just trying to ascertain whether this service is still working?
many thanks!

[juhajoki]

Service is still running, I can open content in previously working devices. Configuring latest Edge for Playready playback, please refer to issue 38 comment thread: #38 (comment)

[Murmur]

Reference to dashjs-SL3000 ticket about the initialization of Playready versions (old legacy or new .recommendation stack).
Dash-Industry-Forum/dash.js#3852

[Murmur]

Refapp/staging: https://refapp.hbbtv.org/staging/
Playready(2) menu has a few Playready SecurityLevel contents, EME javascript interface call this as a Robustness flag.

2.9 AVC & 2.10 HEVC SL2000 uses a different KEYID+EncryptionKEY but both video and audio tracks are using a SL2000 laurl license request. This is a simple test to see if different KeyIDs worked at all, it's a known issue some hbbtv devices fail on two different KEYID+KEY values.

2.11, 2.12 & 2.13 SL3000 uses a different KEYID+EncryptionKEY, video SL3000 and audio SL2000 security level. This is a normal scenario following the Microsoft SL3000 specification.

2.14 & 2.15 PR.Rec is using a new systemId com.microsoft.playready.recommendation for MSEEME playback. This is mandatory for MSEdge(Win10) browser and recommended by Microsoft to be used on other platforms as well. It's up to a manufacturer recognize both com.microsoft.playready | com.microsoft.playready.recommendation systemIds and map to the same playready middleware kit.

MSEdge browser app maps com.microsoft.playready to a legacy playready which may not support latest features. Javascript EME apps on MSEdge browser should use com.microsoft.playready.recommendation for both SL2000 and SL3000 content.

[Murmur]

GoogleDocs table listing a support of Widevine and Playready security level on some browsers and hardwares.
https://docs.google.com/spreadsheets/d/1I67ZuuMb23iu0FcEN_DhIgbay2Vcbk4dySYitLSCzPo/edit#gid=0

disclaimer: table did not use a test content but details parsed from the capability API and manufacturer's specifications, still it does help understanding the aspect of security level.
author: Stefan Pham

[Murmur]

New Playready2/2.16 AVC 1080p SL2000 UTF-8 test to use playreadyMessageFormat=utf-8 format. Most devices use utf-16, default value in playready dashjs, but few may send utf8 byte buffers.

At the moment DashJS does not fallback to utf-8 if CDM messages failed on utf-16 mode.

This new test 2.16 can be used in MSE-EME mode to see if playready utf-8 works, rest of the playready tests are using a default utf-16 messages.

https://refapp.hbbtv.org/staging/

[bobcampbell-resillion]

IITF believes the asset testing on the zoo of devices is as complete as its going to be at this time, and the support for SL3000 assets is recorded in the latest spreadsheet. Any remaining or newly discovered issues with a content asset or app should be logged separately.

[Murmur]

Content must use a distinct KeyID+Encryptionkey pair for video(SL3000) and audio(SL2000) tracks. If content had a different KeyID but using the same encryption key then playready(Windows Edge implementation?) downgrades to SL2000 security level.

Dash-Industry-Forum/dash.js#3869 (reply in thread)
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. /Sam Wenker with the Microsoft PlayReady team

[Murmur]

Refapp Staging https://refapp.hbbtv.org/staging/catalogue/

Detailed information about the playready eme robustness flags to clarify tests.

2.11 AVC 1080p SL3000, use on hbbtv1+2+eme
Playready CENC video SL3000, audio SL2000, different KIDs
drmSysid: playready

• no robustness+persistentState+distinctiveIdentifier flags on EME
• its up to a device decide eme playready middleware flags
• hbbtv1+hbbtv2 does not support robustness flags
• this may not work on eme clients because no robustness flags

2.13 HEVC 2160p SL3000, use on hbbtv1+2+eme
Playready CENC video SL3000, audio SL2000, different KIDs, h265(720p,1080p,2160p)
drmSysid: playready

• no robustness+persistentState+distinctiveIdentifier flags on EME
• its up to a device decide eme playready middleware flags
• hbbtv1+hbbtv2 does not support robustness flags so nothing is given
• this may not work on eme clients because no robustness flags

2.14 HEVC SL2000 (PR.rec), use on EME
PR.recommendation video SL2000, audio SL2000, different KIDs, h265(720p,1080p,2160p)
drmSysid: playready.recommendation, fallback to a legacy playready name

• use robustness.video=2000, robustness.audio=2000 EME flags
• use persistentState=required, distinctiveIdentifier=required EME flags
• hbbtv1+hbbtv2 does not support robustness flags so nothing is given

2.15 HEVC SL3000 (PR.rec), use on EME
PR.recommendation video SL3000, audio SL2000, different KIDs, h265(720p,1080p,2160p
drmSysid: playready.recommendation, fallback to a legacy playready name

• use robustness.video=3000, robustness.audio=2000 EME flags
• use persistentState=required, distinctiveIdentifier=required EME flags
• hbbtv1+hbbtv2 does not support robustness flags so nothing is given

---
different KIDs = video and audio tracks are using the different KID+KEY pair.

Hbbtv1(oipfVideo) and hbbtv2(html5Video) modes always use a native player on all tests, even 2.14+2.15 PR.rec tests use a regular playready initialization on hbbtv player modes.

EME(mseVideo) mode can use two different drmSysid identifiers and Microsoft instructions goes like this (may apply on windows edge only):
com.microsoft.playready = legacy DRM, does not support SL3000 hw security, max is SL2000 level.
com.microsoft.playready.recommendation = new DRM supports SL3000 hw, preferred use on pr middleware.

HbbTV on EME mode may not recognize playready.recommendation identifier at all, RefappEME player fallbacks to an older playready identifier on 2.14+2.15 tests. TV may run SL3000 hw fine with a legacy drmsysid identifier.

Refapp uses robustness flags on MSEEME mode, this is mandatory to instruct drm middleware initializing a proper decode pipeline.

---
Playready SL3000(hardware,best)
WinEdge browser works if using EME sysId=com.microsoft.playready.recommendation, videoRobustness=3000, audioRobustness=2000 flag values. WinEdge does not playback SL3000 if robustness flags are not given.

HbbTV(refapp mseeme) EME implementation works if using EME sysId=com.microsoft.playready, no robustness flags flag values. HbbTV does not playback SL3000 if robustness flags are given.

WinEdge works with an additional persistentState=optional, distinctiveIdentifier=optional or persistentState=required, distinctiveIdentifier=required or no additional flags values.

HbbTV works with an additional persistentState=optional, distinctiveIdentifier=optional or no additional flags values but may fail on persistentState=required, distinctiveIdentifier=required values.

Install HEVC Video Extensions from WindowsAppsStore to playback HEVC+SL3000 on WinEdge browser, this works on Intel 7th generation(Kaby Lake) or newer systems.

[juhajoki]

@Murmur consider adding this to readme

[jpiesing]

@Murmur What about robustness and Widevine?

[Murmur]

@jpiesing Widevine SL1(hardware,best) is using the following widevine specific robustness values.
https://refapp.hbbtv.org/staging/catalogue/
WV.6 AVC 1080p SL1
widevine, CENC, video SL1(hardware,best), audio SL3(software), different KIDs for video and audio.

• use robustness.video=HW_SECURE_ALL, robustness.audio=SW_SECURE_CRYPTO EME flags
• use persistentState=optional, distinctiveIdentifier=optional EME flags
• hbbtv1+hbbtv2 native does not support robustness flags so nothing is given

Normal Widevine SL3(software) test would use robustness.video=SW_SECURE_DECODE, robustness.audio=SW_SECURE_CRYPTO EME flags. See here a little difference on video and audio flag.