WebM Stream Format

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Media Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

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. In the latter case, a subset of the blocks within a Track containing a ContentEncryption element are marked as encrypted.

Initialization Data is always a single key ID, as defined by the "webm" Initialization Data Format [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.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key word SHALL in this document is to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

[EME-INITDATA-REGISTRY]: Encrypted Media Extensions Initialization Data Format Registry. David Dorwin; Adrian Bateman; Mark Watson. W3C. 15 September 2016. W3C Working Group Note. URL: https://www.w3.org/TR/eme-initdata-registry/
[EME-INITDATA-WEBM]: "webm" Initialization Data Format. David Dorwin; Adrian Bateman; Mark Watson. W3C. 15 September 2016. W3C Working Group Note. URL: https://www.w3.org/TR/eme-initdata-webm/
[ENCRYPTED-MEDIA]: Encrypted Media Extensions. David Dorwin; Jerry Smith; Mark Watson; Adrian Bateman. W3C. 18 September 2017. W3C Recommendation. URL: https://www.w3.org/TR/encrypted-media/
[Matroska]: Matroska Specifications. Matroska. 9 January 2014. URL: https://matroska.org/technical/specs/index.html
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WebM]: WebM Container Guidelines. The WebM Project. 26 April 2016. URL: https://www.webmproject.org/docs/container/
[WebM-Encryption]: WebM Encryption. Frank Galligan. The WebM Project. 4 March 2015. URL: https://www.webmproject.org/docs/webm-encryption/

WebM Stream Format

Abstract

Status of This Document

1. Stream Format

2. Detection

3. Detecting Encrypted Blocks

4. Initialization Data Extraction

5. Conformance

A. References

A.1 Normative references