W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: AES-CTR inside vs. outside the media container (was: Re: Encrypted Media proposal: Summary of the discussion so far)

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 7 Mar 2012 17:34:16 +0000
To: Henri Sivonen <hsivonen@iki.fi>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <410B1774-F991-472C-AB91-D176EB1BBA10@netflix.com>

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

The benefit of performing these functions before decryption (other than the last, which cannot be performed after decryption), is that implementation of these functions becomes possible in code that is not trusted by the content protection system in use. For example in Javascript, or if the browser itself is untrusted, in the browser.

You should not discount the fact that this is an already complete standard: it will be supported across many devices and it would be unfortunate to unnecessarily create a competing standard.


> (Presumably in non-streaming cases, it might be useful to be able to
> read embedded metadata even if the media is unrenderable, but in the
> streaming Web case, that doesn't seem like an important benefit.)
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
Received on Wednesday, 7 March 2012 17:34:48 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:49 UTC