ietf-corpus from Lantern
rfc-6381

The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types

R. Gellens, D. Singer, P. Frojdh
date2011-08 streamIETF wgnon working group statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc6381 doi10.17487/RFC6381 errataview
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.). Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

obsoletes

updates

Extracted elements (24)

design-rationale §1

Several MIME types ('bucket' types) such as video/3gpp, audio/mp4, and video/3gpp2 can contain any of several codecs, making it impossible to determine rendering requirements from the MIME type alone. The 'codecs' and 'profiles' parameters solve this by allowing unambiguous declaration of codecs and container profiles in the Content-Type header.

registry

design-rationale §3.2

The dot ('.') character is reserved as a hierarchy delimiter within each codec identifier element, enabling codec strings to encode multi-level namespace hierarchies (e.g., codec family, OTI, profile-level). This allows the namespace for each subsequent element to be determined by its preceding element.

design-rationale §4.1

The 'profiles' parameter reports only the profile(s) applying to the complete container format, not codec-specific profiles (which are reported via the 'codecs' parameter). A container profile may imply which codecs are present, so a receiver can sometimes determine compatibility from 'profiles' alone without examining 'codecs'.

design-rationale §3.3

When SVC or MVC content is coded in an AVC-compatible fashion and the sample description includes both an AVC configuration record and an SVC/MVC configuration record, it is recommended that both records be reported in the codecs string, as they may contain different AVC profile, level, and compatibility indicator values.

interoperability-note §8

RFC 6381 obsoletes RFC 4281 in a backwards-compatible manner. Key changes include: added the 'profiles' parameter; fixed a BNF error where the grammar did not correspond to examples or common usage; added AVC family sub-parameter definitions; added a security consideration for codec download triggers; and improved MIME type applicability clarifications.

interoperability-note §3.5

The 'codecs' parameter MAY be specified for additional MIME media types beyond those listed. For ISO-family formats using the existing namespace, only the media type registration needs updating. For formats requiring an expanded namespace or non-ISO-family formats, a new document MAY update RFC 6381 by specifying the additional namespace.

normative-requirement §3.1 MUST

Although the encoder MUST create parameter values that are complete and accurate in 'breadth' (reporting all four-character codes used in all tracks), receivers MUST NOT rely on the parameter values being complete in 'depth', since hierarchical rules for a codec code may have been written after a server was implemented.

normative-requirement §4.4 MUST

For any file carrying a brand registered at MP4RA (notably ISO Base Media File Format and QuickTime files), the 'profiles' parameter MUST list exactly the major-brand first, followed by the compatible-brands, as listed in the filetype box ('ftyp') or segment-type box ('styp'). The major-brand MAY be removed from the compatible-brands list for compactness.

registry

normative-requirement §3.1 SHOULD

If a receiver encounters a body part whose 'codecs' parameter contains codecs not indicated by any media elements, the receiver SHOULD process the body part by discarding the information in the 'codecs' parameter. The body part itself is definitive of the actual codecs needed; the parameter is informative only.

normative-requirement §3.2 MUST NOT

Implementations MUST NOT add comments and/or folding white space (CFWS) between the tokens of a 'codecs' parameter value except after a comma separator.

normative-requirement §3.1 SHOULD

The 'codecs' parameter SHOULD only be used for MPEG-21 files (application/mp21) when timed, coded material (a top-level 'moov' atom) is also present in the file, as MPEG-21 files may but are not required to contain such material.

normative-requirement §3.1 MUST

When the 'codecs' parameter is used, it MUST contain all codecs indicated by the content present in the body part. The 'codecs' parameter MUST NOT include any codecs that are not indicated by any media elements in the body part.

normative-requirement §4.2 SHOULD

When the definition for use of the 'profiles' parameter is defined for a given format, that definition SHOULD indicate that the parameter directly reflects information in the body part and does not convey information beyond what can be learned by inspecting the body part. The body part is definitive; the parameter is informative.

normative-requirement §3.1 MUST

When the RFC 2231 encoded form ('codecs*') is used, the percent sign, asterisk, and single quote characters have special meaning and MUST themselves be percent encoded. The language element SHOULD be omitted and the character set SHOULD also be omitted.

protocol-element §3.1

The 'codecs' parameter is an optional MIME parameter whose value is a single codec identifier or a comma-separated list. Each identifier consists of one or more dot-separated elements where the first element's namespace is determined by the MIME type and subsequent elements' namespaces are determined by the preceding element.

protocol-element §4.2

The 'profiles' parameter is an OPTIONAL MIME parameter whose value is a single profile identifier or a comma-separated list of identifiers indicating the profile(s) of the overall container format to which the file claims conformance. It applies to box-structured files with an initial box containing compatibility brands (ISO Base Media File Format and QuickTime families).

registry §5

IANA has replaced references to RFC 4281 with references to RFC 6381 in the 'MIME Media Types' registry, indicating that the 'codecs' and/or 'profiles' parameters are optional for: audio/3gpp, video/3gpp (RFC 3839); audio/3gpp2, video/3gpp2 (RFC 4393); audio/mp4, video/mp4, application/mp4 (RFC 4337); video/quicktime; application/mp21.

registry

security-consideration §7

An incorrect 'codecs' parameter can cause content to be sent to an incapable device or withheld from a capable one, enabling denial-of-service attacks. However, this is most likely accidental; an attacker capable of altering media in transit could cause more harm by altering the media format itself or the full Content-Type header rather than just the 'codecs' parameter.

security

security-consideration §7

To the extent that a receiver reacts to a 'codecs' parameter indicating an unsupported codec by fetching and installing the required codecs, such action must be performed carefully and in accord with the system's normal validity and security checks and procedures.

security

wire-format §3.3

For ISO Base Media File Format and QuickTime, the first element of a 'codecs' value is a four-character sample description entry code registered at MP4RA (case sensitive). For 'mp4a' (MPEG-4 audio), the second element is the two-hex-digit OTI, and for OTI 40 (MPEG-4 audio) the third element is the decimal audio ObjectTypeIndication—e.g., 'mp4a.40.2' for AAC-LC.

mpls

wire-format §3.3

For 'mp4v' (MPEG-4 part-2 video) with OTI 20, the third element is the decimal VideoProfileLevelIndication—e.g., 'mp4v.20.9' for MPEG-4 Visual Simple Profile Level 0. For AVC family entries ('avc1', 'avc2', 'svc1', 'mvc1', 'mvc2'), the second element ('avcoti') is 6 hex digits encoding profile_idc, constraint_set flags byte, and level_idc from the SPS NAL unit.

wire-format §3.2

The 'codecs' parameter has two forms: 'codecs' (unencodedv) for values not requiring encoding, and 'codecs*' (encodedv, per RFC 2231) for values with octets requiring percent-encoding. Both support single values and comma-separated lists; dot ('.') is reserved as a hierarchy delimiter within each codec identifier.

wire-format §3.4

The ISO-family BNF defines: iso-mpega := mp4a '.' oti ['.' aud-oti]; iso-mpegv := mp4v '.' oti ['.' vid-pli]; iso-avc := (avc1|avc2|svc1|mvc1|mvc2) ['.' avcoti], where oti is 2 hex digits, avcoti is 6 hex digits, aud-oti and vid-pli are decimal strings. The leading '0x' from MP4RA OTI notation is omitted.

wire-format §4.5

The 'profiles' parameter BNF mirrors the 'codecs' parameter: pro-simple := 'profiles' '=' unencodedv; pro-fancy := 'profiles*' '=' encodedv, reusing the same unencodedv and encodedv productions defined for 'codecs'. The namespace is determined by the MIME type.