This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It appears that supporters of EME are not themselves intending to distribute premium content using the Clear Key key system. It appears that the main use of Clear Key by the supporters of EME is to use it for debugging. Even if the Clear Key scheme might have utility for debugging, I think it shouldn't be a requirement to ship such debugging code. Moreover, an implementor may opt to debug the full stack instead using the sort of CDM that premium content would be targeted to but perhaps using debugging keys. Moreover, it isn't a given that a non-Clear Key CDM always comes with an implementation of Clear Key and it doesn't really make sense to have to maintain an implementation of Clear Key on the production level of quality if its purpose is just debugging and the CDM or CDMs that are really intended for actual premium content don't happen to expose the Clear Key option. Furthermore, if one expects DRM for video to eventually go away as it did for audio, having Clear Key support shipped in release builds would for sure mean that some content would become dependent on it even if that content wouldn't actually gain any protection. Thus, if the owners of premium content one day no longer want DRM, we'd still have to keep EME machinery around for backwards compatibility with content that exercises Clear Key for no good reason. Implementing Clear Key independently of the CDM implementation for another key system does not come for free: Browsers that outsource MP4 demuxing might have to implement their own MP4 demuxing where platform MP4 demuxing does not support Common Encryption. Thus, browsers that use platform decoders but don't have a CDM for another key system that would support Clear Key as a side effect might have to do useless development work just to get Clear Key working for sites that for whatever reason use Clear Key even though those sites are not gaining any actual protection by using it.
(In reply to comment #0) > It appears that supporters of EME are not themselves intending to distribute > premium content using the Clear Key key system. It appears that the main use > of Clear Key by the supporters of EME is to use it for debugging. > > Even if the Clear Key scheme might have utility for debugging, I think it > shouldn't be a requirement to ship such debugging code. Moreover, an > implementor may opt to debug the full stack instead using the sort of CDM > that premium content would be targeted to but perhaps using debugging keys. > > Moreover, it isn't a given that a non-Clear Key CDM always comes with an > implementation of Clear Key and it doesn't really make sense to have to > maintain an implementation of Clear Key on the production level of quality > if its purpose is just debugging and the CDM or CDMs that are really > intended for actual premium content don't happen to expose the Clear Key > option. > > Furthermore, if one expects DRM for video to eventually go away as it did > for audio, having Clear Key support shipped in release builds would for sure > mean that some content would become dependent on it even if that content > wouldn't actually gain any protection. Thus, if the owners of premium > content one day no longer want DRM, we'd still have to keep EME machinery > around for backwards compatibility with content that exercises Clear Key for > no good reason. > > Implementing Clear Key independently of the CDM implementation for another > key system does not come for free: Browsers that outsource MP4 demuxing > might have to implement their own MP4 demuxing where platform MP4 demuxing > does not support Common Encryption. Thus, browsers that use platform > decoders but don't have a CDM for another key system that would support > Clear Key as a side effect might have to do useless development work just to > get Clear Key working for sites that for whatever reason use Clear Key even > though those sites are not gaining any actual protection by using it. Since the ClearKey system is already specified in the ED, and since I'm not aware of any intrinsic technical bugs reported against it (other than it might not satisfy some use cases, which I don't view as a technical bug), then I would prefer to see it remain in the ED. In other words, I see no harm in it remaining in the ED. Removing it seems to entail non-zero editorial effort and removes a useful defined CDM. As for whether its support should be mandatory (MUST) or recommended (SHOULD), I would not object to it being changed from MUST to SHOULD implement. Also, it seems to me that a UA could conditionally support the org.w3.clearkey keySystem according to content type. For example, MediaKeys.isTypeSupported("video/mp4", "org.w3.clearkey") could return false given the scenario you describe above, while it might return true for other MIME types.
Discussed in telcon. Resolving LATER to get more implementation experience with ClearKey before deciding whether this should be optional. http://www.w3.org/2013/02/26-html-media-minutes.html
Data point: https://code.google.com/p/chromium/issues/detail?id=169203 The Chromium code that links to that bug characterizes the current situation as "unsustainable".
(In reply to comment #3) > Data point: https://code.google.com/p/chromium/issues/detail?id=169203 The > Chromium code that links to that bug characterizes the current situation as > "unsustainable". Do you have a pointer to the code that contains that characterization?
(In reply to comment #4) > (In reply to comment #3) > > Data point: https://code.google.com/p/chromium/issues/detail?id=169203 The > > Chromium code that links to that bug characterizes the current situation as > > "unsustainable". > > Do you have a pointer to the code that contains that characterization? Argh. I should have pressed the back button and re-read before putting a word in quotes. Sorry. It does not say the current solution is unsustainable. It says a sustainable solution is needed. https://mxr.mozilla.org/chromium/source/src/webkit/media/crypto/ppapi/ffmpeg_cdm_audio_decoder.h#26
(In reply to comment #3) > Data point: https://code.google.com/p/chromium/issues/detail?id=169203 The > Chromium code that links to that bug characterizes the current situation as > "unsustainable". As far as I can see, this bug says the code factoring is unsustainable and nothing about ClearKey as a CDM. Since there isn't a common base class it says copying and pasting code fixes is necessary, which isn't a good long term solution for implementation. You could read it as saying that since ClearKey has a long term future, this situation needs to be resolved.
My point is that Chromium doesn't get Clear Key "for free" thanks to their existing MP4/H.264/AAC support without rearranging their code. They don't get it as a side effect of integrating with Widevine, either. Obviously, they are able to support Clear Key and *could* rearrange code to avoid code copying, but what's the point of having to rearrange code in order to support a debugging mechanism that none of the proponents of EME intend to target "premium content" to?
(In reply to comment #3 through comment #7) The referenced Chromium code and bug are for a test-only CDM that runs outside the media stack. The real production Clear Key implementation is implemented inside the media stack and reuses the existing codec support (including the media::FFmpegAudioDecoder referenced in the bug).
Per the April 2013 WG f2f discussion and follow-up emails [1][2], this bug will be left open. [1] http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0090.html [2] http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0093.html
Tracked in ISSUE-1 https://www.w3.org/html/wg/media/track/issues/1