RE: EME test status

> The following Pull Requests are open for review:
> - Persistent Usage Record DRM tests<https://github.com/w3c/web-platform-tests/pull/3478> - these pass on Edge with the polyfill
> - Persistent License Clear Key tests<https://github.com/w3c/web-platform-tests/pull/3424> - these pass on all browsers with (large) polyfill
> - KeyStatuses test<https://github.com/w3c/web-platform-tests/pull/3490>
> - Additional setMediaKeys tests<https://github.com/w3c/web-platform-tests/pull/3494>

Can someone please volunteer to review one or more of these EME test suite Pull Requests?  Our work on the MSE test suite was delayed significantly by lack of WPT PR reviews.  Let’s NOT have this happened again for EME!

> I am working on Persistent License DRM tests, which should be available shortly.

Mark:  Can you give us an update on when these additional tests will be available?

> There are some other tests in the Google directory, but there are Chromium-specific

Mark and David:  Can we please get agreement on exactly what tests are Chromium-specific and do NOT need to be migrated?  Mark:  Can you start a separate thread with the exact list of Chromium-specific tests?

/paulc

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, August 18, 2016 6:12 PM
To: public-html-media@w3.org
Subject: EME test status

All,

I have updated the test framework to support Microsoft PlayReady servers as well as the DRMToday server and also to support configuration of server certificates. The server to be used is configured in the scripts/drm-messagehandler.js (by commenting servers in/out).

At present, the persistent-usage-record tests (in the PR listed below) require one of the Microsoft servers to be used if you are testing PlayReady. We have access to a test version of the DRMToday servers which also support this, but I have not integrated that yet.

The keyStatuses test (in the PR listed below) requires the DRMToday server, because that test relies on getting a license response containing two keys. This happens based on configuration of the DRMToday, whereas for the Microsoft servers we can only supply a single content key in the request.

As I say, we may in due course be able to support all tests with the DRMToday server. If we end up needing different servers for different tests I will add support for configuring server capabilities and test requirements.

The following Pull Requests are open for review:
- Persistent Usage Record DRM tests<https://github.com/w3c/web-platform-tests/pull/3478> - these pass on Edge with the polyfill
- Persistent License Clear Key tests<https://github.com/w3c/web-platform-tests/pull/3424> - these pass on all browsers with (large) polyfill
- KeyStatuses test<https://github.com/w3c/web-platform-tests/pull/3490>
- Additional setMediaKeys tests<https://github.com/w3c/web-platform-tests/pull/3494>

I am working on Persistent License DRM tests, which should be available shortly.

Of the tests originally submitted by Google, the following remain to be migrated:
- encrypted-media-clear-key-invalid-license.html
- encrypted-media-clearkey-update-non-ascii-input.html
- encrypted-media-keystatuses-multiple-updates.html
- encrypted-media-onencrypted.html
- encrypted-media-playback-encrypted-and-clear-sources.html
- encrypted-media-playback-multiple-sessions.html
- encrypted-media-requestmediakeysystemaccess.html
- encrypted-media-reset-src-after-setmediakeys.html
- encrypted-media-session-closed-event.html
- encrypted-media-setmediakeys-again-after-playback.html
- encrypted-media-setmediakeys-again-after-resetting-src.html
- encrypted-media-setmediakeys-at-same-time.html
- encrypted-media-setmediakeys-multiple-times-with-different-mediakeys.html
- encrypted-media-setmediakeys-multiple-times-with-the-same-mediakeys.html
- encrypted-media-setmediakeys-to-multiple-video-elements.html
- encrypted-media-syntax.html
- encrypted-media-unique-origin.html
- encrypted-media-update-disallowed-input.html
- encrypted-media-waiting-for-a-key.html

(There are some other tests in the Google directory, but there are Chromium-specific).

...Mark