diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html index 4b3eeb97..d97d7391 100644 --- a/encrypted-media-respec.html +++ b/encrypted-media-respec.html @@ -289,7 +289,7 @@
For example, a key is not usable for decryption if its license has expired. Even if its license has not expired, a key is not usable for decryption if other conditions (e.g., output protection) for its use are not currently satisfied.
-A key is associated with a key ID that is a sequence of octets and which uniquely identifies the key. The container specifies the ID of the key that can decrypt a block or set of blocks within the . @@ -332,7 +332,7 @@
The format of the initialization data depends upon the type of container, and containers MAY support more than one format - of initialization data. The Initialization Data Type is a string that indicates the + of initialization data. The Initialization Data Type is a string that indicates the format of the accompanying Initialization Data. Initialization Data Type strings are always matched case-sensitively. It is RECOMMENDED that Initialization Data Type strings are lower-case ASCII strings.
@@ -3027,7 +3027,7 @@The Initialization Data Encountered algorithm queues an event for encounterd in the . Requests to run this algorithm include a target object. @@ -3061,7 +3061,7 @@
The Encrypted Block Encountered algorithm queues a block of encrypted media data for decryption and attempts to decrypt if possible. Requests to run this algorithm include a target object. diff --git a/format-registry/initdata/cenc-respec.html b/format-registry/initdata/cenc-respec.html index c79c6a0a..d2560856 100644 --- a/format-registry/initdata/cenc-respec.html +++ b/format-registry/initdata/cenc-respec.html @@ -3,8 +3,7 @@
This specification defines the "cenc"
format for use with the [[!ENCRYPTED-MEDIA]].
- This format is commonly used with the [[EME-STREAM-REGISTRY]].
+
This specification defines the "cenc"
[=initialization data=] format for use with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
+ This format is commonly used with the [[[EME-STREAM-MP4]]] [[EME-STREAM-REGISTRY]].
This specification also defines a common SystemID and PSSH box format for use with Encrypted Media Extensions.
-This format's string "cenc"
refers to the [[CENC]] spec that defines the PSSH boxes that comprise the format.
+
This format's [=initialization data type=] string "cenc"
refers to the [[CENC]] spec that defines the PSSH boxes that comprise the format.
It does not relate to or imply a stream format, including the use of the 'cenc' protection scheme.
- Stream formats are indicated by the content types as defined in [[EME-STREAM-REGISTRY]].
+ Stream formats are indicated by the content types as defined in the [[[EME-STREAM-REGISTRY]]] [[EME-STREAM-REGISTRY]].
+
The format is one or more concatenated Protection System Specific Header ('pssh') boxes [[!CENC]], each for a unique SystemID. +
The format is one or more concatenated Protection System Specific Header ('pssh') boxes [[CENC]], each for a unique SystemID. One of the concatenated 'pssh' boxes SHOULD use the Common SystemID and PSSH Box Format.
-[[!CENC]] also specifies storage of a 'pssh' box base64-encoded in an XML element of the form <cenc:pssh (base64 'pssh')>
.
+
[[CENC]] also specifies storage of a 'pssh' box base64-encoded in an XML element of the form <cenc:pssh (base64 'pssh')>
.
For example, [[MPEGDASH]] manifests may provide 'pssh' boxes in this format, each contained in a ContentProtection Descriptor element identified by a SystemID.
These 'pssh' boxes may be decoded and concatenated by an application to provide equivalent Initialization Data to that stored in movie or movie fragment boxes.
When such Initialization Data is provided by the application, an implementation (the user agent and/or CDM) MUST :
+When such Initialization Data is provided by the application, an implementation (the user agent and/or CDM) MUST:
Examine the series of 'pssh' boxes to find the first 'pssh' box that the CDM instance supports. This includes checking the SystemID, box version, and system-specific values.
If no such supported box is found, the provided data SHALL be considered "not supported by the CDM."
When Initialization data is provided with initDataType "cenc"
, implementations MUST look for and use the PSSH box with the Common SystemID.
When Initialization data is provided with initDataType "cenc"
, Clear Key implementations MUST look for and use the PSSH box with the Common SystemID.
Implementations MAY support other SystemIDs for backwards compatibility with existing streams.
The SystemID is 1077efec-c0b2-4d02-ace3-3c1e52e2fb4b
.
The PSSH box format is as follows. It follows version 1 of the 'pssh' box as defined in [[!CENC]].
+The PSSH box format is as follows. It follows version 1 of the 'pssh' box as defined in [[CENC]].
1
0
when constructing this box. When processing, if dataSize is non-zero the Data field SHALL be ignored.This specification defines the formats for use with the [[!ENCRYPTED-MEDIA]].
+This specification defines the [=initialization data=] formats for use with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
-Some formats may be extracted from [[HTML5]] as defined in the [[EME-STREAM-REGISTRY]]. +
Some formats may be extracted from [=HTMLMediaElement/media data=] as defined in the [[[EME-STREAM-REGISTRY]]] [[EME-STREAM-REGISTRY]]. All may be provided separately, such as via a manifest or other application data.
+This registry is non-normative.
This registry is intended to enhance interoperability among implementations and users of encrypted media streams with the - (EME) specification [[!ENCRYPTED-MEDIA]]. In particular, this registry provides the means (1) to identify + [[[ENCRYPTED-MEDIA]]] (EME) specification [[ENCRYPTED-MEDIA]]. In particular, this registry provides the means (1) to identify and avoid collisions among initialization data type strings, and (2) to disclose information about initialization data formats accepted by EME implementations to promote interoperability.
The registry maintains a mapping between strings and format specifications, which describe the structure and semantics of initialization data.
- The strings are those used for initDataType
values provided by and to [[!ENCRYPTED-MEDIA]] APIs.
+
The registry maintains a mapping between [=initialization data type=] strings and format specifications, which describe the structure and semantics of initialization data.
+ The strings are those used for initDataType
values provided by and to [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]] APIs.
This registry is not intended to include any information on whether a format is encumbered by intellectual property claims. Implementors and users are advised to seek appropriate legal counsel in this matter if they intend to implement or use a specific format.
@@ -130,18 +98,23 @@Each entry must include a unique [=initialization data type=] string.
Each entry must include a link that references a publicly available specification. - It is RECOMMENDED that such a specification be made available without cost (other than reasonable shipping and handling if not available by online means). + It is recommended that such a specification be made available without cost (other than reasonable shipping and handling if not available by online means).
Candidate entries must be announced on public-media-wg@w3.org(subscribe, - archives) so they can be discussed and evaluated for compliance before being added to the registry. +
Candidate entries must be announced by filing an issue in the + Encrypted Media Extensions GitHub issue tracker + so they can be discussed and evaluated for compliance before being added to + the registry.
Per the specification, entries MUST be fully specified and support common formats such that instances of the format can be processed in a fully specified and compatible way.
Per the [[[ENCRYPTED-MEDIA]]] specification, entries must be fully specified and support common formats such that instances of the format can be processed in a fully specified and compatible way.
Existing entries cannot be deleted or deprecated.
+This specification defines the "keyids"
format for use with the [[!ENCRYPTED-MEDIA]].
It defines a stream format-independent format for specifying a list of (s). +
This specification defines the "keyids"
[=initialization data=] format for use with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
It defines a stream format-independent format for specifying a list of [=Decryption key ID|key ID=](s). This type can be used by applications to directly provide information necessary to generate a license request without using media data or constructing container-specific formats.
The format is a JSON object, encoded in UTF-8 as specified in the Encoding specification [[!encoding]], containing the following member:
+The format is a JSON object, encoded in UTF-8 as specified in the Encoding specification [[encoding]], containing the following member:
Applications may encode the JSON string using the [[encoding]]
+See Using base64url.
+Applications may encode the JSON string using the {{TextEncoder}} interface [[encoding]].
The following example will generate a license request for two (s). (Line breaks are for readability only.)
+The following example will generate a license request for two [=Decryption key ID|key ID=](s). (Line breaks are for readability only.)
{ "kids": [ "LwVHf8JLtPrv2GUXFW2v_A", "0DdtU9od-Bh5L3xbv0Xf_A" - ], + ] }
This specification defines the "webm"
format for use with the [[!ENCRYPTED-MEDIA]].
- This format is commonly used with the [[EME-STREAM-REGISTRY]].
+
This specification defines the "webm"
[=initialization data=] format for use with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
+ This format is commonly used with the [[[EME-STREAM-WEBM]]] [[EME-STREAM-REGISTRY]].
The format is a single of one or more bytes, as defined by the ContentEncKeyID [[!Matroska]] element and [[!WebM-Encryption]].
+The format is a single [=Decryption key ID|key ID=] of one or more bytes, as defined by the ContentEncKeyID [[Matroska]] element and [[WebM-Encryption]].
+This specification defines the stream formats for use with the [[!ENCRYPTED-MEDIA]].
+This specification defines the stream formats for use with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
+This registry is non-normative.
This registry is intended to enhance interoperability among implementations and users of encrypted media streams with the - (EME) specification [[!ENCRYPTED-MEDIA]]. In particular, this registry provides the means (1) to identify + [[[ENCRYPTED-MEDIA]]] (EME) specification [[ENCRYPTED-MEDIA]]. In particular, this registry provides the means (1) to identify and avoid collisions among content type strings, and (2) to disclose information about encrypted data formats accepted by EME implementations to promote interoperability.
The registry maintains a mapping between content type strings and encryption format specifications, which describe the structure, semantics, and processing of the formats.
- The strings are those used for the media type/subtype pairs in contentType
values provided to [[!ENCRYPTED-MEDIA]] APIs.
+ The strings are those used for the media type/subtype pairs in contentType
values provided to [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]] APIs.
This registry is not intended to include any information on whether a stream format is encumbered by intellectual property claims. Implementors and users are advised to seek appropriate legal counsel in this matter if they intend to implement or use a specific stream format.
@@ -126,19 +97,24 @@Each entry must include a unique MIME-type/subtype pair. If the byte stream format is derived-from an existing file format, then it should use the MIME-type/subtype pairs typically used for the file format.
+Each entry must include a link that references a publicly available specification. - It is RECOMMENDED that such a specification be made available without cost (other than reasonable shipping and handling if not available by online means). + It is recommended that such a specification be made available without cost (other than reasonable shipping and handling if not available by online means).
Candidate entries must be announced on public-media-wg@w3.org(subscribe, - archives) so they can be discussed and evaluated for compliance before being added to the registry. +
Candidate entries must be announced by filing an issue in the + Encrypted Media Extensions GitHub issue tracker + so they can be discussed and evaluated for compliance before being added to + the registry.
Per the specification, the media container for a stream format MUST NOT be encrypted.
Per the specification, entries MUST be fully specified and support "common encryption" such that the content can decrypted in a fully specified and compatible way when a key or keys are provided.
Per the [[[ENCRYPTED-MEDIA]]] specification, the media container for a stream format must not be encrypted.
Per the [[[ENCRYPTED-MEDIA]]] specification, entries must be fully specified and support "common encryption" such that the content can decrypted in a fully specified and compatible way when a key or keys are provided.
Existing entries cannot be deleted or deprecated.
This specification defines the stream format for using ISO Base Media - File Format [[!ISOBMFF]] content that uses the ISO Common Encryption - protection schemes [[!CENC]] with the - [[!ENCRYPTED-MEDIA]]. + File Format [[ISOBMFF]] content that uses the ISO Common Encryption + protection schemes [[CENC]] with the [[[ENCRYPTED-MEDIA]]] + [[ENCRYPTED-MEDIA]].
- Although the ISO Base Media File Format [[!ISOBMFF]] associated with + Although the ISO Base Media File Format [[ISOBMFF]] associated with this format's MIME type/subtype strings supports multiple protection schemes, when used with Encrypted Media Extensions, these strings refer specifically to content encrypted and packaged using the 'cenc' or - 'cbcs' protection schemes, as defined by section 4.2 of [[!CENC]]. + 'cbcs' protection schemes, as defined by section 4.2 of [[CENC]].
- ISO Base Media File Format [[!ISOBMFF]] content that is encrypted using - the ISO Common Encryption protection schemes [[!CENC]] SHALL be + ISO Base Media File Format [[ISOBMFF]] content that is encrypted using + the ISO Common Encryption protection schemes [[CENC]] SHALL be encrypted at the sample level with either the 'cenc' (AES-128 CTR) or 'cbcs' (AES-128 CBC) encryption schemes, as defined in section 4.2 of - [[!CENC]]. These protection methods enabls multiple Key Systems to + [[CENC]]. These protection methods enable multiple Key Systems to decrypt the same media content.
- Each key is identified by a and each encrypted + Each key is identified by a [=Decryption key ID|key ID=] and each encrypted sample is associated with the key ID of the key needed to decrypt it. This association is signaled either through the specification of a default key ID in the track encryption box ('tenc') or by assigning the @@ -144,26 +116,25 @@
For a stream determined to be in the ISO Base Media File Format - [[!ISOBMFF]], the ISO Common Encryption protection schemes may be + [[ISOBMFF]], the ISO Common Encryption protection schemes may be detected as follows.
- Protection scheme signaling conforms with [[!ISOBMFF]]. When protection
+ Protection scheme signaling conforms with [[ISOBMFF]]. When protection
has been applied, the stream type will be transformed to 'encv' for
video or 'enca' for audio, with a Protection Scheme Information Box
('sinf') added to the sample entry in the Sample Description Box
('stsd'). The Protection Scheme Information Box ('sinf') will contain a
Scheme Type Box ('schm') with a scheme_type field set to a value of
- 'cenc'
or 'cbcs'
. [[!CENC]]
+ 'cenc'
or 'cbcs'
[[CENC]].
- For the purposes of the , encrypted blocks - are identified as follows. + For the purposes of the [=Encrypted Block Encountered=] algorithm, + encrypted blocks are identified as follows.
The encrypted block is a sample. Determining whether a sample is @@ -180,31 +151,35 @@
For complete information, see [[!CENC]].
+For complete information, see [[CENC]].
Streams may contain one or more Protection System Specific Header - ('pssh') boxes [[!CENC]], each for a unique SystemID, at each location + ('pssh') boxes [[CENC]], each for a unique SystemID, at each location where a 'pssh' box is necessary. Content using this stream format - SHOULD include a box containing the . + SHOULD include a box containing the + Common SystemID and PSSH Box Format.
- is always one or more concatenated - 'pssh' boxes as defined by the - [[!EME-INITDATA-REGISTRY]]. + [=Initialization data=] is always one or more concatenated + 'pssh' boxes as defined by the [[[EME-INITDATA-CENC]]] + [[EME-INITDATA-REGISTRY]].
- Each time one or more 'pssh' boxes are encountered, the algorithm SHALL be invoked
+ Each time one or more 'pssh' boxes are encountered, the
+ [=Initialization Data Enountered=] algorithm SHALL be invoked
with initDataType = "cenc"
- [[!EME-INITDATA-REGISTRY]] and initData = the 'pssh'
+ data-cite="eme-initdata-cenc#format">cenc"
+ [[EME-INITDATA-REGISTRY]] 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 stream.
This specification defines the stream format for using WebM [[!WebM]] content with the [[!ENCRYPTED-MEDIA]].
+This specification defines the stream format for using WebM [[WebM]] content with the [[[ENCRYPTED-MEDIA]]] [[ENCRYPTED-MEDIA]].
Encrypted WebM streams [[!WebM-Encryption]] are encrypted at the block level with AES-128 CTR encryption. - The container SHALL include appropriate values within the ContentEncryption [[!Matroska]] element. +
Encrypted WebM streams [[WebM-Encryption]] are encrypted at the block level with AES-128 CTR encryption. + The container SHALL include appropriate values within the ContentEncryption [[Matroska]] element.
WebM streams may be partially encrypted, both at the Track level and the block level. In the former case, a subset of Tracks in the stream have a ContentEncryption element. @@ -121,18 +88,21 @@
For a stream determined to be in the WebM format [[!WebM]], when a Track [[!Matroska]] is parsed, the presence of a ContentEncKeyID element indicates that blocks in the track may be encrypted.
+For a stream determined to be in the WebM format [[WebM]], when a Track [[Matroska]] is parsed, the presence of a ContentEncKeyID element indicates that blocks in the track may be encrypted.
For the purposes of the , encrypted blocks are those marked encrypted by the Signal Byte. [[!WebM-Encryption]]
+For the purposes of the [=Encrypted Block Encountered=] algorithm, encrypted blocks are those marked encrypted by the Signal Byte [[WebM-Encryption]].
is always a single , as defined by the [[!EME-INITDATA-REGISTRY]].
-Each time a ContentEncKeyID [[!Matroska]] element is encountered in a Track, the algorithm SHALL be invoked with initDataType = "webm"
[[!EME-INITDATA-REGISTRY]] and initData = the value in that element.
[=Initialization Data=] is always a single [=Decryption key ID|key ID=], as defined by the [[[EME-INITDATA-WEBM]]] [[EME-INITDATA-REGISTRY]].
+Each time a ContentEncKeyID [[Matroska]] element is encountered in a Track, the [=Initialization Data Encountered=] algorithm SHALL be invoked with initDataType = "webm"
[[EME-INITDATA-REGISTRY]] and initData = the value in that element.