- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Thu, 16 Jan 2014 17:13:22 +0200
- To: Jeff Jaffe <jeff@w3.org>
- Cc: RĂ¼diger Sonderfeld <ruediger@c-plusplus.de>, Mark Watson <watsonm@netflix.com>, "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
On Thu, Jan 16, 2014 at 4:15 PM, Jeff Jaffe <jeff@w3.org> wrote: > The precedent for having such (non-normative) dependencies is that we began > to standardize HTML5 video at a time when the dominant codec (H.264) did not > comply with our RF insistence for Web standards. Our approach has been to > standardize that which we can make RF to reduce the proprietary footprint > and work over time to remove the proprietary pieces. H.264 is indeed contrary to the W3C's RF insistence. Still, the CDM situation is much worse than the H.264 situation. * <video> has utility with an unencumbered codec. EME has no utility without an encumbered CDM. * What you need to do in order to decode H.264 is not a secret. The operation of CDMs is. * An H.264 decoder doesn't need to be unmodifiable by the end users. Such unmodifiability is the whole point of CDMs. * H.264 is one thing (well, a set of profiles and levels, but still). There are multiple CDMs. As long as you manage to gain access to one (multiprofile) H.264 decoder, you have achieved compatibility with (non-DRM) H.264 content. If you manage to gain access to one CDM, your browser is still incompatible with content targeted at other CDMs. * The entity collecting royalties for H.264 doesn't cares about money but not about implementation. The entities managing the permissions to interoperate with CDMs care a great deal about implementation details that aren't black-box testable from the Web ("robustness"). * If you are in a country where there's no legal need for you get permission to interoperate with H.264, your implementation gets to interoperate even if you don't arrange a permission. In the CDM case, your unlicensed implementation will be cryptographically denied interoperability by the root of trust refusing to certify your keys and key servers refusing to talk to you if your keys don't chain to the root of trust of the Key System. * There's a distinction between unauthorized interoperation being a civil matter or a criminal matter. * Platform (operating system or hardware) decoders for H.264 are more widely available than platform CDMs. * When a hardware H.264 decoder isn't available and the CPU is fast enough, a software decoder gets to decode all (non-DRM) H.264 content. When a hardware CDM is not available, a software CDM doesn't get to act as a substitute in the general case even if the CPU was fast enough. * When a platform decoder is unavailable, there are no architecture is prohibited from receiving a fully-functional (subject to CPU speed) H.264 as a software installation delivered by someone other than the platform vendor assuming that the platform allows software installation at all. When a platform CDM is unavailable, the platform cannot receive a fully-working CDM as a software installation delivered by someone other than the platform vender and the how far or close to fully-working you are allowed to get depends on the characteristics of the underlying platform. * The CDM problem includes the H.264 problem (because a CDM is expected to play H.264 content) but the solution space is restricted compared to the solution space for non-DRM H.264 decoding, because you don't get to delegate to an H.264 component that doesn't live inside the DRM realm. -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Thursday, 16 January 2014 15:13:53 UTC