Abstract

This specification defines a Media Source Extensions byte stream format specification based on the WebM container format.

Status of This Document

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

The working group maintains a list of all bug reports that the editors have not yet tried to address; there may also be open bugs in the previous bug tracker.

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.

This document was published by the HTML Media Extensions Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-html-media@w3.org (subscribe, archives). All comments are welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. 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 5 February 2004 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 1 September 2015 W3C Process Document.

Table of Contents

1. Introduction

This specification describes a byte stream format based on the WebM container format. It defines the MIME-type parameters used to signal codecs, and provides the necessary format specific definitions for initialization segments, media segments, and random access points required by the byte stream formats section of the Media Source Extensions spec.

2. MIME-type parameters

This section specifies the parameters that can be used in the MIME-type passed to isTypeSupported() or addSourceBuffer().

codecs
A comma separated list of codec IDs used to specify what codecs will be used in the byte stream.
Codec ID Valid with "audio/webm" Valid with "video/webm"
vorbis true true
opus true true
vp8 false true
vp9 false true
Note
Implementations SHOULD support all of the codec IDs mentioned in the table above.

Examples of valid MIME-types with a codecs parameter.

  • audio/webm;codecs="vorbis"
  • video/webm;codecs="vorbis"
  • video/webm;codecs="vp8"
  • video/webm;codecs="vp8,vorbis"
  • video/webm;codecs="vp9,opus"

3. Initialization Segments

A WebM initialization segment MUST contain a subset of the elements at the start of a typical WebM file.

The user agent MUST run the append error algorithm with the decode error parameter set to true if any of the following conditions are not met:

  1. The initialization segment MUST start with an EBML Header element, followed by a Segment header.
  2. The size value in the Segment header MUST signal an "unknown size" or contain a value large enough to include the Segment Information and Tracks elements that follow.
  3. A Segment Information element and a Tracks element MUST appear, in that order, after the Segment header and before any further EBML Header or Cluster elements.

The user agent MUST accept and ignore any elements other than an EBML Header or a Cluster that occur before, in between, or after the Segment Information and Tracks elements.

The user agent MUST source attribute values for id, kind, label and language for AudioTrack, VideoTrack and TextTrack objects as described for WebM in the in-band tracks spec [INBANDTRACKS].

4. Media Segments

A WebM media segment is a single Cluster element.

The user agent uses the following rules when interpreting content in a Cluster:

  1. The TimecodeScale in the WebM initialization segment most recently appended applies to all timestamps in the Cluster
  2. The Timecode element in the Cluster contains a presentation timestamp in TimecodeScale units.
  3. The Cluster header MAY contain an "unknown" size value. If it does then the end of the cluster is reached when another Cluster header or an element header that indicates the start of an WebM initialization segment is encountered.

The user agent MUST run the append error algorithm with the decode error parameter set to true if any of the following conditions are not met:

  1. The Timecode element MUST appear before any Block & SimpleBlock elements in a Cluster.
  2. Block & SimpleBlock elements are in time increasing order consistent with the WebM spec.
  3. If the most recent WebM initialization segment describes multiple tracks, then blocks from all the tracks MUST be interleaved in time increasing order. At least one block from all audio and video tracks MUST be present.

The user agent MUST accept and ignore Cues or Chapters elements that follow a Cluster element.

5. Random Access Points

Either a SimpleBlock element with its Keyframe flag set, or a BlockGroup element having no ReferenceBlock elements, signals the location of a random access point for that track. The order of multiplexed blocks within a media segment MUST conform to the WebM Muxer Guidelines.

6. Conformance

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 words MAY, MUST, and SHOULD are to be interpreted as described in [RFC2119].

7. Acknowledgments

The editors would like to thank Frank Galligan, and Philip Jägenstedt for their contributions to this specification.

A. References

A.1 Normative references

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

A.2 Informative references

[INBANDTRACKS]
Bob Lund; Silvia Pfeiffer. Sourcing In-band Media Resource Tracks from Media Containers into HTML. URL: http://dev.w3.org/html5/html-sourcing-inband-tracks/