[eme] Four tests failing on Chrome with MSE-related uncaught InvalidStateError:

[ddorwin]

http://www.w3c-test.org/encrypted-media/clearkey-mp4-playback-temporary-clear-encrypted.html,
http://www.w3c-test.org/encrypted-media/clearkey-mp4-playback-temporary-encrypted-clear.html, and the drm- equivalents fail on Chrome 53 and 56 with:
Uncaught InvalidStateError: Failed to execute 'endOfStream' on 'MediaSource': The MediaSource's readyState is not 'open'.

There is another exception before that in the console that may be related:

clearkey-mp4-playback-temporary-encrypted-clear.html:1 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().
testmediasource.js:33 Uncaught InvalidStateError: Failed to execute 'endOfStream' on 'MediaSource': The MediaSource's readyState is not 'open'.endOfStream @ testmediasource.js:33

Firefox 49 passes the first test, but it's not clear that the test is correct.

/cc @mwatson2 @wolenetz @jdsmith3000

[mwatson2]

I believe Chrome dislikes the media and the media element and media source transition into a failed state.

So, the question is whether the media is non-compliant to the bytestream specification (and Firefox is just forgiving) or whether Chrome is failing on a compliant bytestream.

[ddorwin]

Chrome fails with "Video encryption changes not allowed" in chrome://media-internals/. These tests cover some of the scenarios in https://crbug.com/597443.

Firefox passes http://www.w3c-test.org/encrypted-media/clearkey-mp4-playback-temporary-clear-encrypted.html but fails http://www.w3c-test.org/encrypted-media/clearkey-mp4-playback-temporary-encrypted-clear.html. (The drm- results are the same). I'm surprised it isn't the other way around. The console output is:

Media resource mediasource:http://www.w3c-test.org/cfc61294-5f27-4eb2-b187-53b9409f7e3a could not be decoded.clearkey-mp4-playback-temporary-encrypted-clear.html
InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable
endOfStream()

These look like legitimate failures, for Chrome at least. However, we should try to report these transition failures with a clearer error message, especially since these failures may not be addressed in the near future.

[mwatson2]

Both of these are important use-cases where I think we should be clear about whether they are required to be supported or not in the specification. If we don't already have two passing implementations for (some form of) these use-cases, we need to mark as "feature-at-risk" in the new CR.

• Clear lead-in is often used for speeding up playback start.
• Clear content in the middle of playback is used for ad insertion.

I can improve the test failure behavior, but another question is whether different sequencing would cause these tests to pass on more browsers ? For example, does it make a difference if generateRequest is called before content is appended, to signal more clearly there will be encrypted content ? Or if the encrypted content Initialization Segment is appended first, before the clear content ?

[ddorwin]

Specifying this is tracked as w3c/encrypted-media#251. Ad insertion is probably the most relevant use case.

Clear lead-in can be implemented by not encrypting those frames within an "encrypted" stream. Chrome supports that fine. (If we don't have a test for this, we might want to add one, though this is more validation of proper handling of the container than EME.)

This test is using concatenated moov boxes, one encrypted and one unencrypted.

This is more complex for clients, which may need to enable a decrypting pipeline. Encrypted => unencrypted should be simpler for Chrome than the other direction, but we wanted to avoid inconsistent behavior. Another option would be to require, at least in the Unencrypted => encrypted case, that MediaKeys be attached before loading the source. This is one possible solution for w3c/encrypted-media#251.