- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 7 Mar 2012 20:57:46 +0000
- To: Charles Pritchard <chuck@jumis.com>
- CC: Henri Sivonen <hsivonen@iki.fi>, Tab Atkins Jr. <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
On Mar 7, 2012, at 12:44 PM, Charles Pritchard wrote: > On 3/7/12 9:34 AM, Mark Watson wrote: >> On Mar 7, 2012, at 4:54 AM, Henri Sivonen wrote: >> >>> On Mon, Mar 5, 2012 at 2:57 AM, Mark Watson<watsonm@netflix.com> wrote: >>>> This is how we at Netflix are able to work with multiple CDMs but one set of media files using the ISO Common Encryption standard for mp4 files. >>> Other than ISO Common Encryption being already deployed, what's the >>> benefit of encrypting codec data the mp4 container using AES-CTR as >>> opposed to encrypting the entire mp4 file using AES-CTR? >> Hi Henri, >> >> In ISO Common Encryption, the following parts of the file are in the clear: >> - index information for random access and adaptive stream switching >> - codec initialization and compatibility information >> - sample timing and dependency information >> - headers providing content protection initialization information (possibly for multiple content protection schemes) >> >> This allows a number of functions to be performed before decryption: >> - determining compatibility and initializing codecs >> - construction of HTTP requests for specific time ranges (basically, all of the adaptive streaming logic) >> - extraction of samples into a common container-independent format (elementary streams) with attention to audio/video synchronization >> - selection and initialization of a content protection system > > Decryption of index blocks is not a big deal. The overhead is absolutely minimal; instead of seeking to position N, you seek to position N - N MOD blocksize. What I mean is that because the index is in the clear, then code handling the data in advance of the decryption function can handle construction of byte ranges (which is needs the in-the-clear index to construct), rate adaptation decisions etc. > > The multiple content protection schemes (and multiple keys) case, of course, is a very different thing. Things (plural): multiple content protection schemes and multiple keys are orthogonal features. > > This one sticks: > "- headers providing content protection initialization information (possibly for multiple content protection schemes)" Not sure what you mean. The idea of common encryption is that the same file could be decoded by multiple protection systems, e.g. PlayReady or Widevine. This is what could make CDMs substitutable. > > -Charles >
Received on Wednesday, 7 March 2012 20:58:16 UTC