One document matched: draft-gellens-mime-bucket-bis-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2912.xml">
<!ENTITY RFC2231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2231.xml">
<!ENTITY RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC3625 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3625.xml">
<!ENTITY RFC2506 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2506.xml">
]>
<rfc category="std" ipr="trust200902" docName="draft-gellens-mime-bucket-bis-05.txt" obsoletes="4281">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="MIME codecs and profiles">The Codecs and Profiles Parameters for "Bucket" Media Types</title>
<author initials='R.G.' surname="Gellens" fullname='Randall Gellens'>
<organization>QUALCOMM Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city> <region>CA</region> <code>92121</code>
<country>US</country>
</postal>
<email>randy@qualcomm.com</email>
</address>
</author>
<author initials='D.S.' surname="Singer" fullname='David Singer'>
<organization>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city> <region>CA</region> <code>95014</code>
<country>US</country>
</postal>
<phone>+1 408 996 1010</phone>
<email>singer@apple.com</email>
</address>
</author>
<author initials='P.F.' surname="Frojdh" fullname='Per Frojdh'>
<organization>Ericsson Research</organization>
<address>
<postal>
<street>Multimedia Technologies SE-164</street>
<city>Stockholm</city> <code>80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 7190000</phone>
<email>Per.Frojdh@ericsson.com</email>
</address>
</author>
<date month="June" year="2011"/>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract><t>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.
</t><t>This document specifies two parameters, "codecs" and "profiles", which are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs and/or profiles employed by the media formats contained within. 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.
</t><t>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.)</t>
<t>Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. 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.</t>
</abstract>
</front>
<middle>
<section anchor="sec-1" title="Introduction">
<t>
One of the original motivations for MIME is the ability to identify
the specific media type of a message part. However, due to various
factors, it is not always possible from looking at the MIME type and
subtype to know which specific media formats are contained in the
body part, or which codecs are indicated in order to render the
content.
</t><t>
There are several media type/subtypes (either currently registered or
deployed with registration pending) that contain codecs chosen from a
set. In the absence of the parameters described here, it is necessary to examine each media element in
order to determine the codecs or other features required to render the content. For
example, video/3gpp may contain any of the video formats H.263
Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any
of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate -
WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or
Enhanced aacPlus, as specified in <xref target="3GPP-Formats" />.
</t><t>
In some cases, the specific codecs can be determined by examining the
header information of the media content. While this isn't as bad as
examining the entire content, it still requires specialized knowledge
of each format and is resource consumptive.
</t><t>
This ambiguity can be a problem for various clients and servers. For example, it presents a significant burden to Multimedia Messaging (MMS) servers,
which must examine the media sent in each message in order to
determine which codecs are required to render the content. Only then
can such a server determine if the content requires transcoding or
specialized handling prior to being transmitted to the handset.
</t><t>
Additionally, it presents a challenge to smart clients on devices
with constrained memory, processing power, or transmission bandwidth
(such as cellular telephones and PDAs). Such clients often need to
determine in advance if they are currently capable of rendering the
content contained in an MMS or email message.
</t><t>
Ambiguity:
</t><t><list style="symbols">
<t>audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in <xref target="3GPP-Formats" />.</t>
<t>audio/3gpp2 can contain AMR, AAC, 13K (as per <xref target="RFC3625" />), Enhanced Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV),
or VMR-WB, as specified in <xref target="3GPP2-Formats" />.</t>
<t>video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC,
or Enhanced aacPlus, as specified in <xref target="3GPP-Formats" />.</t>
<t>video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per <xref target="RFC3625" />), EVRC, SMV, or VMR-WB, as specified in <xref target="3GPP2-Formats" />.</t>
<t>audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 or registered at the <xref target="MP4RA">MP4
registration authority</xref>.</t>
<t>video/mp4 has the same issues as audio/mp4, and in addition many video codecs, and especially the MPEG codecs, have a variety of profiles and levels, not all of which are supported by every implementation.</t>
</list>
</t><t>
Note that there are additional media types that are ambiguous, but
are outside the scope of this document, including:
</t><t><list style="symbols">
<t>video/mpeg4-generic, which can contain anything allowed by the MPEG-4 specification, or any codec registered with the <xref target="MP4RA">MP4
registration authority</xref>;</t>
</list>
</t><t>
With each "bucket" type, a receiving agent only knows that it has a
container format. It doesn't even know whether content labeled
video/3gpp or video/3gpp2 contains video; it might be audio only,
audio and video, or video only.
</t><t>
A solution that permits a receiving agent to determine the specific
codecs or profiles required to render media content would help provide efficient
and scalable servers, especially for Multimedia Messaging (MMS), and
aid the growth of multimedia services in wireless networks.
</t>
</section>
<section anchor="sec-2" title="Conventions Used in This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" <xref target="RFC2119" />
.
</t><t>
The syntax in this document uses the BNF rules specified in
<xref target="RFC2045" /> and <xref target="RFC2231" />.
</t>
</section>
<section anchor="sec-3" title="The Codecs Parameter">
<section anchor="sec-3.1" title="Introduction">
<t>
This section adds a parameter to allow unambiguous specification of
all codecs indicated to render the content in the MIME part. This
parameter is optional in all current types to which it is added.
Future types that contain ambiguity are strongly encouraged to
include this parameter.</t>
<t>This parameter applies to:
<list style='numbers'>
<t>Files in the family based on the ISO Base Media File Format <xref target="ISO14496-12" />.</t>
<t>The QuickTime file format, owned by Apple Inc.</t>
</list></t>
<t>This includes the media types:
<list style='numbers'>
<t>audio/3gpp, video/3gpp</t>
<t>audio/3gpp2, video/3gpp2</t>
<t>audio/mp4, video/mp4, application/mp4</t>
<t>video/quicktime</t>
<t>application/mp21 (see note below)</t>
</list></t>
<t>Note that MPEG-21 files under the type application/mp21 may, but are not required to, contain a top-level 'moov' atom providing a timed, coded, resource. The codecs parameter SHOULD only be used for MPEG-21 files when this timed material is also present in the file.</t>
<t>
Parameter name:
codecs
</t><t>
Parameter value: A single value, or a comma-separated list of values
identifying the codec(s) indicated to render the content in the
body part.
</t><t>
Each value consists of one or more dot-separated elements. The
name space for the first element is determined by the MIME type.
The name space for each subsequent element is determined by the
preceding element. The precise syntax is given below in the <xref target="sec-3.2">Generic Syntax</xref>.
</t><t>
Note that, per <xref target="RFC2045" />, some characters (including the
comma used to separate multiple values) require that the entire
parameter value be enclosed in quotes.
</t><t>
An element MAY include an octet that <xref target="RFC2045" /> REQUIRES to be encoded. In this case, <xref target="RFC2231" /> is used:
an asterisk ("*") is placed at the end of the parameter name
(becoming "codecs*" instead of "codecs"), the parameter value
usually starts with two single quote ("'") characters
(indicating that neither character set nor language is
specified), and each octet that requires encoding is represented
as a percent sign ("%") followed by two hexadecimal digits.
Note that, when the <xref target="RFC2231" /> form is used, the percent
sign, asterisk, and single quote characters have special meaning
and so MUST themselves be encoded.
</t><t><figure><artwork>
Examples of Generic Syntax:
codecs=a.bb.ccc.d
codecs="a.bb.ccc.d, e.fff"
codecs*=''fo%2e
codecs*="''%25%20xz, gork"
</artwork></figure></t><t>
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.
</t><t>
In some cases, not all indicated codecs are absolutely required in
order to render the content. Therefore, when a receiver does not
support all listed codecs, special handling MAY be required. For
example, the media element(s) MAY need to be examined in order to
determine if an unsupported codec is actually required (e.g., there
may be alternative tracks (such as English and Spanish audio), there
may be timed text that can be dropped, etc.)
</t><t>
NOTE: Although the parameter value MUST be complete and accurate in
'breadth' (that is, it MUST report all four-character codes used in
all tracks for ISO-family files, for example) systems MUST NOT rely
on it being complete in 'depth'. If the hierarchical rules for a
given code (e.g., 'qvxy') were written after a server was
implemented, for example, that server will not know what elements to
place after 'qvxy'.
</t><t>
If a receiver encounters a body part whose codecs parameter contains
codecs that are not indicated by any media elements, then the
receiver SHOULD process the body part by discarding the information
in the codecs parameter.
</t><t>
If a receiver encounters a body part whose codecs parameter does not
contain all codecs indicated by the media elements, then the receiver
MAY process the body part by discarding the information in the codecs
parameter.
</t></section>
<section anchor="sec-3.2" title="Generic Syntax">
<t>
The codecs parameter takes either of two forms. The first form is
used when the value does not contain any octets that require
encoding. The second form uses <xref target="RFC2231" />
to allow arbitrary
octets to be encoded. With either form, quotes allow for commas and
other characters in <tspecials> (quotes MAY be used even when not
required).
</t><t>
This BNF uses the rules specified in <xref target="RFC2045" />
and <xref target="RFC2231" />
.
</t><t>
Implementations MUST NOT add CFWS between the tokens except after
",". TOKEN is defined in <xref target="RFC2045" />, and <ext-octet> and <attribute-char> are defined in <xref target="RFC2231" />.</t>
<t>The BNF syntax is as follows:</t>
<t><figure><artwork>
codecs := cod-simple / cod-fancy
cod-simple := "codecs" "=" unencodedv
unencodedv := id-simple / simp-list
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
id-simple := element
; "." reserved as hierarchy delimiter
element := 1*octet-sim
octet-sim := <any TOKEN character>
; Within a codecs parameter value, "." is reserved
; as a hierarchy delimiter
cod-fancy := "codecs*" ":=" encodedv
encodedv := fancy-sing / fancy-list
fancy-sing := [charset] "'" [language] "'" id-encoded
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
id-list := id-encoded *( "," id-encoded )
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
encoded-elm := 1*octet-fancy
octet-fancy := ext-octet / attribute-char
DQUOTE := %x22 ; " (double quote)
</artwork></figure></t>
<t>
Initial name space: This document only defines values for files in
the ISO Base Media File Format, and QuickTime, families. Other file formats may also
define codec naming.
</t>
</section>
<section anchor="sec-3.3" title="ISO File Format Name Space">
<t>
For the ISO Base Media File Format, and the QuickTime movie file format, the first element of a codecs
parameter value is a sample description entry four-character code as
registered by the MP4 Registration Authority <xref target="MP4RA" />. Values are
case sensitive.
</t><t>
Note that there are potentially multiple tracks in a file, each
potentially carrying multiple sample entries (some but not all uses
of the ISO File Format restrict the number of sample entries in a
track to one).
</t><t>
When the first element of a value is 'mp4a' (indicating some kind of
MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2
video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams such as MPEG-4 BIFS), the second element is the hexadecimal representation of the
MP4 Registration Authority ObjectTypeIndication (OTI), as specified
in <xref target="MP4RA" /> and <xref target="MP41" /> (including amendments). Note that <xref target="MP4RA" />
uses a leading "0x" with these values, which is omitted here and
hence implied.
</t><t>
One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio).
For this value, the third element identifies the audio
ObjectTypeIndication (OTI) as defined in <xref target="MP4A" /> (including
amendments), expressed as a decimal number.
</t><t>
For example, AAC low complexity has the value 2, so a complete
string for AAC-LC would be "mp4a.40.2".
</t><t>
One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2
video). For this value, the third element identifies the video
ProfileLevelIndication as defined in <xref target="MP4V" /> (including amendments),
expressed as a decimal number.
</t><t>
For example, MPEG-4 Visual Simple Profile Level 0 has the value 9,
so a complete string for MPEG-4 Visual Simple Profile Level 0 would
be "mp4v.20.9".
</t><t>
When the first element of a value is a code indicating a codec from the Advanced Video Coding specification <xref target="AVC" />, specifically one of the sample entries defined in <xref target="AVC-Formats" /> (such as 'avc1', 'avc2', 'svc1', 'mvc1' and 'mvc2') - indicating AVC (H.264), Scalable Video Coding (SVC) or Multiview Video Coding (MVC), the second element (referred to as 'avcoti' in the formal syntax) is the hexadecimal representation of the following three bytes in the (subset) sequence parameter set NAL unit specified in <xref target="AVC" />:</t>
<t><list style="format (%d)">
<t>profile_idc, </t>
<t>the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits) and</t>
<t>level_idc. </t>
</list></t>
<t>Note that the sample entries 'avc1' and 'avc2' do not necessarily indicate that the media only contains AVC NAL units. In fact, the media may be encoded as an SVC or MVC profile and thus contain SVC or MVC NAL units. In order to be able to determine which codec is used further information is necessary (profile_idc). Note also that reserved_zero_2bits is required to be equal to 0 in <xref target="AVC" />, but other values for it may be specified in the future by ITU-T or ISO/IEC.</t><t>
This is as previously defined in the 3GPP File Format specification <xref target="3GPP-Formats">3GPP TS 26.244</xref>, section A.2.2. </t>
<t>When SVC or MVC content is coded in an AVC-compatible fashion, the sample description may include both an AVC configuration record and an SVC or MVC configuration record. Under those circumstances, it is recommended that the two configuration records both be reported as they may contain different AVC profile, level, and compatibility indicator values. Thus the codecs reported would include the sample description code (e.g. 'avc1') twice, with the values from one of the configuration records forming the 'avcoti' information in each.</t>
</section>
<section anchor="sec-3.4" title="ISO Syntax">
<figure><artwork>
id-simple :=/ id-iso
id-encoded :=/ id-iso
id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc
iso-gen := cpid *( element / encoded-elm )
; <element> used with <codecs-simple>
; <encoded-elm> used with <codecs-fancy>
;
; Note that the BNF permits "." within <element>
; and <encoded-elm> but "." is reserved as the
; hierarchy delimiter
iso-mpega := mp4a "." oti [ "." aud-oti ]
iso-mpegv := mp4v "." oti [ "." vid-pli ]
iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ]
cpid := 4(octet-simple / octet-fancy)
; <octet-simple> used with <codecs-simple>
; <octet-fancy> used with <codecs-fancy>
mp4a := %x6d.70.34.61 ; 'mp4a'
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
avc1 := %x61.76.63.31 ; 'avc1'
avc2 := %x61.76.63.32 ; 'avc2'
svc1 := %x73.76.63.31 ; 'svc1'
mvc1 := %x6d.76.63.31 ; 'mvc1'
mvc2 := %x6d.76.63.32 ; 'mvc2'
avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
aud-oti := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
</artwork></figure>
</section>
<section anchor="sec-4" title="Use in Additional Media Types">
<t>
This parameter MAY be specified for use with additional MIME media
types.
</t><t>
For ISO file formats where the name space as defined here is
sufficient, all that needs to be done is to update the media type
registration to specify the codecs parameter with a reference to this
document. For existing media types, it is generally advisable for
the parameter to be optional; for new media types, the parameter MAY
be optional or required, as appropriate.
</t><t>
For ISO file formats where the name space as defined here needs to be
expanded, a new document MAY update this one by specifying the
additional detail.
</t><t>
For non-ISO formats, a new document MAY update this one by specifying
the name space for the media type(s).
</t>
</section>
<section anchor="sec-5" title="Examples">
<t><figure><artwork>
Content-Type: video/3gpp2; codecs="sevc, s263"
(EVRC audio plus H.263 video)
Content-Type: audio/3gpp; codecs=samr
(AMR audio)
Content-Type: video/3gpp; codecs="s263, samr"
(H.263 video plus AMR audio)
Content-Type: audio/3gpp2; codecs=mp4a.E1
(13k audio)
Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
(MPEG-4 Visual Simple Profile Level 0 plus 13K voice)
Content-Type: video/mp4; codecs="avc1.640028"
(H.264/AVC video, High Profile, Level 40,
e.g. DVB 720p 50Hz HDTV)
Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E"
(SVC video, Scalable High Profile, Level 30,
with a Main Profile AVC base layer, e.g. DVB 25 Hz SDTV)
Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030"
(MVC video, Stereo High Profile, Level 42,
with a High Profile base layer, e.g. as adopted in Blu-ray)
</artwork></figure></t><t>
Note: OTI value 20 ("0x20" in <xref target="MP4RA" />) says "Includes
associated Amendment(s) and Corrigendum(a). The actual object
types are defined in <xref target="MP4V" /> and are conveyed in the
DecoderSpecificInfo as specified in <xref target="MP4V" />, Annex K."
(references adjusted).
</t>
</section>
<section anchor="sec-6" title="Additional Media Feature Details">
<t>
It is sometimes helpful to provide additional details for a media
element (e.g., the number of X and Y pixels, the color depth, etc.).
These details are sometimes called "media features" or "media
characteristics".
</t><t>
When such additional features are included, the content-features <xref target="RFC2912" /> header provides a handy way to do so.
</t>
</section>
</section>
<section anchor="sec-7" title="The Profiles Parameter">
<section title="Introduction">
<t>Just as some codecs have a variety of profiles (subsets of their functionality within which a bitstream can be coded), so also some media files can be profiled, and be associated with one or more profile identifiers of the profiles to which they conform. These profiles can indicate features of the file format itself, which codecs may be present, the profiles of those codecs, and so on. It can be advantageous to a receiving system to know the overall file profile(s) of a file; indeed, under these circumstances it may not be necessary to know the codecs themselves if they are implied by the profile.</t>
</section>
<section title="Formal Declaration">
<t>
This section adds a parameter to allow unambiguous specification of
the profiles to which a file claims conformance. This
parameter is optional in all current types to which it is added.</t>
<t>This parameter applies to:
<list style='numbers'>
<t>Box-structured (also known as atom-structured) files that have an initial box containing compatibility brands, as registered at the <xref target="MP4RA">MP4 Registration Authority</xref>, such as a filetype or segment-type box. This includes principally files in the family based on the <xref target="ISO14496-12">ISO Base Media File Format</xref>.</t>
<t>The QuickTime file format, owned by Apple Inc.</t>
</list></t>
<t>This includes the media types:
<list style='numbers'>
<t>audio/3gpp, video/3gpp</t>
<t>audio/3gpp2, video/3gpp2</t>
<t>audio/mp4, video/mp4</t>
<t>video/quicktime</t>
<t>application/mp21</t>
</list></t>
<t>
Parameter name:
profiles
</t><t>
Parameter value: A single value, or a comma-separated list of values
identifying the profiles(s) to which the file claims conformance.
</t><t>
The name space is determined by the MIME type.
</t><t>
Note that, per <xref target="RFC2045" />, some characters (including the
comma used to separate multiple values) require that the entire
parameter value be enclosed in quotes.
</t><t>
An element MAY include an octet that <xref target="RFC2045" /> REQUIRES to be encoded. In this case, <xref target="RFC2231" /> is used:
an asterisk ("*") is placed at the end of the parameter name
(becoming "profiles*" instead of "profiles"), the parameter value usually starts with two single quote ("'") characters(indicating that neither character set nor language is
specified), and each octet that requires encoding is represented
as a percent sign ("%") followed by two hexadecimal digits.
Note that, when the <xref target="RFC2231" /> form is used, the percent
sign, asterisk, and single quote characters have special meaning
and so MUST themselves be encoded.
</t><t><figure><artwork>
Examples of Generic Syntax:
profiles="isom,mp41,qvXt"
profiles*="''%25%20xz, gork"
</artwork></figure></t>
</section>
<section title="Profiles Parameter Definition">
<t>The 'profiles' parameter is an optional parameter that indicates one or more profiles to which the file claims conformance. Like the 'codecs' parameter described above, it may occur as either 'profiles' or 'profiles*', with the same encoding rules. The value is, as for the codecs parameter, a comma-separated list of profile identifiers. </t>
</section>
<section title="Profiles for files carrying registered brands">
<t>For any file format carrying a brand registered at the <xref target="MP4RA">MP4 Registration Authority</xref>, notably files based on the ISO Base Media File Format <xref target="ISO14496-12">ISO/IEC 14496-12</xref> and QuickTime movie files, the profiles parameter MUST list exactly the major brand, followed by the compatible-brands, as listed in the filetype box ('ftyp') or segment-type box ('styp'). The major-brand MUST be first, and MAY be removed from the compatible-brands list. (The file format requires that it be repeated in the compatible brands, but this requirement is relaxed here for compactness.)</t>
<t>An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 version 1 is the major brand and preferred use, that the file is compatible with the version of the base file format identified by 'isom', and that it is also compatible with the specification/profile 'qvXt' (whatever that may be).</t>
</section>
<section title="Profiles Parameter BNF Definition">
<t><figure><artwork>
profil := pro-simple / pro-fancy
pro-simple := "profiles" "=" unencodedv
; Within a codecs parameter value, "." is reserved
; as a hierarchy delimiter
pro-fancy := "profiles*" ":=" encodedv
</artwork></figure></t>
</section>
</section>
<section anchor="sec-8" title="IANA Considerations">
<t>
The IANA has added "codecs" and "profiles" as optional parameters to the media types as listed in Sections 3 and 4, with a reference to this document.
</t>
</section>
<section anchor="sec-9" title="Registration">
<t>
The MPEG4 Registration Authority can be consulted for the most up-to-date registration of sub-parameters for the codecs type, for specific codecs.
</t>
</section>
<section anchor="sec-10" title="Security Considerations">
<t>
The codecs parameter itself does not alter the security
considerations of any of the media types with which it is used. Each
audio and video media type has its own set of security considerations
that continue to apply, regardless of the use of the codecs
parameter.
</t><t>
An incorrect codecs parameter might cause media content to be
received by a device that is not capable of rendering it, or might
cause media content to not be sent to a device that is capable of
</t><t>
receiving it. An incorrect codecs parameter is therefore capable of
some types of denial-of-service attacks. However, this is most
likely to arise by accident, as an attacker capable of altering media
data in transit could cause more harm by altering the media format
itself, or even the content type header, rather than just the codecs
parameter of the content type header.
</t>
</section>
<section anchor="sec-11" title="Acknowledgements">
<t>
Harinath Garudadri provided a great deal of help, which is very much
appreciated. Mary Barnes and Bruce Lilly provided detailed and
helpful comments. Reviews and comments by Sam Hartman, Russ Housley,
and Bert Wijnen were much appreciated. Chris Newman carefully
reviewed and improved the BNF.</t><t>
Christian Timmerer helped with the MPEG-21 material, and Thomas Schierl and Yago Sanchez helped with SVC and MVC.
</t>
</section>
</middle>
<back><references title='Normative References'>
&RFC2119;
&RFC2912;
&RFC2231;
&RFC2045;
<reference anchor="ISO14496-12">
<front>
<title>Information technology — Coding of audio-visual objects — Part 12: ISO base media file format</title>
<author/>
</front>
<seriesInfo name="ISO/IEC" value="14496-12:2008" />
</reference>
<reference anchor="3GPP-Formats">
<front>
<title>Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)</title>
<author><organization>3rd Generation Partnership Project</organization></author>
</front>
<seriesInfo name="3GPP TS" value="26.244" />
</reference>
<reference anchor="MP4RA" target="http://www.mp4ra.org">
<front>
<title>MP4REG, The MPEG-4 Registration Authority</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="AVC">
<front>
<title>Advanced video coding for generic audiovisual services</title>
<author />
</front>
<seriesInfo name="ITU-T" value="Recommendation H.264" />
<seriesInfo name="ISO/IEC" value="14496-10:2009" />
</reference>
<reference anchor="AVC-Formats">
<front>
<title>Information technology — Coding of audio-visual objects — Part 15: Advanced Video Coding (AVC) file format</title>
<author/>
</front>
<seriesInfo name="ISO/IEC" value="14496-15:2010" />
</reference>
</references>
<references title='Informative References'>
&RFC3625;
<reference anchor="3GPP2-Formats" target="http://www.3gpp2.org/Public_html/specs/C.S0050-0_v1.0_121503.pdf">
<front>
<title>3GPP2 File Formats for Multimedia Service</title>
<author><organization>Third Generation Partnership Project 2</organization></author>
</front>
</reference>
<reference anchor="MP41">
<front>
<title>Information technology--Coding of audio-visual objects--Part 1: Systems</title>
<author />
</front>
<seriesInfo name="ISO/IEC" value="14496-1:2010" />
</reference>
<reference anchor="MP4A">
<front>
<title>Information technology--Coding of audio-visual objects--3: Audio</title>
<author />
</front>
<seriesInfo name="ISO/IEC" value="14496-3:2009" />
</reference>
<reference anchor="MP4V">
<front>
<title>Information technology--Coding of audio-visual objects--Part 2: Visual</title>
<author />
</front>
<seriesInfo name="ISO/IEC" value="14496-2:2004" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:19:56 |