Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement
Revert addition of keySystem attribute to HTMLSourceElement
Status: RESOLVED WORKSFORME
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on: 19156 20335
Blocks: 23828 23897
  Show dependency treegraph
 
Reported: 2012-12-11 06:54 UTC by David Dorwin
Modified: 2013-11-23 00:27 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dorwin 2012-12-11 06:54:02 UTC
This is a proposal.

keySystem was originally added to HTMLSourceElement to allow selection of a supported key system-type combination by the user agent and to be consistent with the changes to canPlayType().

With the removal of the canPlayType() changes (bug 20335) and moving of EME methods to new objects, the HTMLMediaElement no longer has knowledge of key systems. It seems appropriate to also remove such knowledge from HTMLSourceElement as well.
Comment 1 David Dorwin 2013-01-08 16:38:42 UTC
Will address after FPWD as discussed during the telecon today.
Comment 2 David Dorwin 2013-04-23 20:36:57 UTC
In the January 8th telecon, Adrian said he was discussing this internally to decide how useful it is. Assigning to him to report back and resume discussion.
Comment 3 Adrian Bateman [MSFT] 2013-04-24 23:21:52 UTC
We have a working prototype of this and believe it is useful. For example, you might use this to declaratively prioritise a protected high quality resource over a non-protected low quality resource.

I propose that we resolve this WORKSFORME.
Comment 4 David Dorwin 2013-05-01 04:27:54 UTC
It doesn't matter too much to me - the primary downside is the extra work for implementors. How important is the declarative case given that many (most?) EME apps will use MSE as well? 

I'm a bit concerned that the same logic (type + key system) needs to be spread across objects to support both <source> and MediaKeys::isTypeSupported(). I don't have experience to say how big of an issue that is, though.

If this makes sense for EME, does it make sense for MSE as well? I guess the assumption there is that you either support MSE for ISO/WebM or you wouldn't support any such extensions to HTMLSourceElement. Browsers that don't support MSE might get an automatic fallback without needing to make any changes, though. (If there is interest in this idea, we should file a separate bug for MSE. I'm just bringing it up here for context.)
Comment 5 Aaron Colwell 2013-05-01 14:07:31 UTC
(In reply to comment #4)
> It doesn't matter too much to me - the primary downside is the extra work
> for implementors. How important is the declarative case given that many
> (most?) EME apps will use MSE as well? 

I think you need to be careful about assuming that MSE & EME will always be used together. I can easily see web applications wanting to protect their content without going down the adaptive streaming path.

> 
> I'm a bit concerned that the same logic (type + key system) needs to be
> spread across objects to support both <source> and
> MediaKeys::isTypeSupported(). I don't have experience to say how big of an
> issue that is, though.
> 
> If this makes sense for EME, does it make sense for MSE as well? I guess the
> assumption there is that you either support MSE for ISO/WebM or you wouldn't
> support any such extensions to HTMLSourceElement. Browsers that don't
> support MSE might get an automatic fallback without needing to make any
> changes, though. (If there is interest in this idea, we should file a
> separate bug for MSE. I'm just bringing it up here for context.)

You can't use HTMLSourceElement with MSE because you have no way to determine what the URL would be at page generation time. Even if we used URLs w/ a special scheme to signal MSE usage, most existing browsers would fail on those URLs because they don't understand what the URL is trying to convey. I tried going down this path early in MSE's life. I gave up on it because the fallback behavior for browsers that didn't support MSE wouldn't actually work. :/

In the case of EME though it is possible to have valid URLs that the browser understands, can try, and are available at page generation time. I'm pretty sure existing browsers would ignore the keySystem attribute on the element and would run the resource selection algorithm as if it didn't exist. As long as the encrypted content does not cause the selection algorithm to abort early in existing browsers, I believe that adding this attribute to the HTMLSourceElement is useful for applications that don't plan on using MSE.
Comment 6 Adrian Bateman [MSFT] 2013-05-21 16:05:57 UTC
Discussed on the telcon today. We resolved to close this bug WORKSFORME. I think there are reasonable use cases for this feature when dealing with non-MSE protected content, for example where you want to use the source selection algorithm to favour higher quality protected content over lower quality unprotected content.