[Bug 24874] Positive isTypeSupported() may be misleading (MSE vs. .src=)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24874

--- Comment #9 from David Dorwin <ddorwin@google.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 13 December 2014 00:25:39 UTC