[Bug 17673] Define Initialization Data for implementations that choose to support the ISO Base Media File Format

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

--- Comment #64 from Jerry Smith <jdsmith@microsoft.com> ---
The complete paragraph 5 text removed was:

"Each time one or more 'pssh' boxes are encountered, the Initialization Data
Encountered algorithm shall be invoked with initDataType = "cenc" and initData
= the 'pssh' box(es). Multiple 'pssh' boxes must be provided together if and
only if they appear directly next to each other in the file."

Most of this is redundant to the first paragraph in EME under the
Initialization Data Encountered section, but it does clarify the attribute
strings and certainly is consistent with the EME spec.  I will restore it.

I believe paragraphs 2, 3 and 4 are relevant to the use of CENC content with
EME, since they elaborate on CENC features that affect when init data may be
encountered, and acknowledge that a compatible source with EME is in XML form. 
Specific replies to David's comments:

>2) The second paragraph of section 3 seems to specifically address embedded >keys. Is that right? Is this the *only* use of PSSH boxes in a 'moof'? >Embedded keys are not currently covered by the main EME spec text.

Embedded keys are a likely example, but a protection system may use any type of
authentication, authorization, and usage rules in the protection system
specific information.  The intent is to not be restrictive.  The connection to
Key ID (KID) is the only normative link between sample information and
entitlement control.  

>2a) "Each ‘moof’/’pssh’ must protect the contained keys with a SystemID >specific method." How can a 'moof' protect the keys?

The Protection System Specific data must use encryption or some other means to
protect the media keys.

>2b) The last sentence explains why one might use sample groups. I believe this >is the only such text in the spec and should be removed. (This would be >valuable in a "Using EME with Common Encryption" primer, but I don't think it >belongs in the spec/registry.

It is important to clarify that media keys and KID can change over time (per
sample), and KID signaling in CENC provides a standard index that can be used
by protection system specific information to control entitlement by controlling
access to the new KID/key.  

>3) The third paragraph seems orthogonal to EME and like a DASH-specific usage >of a generic EME capability (see also below). I think it should be removed.(Is >it really CENC that specifies this or is it DASH?)

It is specified in CENC 2nd Edition with the intent of being useful in any XML
manifest, and could be applied to other text format tags.  The important
distinction is that identical ‘pssh’ box data (including the box header) can be
stored and delivered via a manifest or other application specific method, and
processed the same way as a ‘pssh’ box stored in a file header.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 3 July 2014 20:29:42 UTC