commercial DRM test coverage

[jpiesing]

This is my attempt to capture ideas on coverage of commercial DRM tests if WAVE would do these in 2024. I think there are several groups of possible tests.

1. Repetitions of existing tests but with encrypted content
   (Each of these would be repeated for each DRM system).

• 8.2 Sequential Track Playback and/or 8.12 Playback of Encrypted Content and/or 9.2 Regular Playback of a CMAF Presentation
• 8.3 Random Access to Fragment and 8.4 Random Access to Time and/or 9.3 Random Access of a WAVE Presentation)
• 8.5 Switching Set Playback (but perhaps with fewer Representations)
• 8.13 Restricted Splicing of Encrypted Content where the encrypted content is DRM protected
• 8.14 Sequential Playback of Encrypted and Non-Encrypted Baseline Content where the encrypted content is DRM protected (perhaps with a variation where this happens 5-10 times)

2. General DRM features
   (Each of these would be repeated for each DRM system as far as applicable)

• Key changes before the end of the content - there may be multiple variations on this, e.g. end of one content item and start of the next and/or a time-limited license expires
• Key change and a new license is obtained once
• Key change and a new license is obtained (both repeated at least 5-10 times)
• Key rotation (if different from the previous line)
• The EME update method to the extent it's not included in the key change tests above.
• Persistent (pre-loaded) licenses
• Encrypted video with unencrypted audio
• The EME Get Supported Configuration algorithm
• Multiple EME initialization segments (i.e. pssh boxes)

3. DRM system specific features
   3.1 PlayReady

• SL3000 for video (assuming repetitions of existing tests use SL2000)
• SL3000 for video and SL2000 for audio (repeated for both cenc and cbcs)
• MediaKeySystemMediaCapability.robustness
• Custom Data
• License server over-ride
  3.2 Widevine
• L1 for video (assuming repetitions of existing tests uses L3)
• L1 for video and L3 for audio
• to be completed
  3.3 FairPlay
• to be completed
  4 Errors
