This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Will address after FPWD as discussed during the telecon today.
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.
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.
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.)
(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.
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.
Re-opening per the discussion in bug 23828 and elsewhere.
Before reordering the spec and converting it to ReSpec, I plan to submit a changeset that removes HTMLSourceElement (rather than spending time converting it). If necessary, it can be added back along with a fix for bug 23828.
Agreed to remove in the telecon today.
https://dvcs.w3.org/hg/html-media/rev/b14f7a214d8a removes modifications of HTMLSourceElement from the spec.