On a related note, we should specify what happens when:
A) video.setMediaKeys() is called and video.src is already set to a source that does not support EME.
B) An attempt is made to set video.src to a source that does not support EME when video.mediaKeys is already set.

For (A), we should probably add a step to the setMediaKeys() algorithm that throws NOT_SUPPORTED_ERR or INVALID_ACCESS_ERR if the user agent knows that the media loaded cannot be decrypted/used with EME.

For (B), I believe we would need to update the media element load algorithm [1]. However, this algorithm, nor many media element algorithms, throw exceptions.

Alternatively, we could just let things fail elsewhere. That's probably more acceptable if there is a clear way for applications to detect incompatibility (like #3 above).

[1] http://www.w3.org/TR/html5/embedded-content-0.html#media-element-load-algorithm

The changes for bug 25923, specifically MediaKeySystemOptions, enables a less-ugly version of option #3: We could add a sourceType member or something similar.

Ideally, applications should get the desired behavior by default, but that could be difficult unless we assume applications want MSE behavior by default. It might also require that sourceType be a list or that each source type have its own MediaKeysRequirement member in MediaKeySystemOptions.

We need to:
A) Decide whether this issue is worth addressing
B) If so, determine how to address it.
C) Define the behavior of setting .src and calling setMediaKeys() when the combination is not supported (see comment #1).

(In reply to David Dorwin from comment #3)
> We need to:
> A) Decide whether this issue is worth addressing

I think this is worth addressing. This would make for less surprising behavior when using EME I think.

> B) If so, determine how to address it.
> C) Define the behavior of setting .src and calling setMediaKeys() when the
> combination is not supported (see comment #1).

For when video.setMediaKeys() is called and video.src is already set to a source that does not support EME, sending NOT_SUPPORTED_ERR makes sense to me.

For when an attempt is made to set video.src to a source that does not support EME when video.mediaKeys is already set: I think when video.src is set, we should always clear the current mediaKeys (and fire the close() event if we end up doing that).

(In reply to Joe Steele from comment #4)

> For when an attempt is made to set video.src to a source that does not
> support EME when video.mediaKeys is already set: I think when video.src is
> set, we should always clear the current mediaKeys (and fire the close()
> event if we end up doing that).

Are you saying setting video.src ALWAYS clears mediaKeys or only when EME is not supported? The former is not an option - this is an expected pattern. For the latter, I think it's inappropriate for setting one attribute to change another.

Ideally, we'd throw an exception in response to "video.src = <URL>", but it's not clear how we can do that. (See comment #1.)

(In reply to David Dorwin from comment #5)
> (In reply to Joe Steele from comment #4)
> 
> > For when an attempt is made to set video.src to a source that does not
> > support EME when video.mediaKeys is already set: I think when video.src is
> > set, we should always clear the current mediaKeys (and fire the close()
> > event if we end up doing that).
> 
> Are you saying setting video.src ALWAYS clears mediaKeys or only when EME is
> not supported? The former is not an option - this is an expected pattern.

I am saying setting the video.src member would automatically clear the video.mediakeys element. Regardless of the source.

> For the latter, I think it's inappropriate for setting one attribute to
> change another.

Ok, fair enough. It would be unusual agreed - but we could give guidelines. 

> Ideally, we'd throw an exception in response to "video.src = <URL>", but
> it's not clear how we can do that. (See comment #1.)

If we don't throw exceptions - what happens when we try to play?
* I would expect that content that is unencrypted will just play and the UA will ignore _mediakeys_ if set.
* I would expect that content that is encrypted will try to play, but with no usable key ids available to decrypt, the browser will fail with MEDIA_ERR_DECODE. 

Both of those seem like reasonable behaviors. Would this work for your implementation?

Firefox's implementation can handle EME in src=foo.mp4 and in MSE video. We're planning on shipping support for both, though we expect EME to mostly be used with MSE.

I'm not opposed to making whether EME works in MSE or in src= URLs discoverable. Maybe MediaKeySystemOptions.audioCapability = "mse,src"?

(In reply to David Dorwin from comment #2)
> The changes for bug 25923, specifically MediaKeySystemOptions, enables a
> less-ugly version of option #3: We could add a sourceType member or
> something similar.
> 
> Ideally, applications should get the desired behavior by default, but that
> could be difficult unless we assume applications want MSE behavior by
> default. It might also require that sourceType be a list or that each source
> type have its own MediaKeysRequirement member in MediaKeySystemOptions.

Below is a specific proposal for adding differentiation of MSE and traditional sources to MediaKeySystemConfiguration [1]

enum MediaSourceType { "mse", "url" };
dictionary MediaKeySystemConfiguration {
  ...
  sequence<MediaSourceType> sourceTypes = ["mse"];
};

Notes:
* The default value for the new member makes responses default to MSE, which is what most applications will want.
* This solution allows a single configuration to be used for both MSE and .src and to get a response as to which one(s) are supported by the returned object. However, is there actually a use case for this? I assume most applications will be written for one or the other. 
* The name "MediaSourceType" is generic since this might be useful elsewhere, though it does sound like it is specific to the Media Source spec.

Handling incompatible sources:
* When a source is already set, the setMediaKeys() promise is rejected with "NotSupportedError" or "InvalidStateError" (pick one).
* When an unsupported source is set after setMediaKeys() succeeds, the HTMLMediaElement reports MEDIA_ERR_SRC_NOT_SUPPORTED.


This seems like a lot of work for something that rarely matters, and it is a bit odd for EME to have to be concerned about this. At least adding a specific member with a reasonable default to an existing dictionary allows us to deprecate this member over time if necessary.

[1] https://w3c.github.io/encrypted-media/#idl-def-MediaKeySystemConfiguration

(In reply to David Dorwin from comment #8)
> This seems like a lot of work for something that rarely matters, and it is a
> bit odd for EME to have to be concerned about this. At least adding a
> specific member with a reasonable default to an existing dictionary allows
> us to deprecate this member over time if necessary.

An important question is whether the app would take any useful alternate action based on the results. Most EME-using apps are likely to be written for either MSE or .src=url. For such apps, differentiating in requestMediaKeySystemAccess() does not allow the app to do anything different - it will still fail.

If an application wanted to fallback, it could do so after the failure.

The usefulness is further decreased by the fact that there are no known implementations that only support EME with non-MSE sources. (This would be especially true for any implementation that supports MSE for clear content.) Thus, this becomes a way to ask whether EME supports .src=url is supported, something that we do not expect to be common.

Note that spec compliance tests will likely use .src=url, meaning implementations will need to support this.

Another thing to consider is that from an application and spec point of view, MSE vs. .src=url is a demuxing issue while EME (except for the "encrypted" event) and its objects are related to the post-demuxing stages of playback. The fact that some implementations use different pipelines depending on the type of demuxing seems like an oddity.


In summary, we do not have concrete use cases, apps are unlikely to take any useful alternate action, and implementations should not differentiate between the sources. Thus, I think we should close this, possibly adding a non-normative note that some implementations may not support non-MSE content with EME.

For clarity, I propose we close this bug after adding a non-normative note that some implementations may not support non-MSE content with EME.

https://github.com/w3c/encrypted-media/commit/a52d90337bec8bdafc457b33d48d617dc9b1f7bf adds the non-normative note.