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 https://www.w3.org/TR/.
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.
Publication as a Working Group Note 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 section specifies the MIME-types that may be passed to isTypeSupported() or addSourceBuffer() for byte streams that conform to this specification.
"audio/mpeg" for MPEG-1/2/2.5 Layer I/II/III streams, as specified in RFC 3003 [RFC3003].
The "codecs" MIME-type parameter MUST NOT be used with these MIME-types.
3. MPEG Audio Frames
The format of an MPEG Audio Frame depends on the MIME-type used.
If the "audio/aac" MIME-type is used, an MPEG Audio Frame is a sequence of bytes that conform to the adts_frame() syntax specified in Table 1.A.5 of ISO/IEC 14496-3:2009.
If the "audio/mpeg" MIME-type is used, an MPEG Audio Frame is a sequence of bytes that conform to the frame() syntax element specified in Section 2.4.1.2 of ISO/IEC 11172-3:1993 or the corresponding definition in ISO/IEC 13818-3:1998.
4. Metadata Frames
Since ID3v1, ID3v2 metadata frames, and Icecast headers are common in existing MPEG audio streams, implementations SHOULD gracefully handle such frames. Zero or more of these metadata frames are allowed to occur before, after, or between MPEG Audio Frames. Minimal implementations MUST accept, consume, and ignore these frames. More advanced implementations MAY choose to expose the metadata information via an inband TextTrack or some other mechanism.
4.1 Icecast headers
There is no normative spec for Icecast/SHOUTcast headers, just examples. For the purpose of this specification, an Icecast header is defined as beginning with the 4 character sequence "ICY "(U+0049 I, U+0043 C, U+0059 Y, U+0020 SPACE) and ending with a pair of carriage-return line-feed sequences (U+000D CARRIAGE RETURN, U+000A LINE FEED, U+000D CARRIAGE RETURN, U+000A LINE FEED).
Note
Icecast headers are allowed in the byte streams because some Icecast and SHOUTcast servers return a status line that looks like "ICY OK 200" instead of a standard HTTP status line. User-agent network stacks typically interpret this as an HTTP 0.9 response and include the header in the response body. Allowing these headers to appear provides a simple way to interoperate with these servers.
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, MUST NOT, and SHOULD are to be interpreted as described in [RFC2119].