• License does not have the correct rights for the content
• Content is DRM protected but not by one of the supported ones on this implementation
• Content is protected by a supported DRM but no license is available
• License is available but has expired (depending on the DRM system, there may be more than one variation of 'expired', e.g. expires at an absolute (wall-clock) time+date and/or expires at a time relative to when the license was acquired
• License expires during playback (where expires may be an absolute time and/or a relative time as before)
• Video and audio have different KIDs and there's only a license for one of them

[dsilhavy]

Not sure if this is covered explicitly: The transition from unencrypted content to encrypted content is something that can cause problems. From my understanding, the MSE/EME stack needs to be initialized with an encrypted init segment first. Otherwise, the MSE needs to be reset prior to the transition.

[louaybassbouss]

Not sure if this is covered explicitly: The transition from unencrypted content to encrypted content is something that can cause problems. From my understanding, the MSE/EME stack needs to be initialized with an encrypted init segment first. Otherwise, the MSE needs to be reset prior to the transition.

@dsilhavy this is covered in the [8.14 sequential-playback-of-encrypted-and-non-encrypted-baseline-content](https://github.com/cta-wave/dpctf-tests?tab=readme-ov-file#templates) for use case: Main Content is encrypted, Ad Content unencrypted. There is a transition from encrypted to unencrypted and then another transition from unencrypted to encrypted.

[mbergman42]

Question, if we are to be supporting FairPlay/Widevine/Playready on behalf of industry, what support can we expect from the owners of those technologies? Can we get Google/MSFT/Apple SMEs involved, can they help cover development costs?

[jpiesing]

Here are a few comments from the discussion in the Fall Forum meeting.

1. What would we be testing & (perhaps more important, what would we not be testing). We would not be testing the implementation of EME or of any particular DRM system but the integration of the browser (i.e. the EME implementation) with the DRM system and the media playback feature of the host OS.
2. A de-facto common set of unit tests for integration of commercial DRM benefits the device manufacturer / implementer / integrator as well as content and app providers - although in the latter case, it's of less benefit to top tier app providers who are big enough to make & maintain their own unit tests for devices and require devices pass those tests as a condition for access to content.
3. The reality on DRM systems is that almost all media consumption devices (outside the Apple Ecosystem) support PlayReady and Widevine - although these are not always available to all applications. For example, a device may support Widevine only in the context of YouTube and not make it available via it's default browser for HTML5 apps. Companies that 10 years ago had their own DRM or pseudo-DRM may now also offer multi-DRM license serving. For example Intertrust offer ExpressPlay as a multi-DRM license serving product and Nagra offer "Multi-DRM" as a multi-DRM licensing serving product. If you look at https://www.ezdrm.com/new-compare-drms, the only additional DRM is the Huawei WisePlay - presumably a consequence of the US sanctions against them.
4. For a list of multi DRM service providers, see https://docs.unified-streaming.com/documentation/drm/drm-providers.html. A new entrant's barrier to entry is supporting a reasonable number of that list to support them. I may try and go through that list to list which DRMs are supported by each one.

[jpiesing]

Question, if we are to be supporting FairPlay/Widevine/Playready on behalf of industry, what support can we expect from the owners of those technologies? Can we get Google/MSFT/Apple SMEs involved, can they help cover development costs?

I think we can expect very little from the incumbent suppliers.

[jpiesing]

One of the discussion points in the fall forum meeting was about the choice and variety of DRM systems.
One way to get information on this without spending lots of money is to look at the multi-DRM vendors and what DRM systems they support. The attached spreadsheet contains a list of the multi-DRM vendors I could find and what I could find of the DRM systems they support. It contains links to the information used.

It is quite dramatic.

• The lists I found identified 19 multi-DRM service providers
• 3 may not exist any more or may exist under different names or may be duplicates due to M&A activity (Cisco/Synamedia, Conax part of Nagra, Vualto part of JW Player)
• One looks more like a streaming video app than a provider of services to such apps
• Everyone where I could find information supports PlayReady, Widevine and FairPlay.
• Excluding those 3, only 4 other DRMs were mentioned.
• 3 are part of groups / companies that have also have their own DRM and support that DRM (Intertrust ExpressPlay/Marlin, Nagra PRM, ViaAccess Orca DRM). These 3 DRMs are not supported by any other multi-DRM vendor.
• Huawei WisePlay was mentioned by 2 multi-DRM providers, this was the only DRM system other than the 3 incumbents supported by any multi-DRM vendor without some form of common ownership.

I'm happy to be corrected. Improvements welcome.

Analysis of DRM systems supported by Multi-DRM service providers 2024-10-04 (1).xlsx

IMHO this would justify any potential WAVE activity in this field focussing on the 3 DRM systems that are very widely supported.

[haudiobe]

TF Call:

• thank you - great info
• we have also some material in the survey @cta-source will share
• We keep this excel as record to justify that we focus on only the 3 DRM systems Fairplay, PlayReady and Widevine

[jpiesing]

Here is my attempt to identify what might be an inexpensive minimum step in this direction. I use EZDRM as an example.

1. Identify which existing tests and test content to clone for the first set of commercial DRM tests. It could be one, it could be all the ClearKey tests, it could be the list in my initial comment above. It could be something else. In order to simplify and keep costs down for the 1st step, I assume it's limited to 1) tests that only need one license request which is at the start and 2) tests which use one of the existing observations so no changes to the OF.
2. Modify the existing content packaging scripts to encrypt test content using commercial DRM. For EZDRM, this is a call to a web API to obtain the key(s) and then using that to encrypt the content. We already have the encryption piece for the ClearKey test content but not the web API call.
3. Modify dpctf-testharness.js to be able to request a key from EZDRM. This may mean modifying tests.json or test-config.json to include information needed for the key request, which may be information from the API call when the content was encrypted. All of this should be done in a way that makes it easy to add other multi-DRM service providers in the future.
4. Clone the existing HTML files under appropriate names for DRM encrypted content.
5. Create the actual tests by combining the cloned HTML files with the encrypted content
6. Test, test, test
7. Validate

[jpiesing]

We have the following tests for ClearKey encrypted content at the moment (only the locally hosted versions selected).

AVC video

• cfhd_14.985_29.97_59.94-local/playback-of-encrypted-content-https__t1-cenc.html
• cfhd_12.5_25_50-local/restricted-splicing-of-encrypted-content-https__splice_main-cenc_splice_ad-cenc.html
• cfhd_12.5_25_50-local/sequential-playback-of-encrypted-and-non-encrypted-baseline-content-https__splice_main-cenc_splice_ad.html
• cfhd_12.5_25_50-local/playback-of-encrypted-content-https__t1-cenc.html
• cfhd_15_30_60-local/playback-of-encrypted-content-https__t1-cenc.html

Audio

• caac_sets-local/sequential-playback-of-encrypted-and-non-encrypted-baseline-content-https__at15_at14.html
• caac_sets-local/restricted-splicing-of-encrypted-content-https__at15_at16.html
• caac_sets-local/playback-of-encrypted-content-https__at5.html

Looking at this, a simple starting point would be the AVC stream t1 in either the 25 or 30Hz variations. This could be used / cloned to produce the following streams;

• PlayReady SL2000
• PlayReady SL3000
• Widevine L1
• Widevine L3
• FairPlay
• PlayReady SL2000+Widevine (tbc L1 / L3)
• PlayReady SL2000+Widevine (tbc L1 / L3) + FairPlay

Each of these would be combined with modified versions of playback-of-encrypted-content-https__t1-cenc and dpctf-testharness.js to generate the same number of tests.

Obviously this can be reduced still further by deferring PlayReady SL3000 and Widevine L1 to later.

A slightly larger starting point would add clones of a few more of the tests listed in the first comment in this issue and encrypted audio.

[jpiesing]

Here is a TP Vision contribution to HbbTV that lists things to be tested which is also relevant here. Some of these may duplicate the above.

• Changing of initialization segments over time including changing between initialization segments that indicate encrypted media and ones that indicate non-encrypted media and vice-versa (see EME [] clause 7.5.2 "Initialization Data Encountered").
• Changing of KIDs
• Expiration of licenses (see MediaKeySession.expiration in EME[]).
• Where a DRM system supports persistent licenses, requesting these using a MediaKeys object with a MediaKeySessionType of "persistent-license" (see EME [] clause 5). The CDM shall not request a new license if it already has one that can be used to decrypt content to be played.
• Providing messages (including licenses) to the CDM ( see MediaKeySession.update() in EME[]).
• Requesting a supported key system configuration (see the Get Supported Configuration algorithm, clause 3.2.2.1 in EME []).

These test that various requirements of EME work however the way to test this (either code and/or encrypted streams) may be specific to a particular DRM system.