RFC 6381

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

📅 published August 2011, from ietf

RFC 6381 🎀 is a standard from the IETF (Internet Engineering Task Force). Here's the paperwork, bestie:

  • Title: The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types 💖
  • Authors: R. Gellens (QUALCOMM, Inc.), D. Singer (Apple, Inc.), and P. Frojdh (Ericsson AB) 🫶
  • Category: Standards Track, ISSN: 2070-1721 📋
  • Published: August 2011 🗓️
  • It obsoletes RFC 4281 💀, which means it replaces that one.
  • It updates RFC 3839, RFC 4337, and RFC 4393 🔄

Abstract ✨

Okay so, a bunch of MIME type/subtype combos can hold different media formats inside them 📦. That means a receiving agent has to dig into the details of the content to figure out if it can actually render the elements, based on which codecs it has. It's a lot, especially when the end system has limited resources or the connection has limited bandwidth 😭. Being able to tell from the Content-Type alone whether the content can be rendered is so helpful.

This document specifies two parameters, 'codecs' and 'profiles' 🦋. They get used with various MIME types or type/subtype combinations so you can clearly say which codecs the media formats inside are using, or which profile(s) the overall container format follows. This document obsoletes RFC 4281. RFC 4281 defined the 'codecs' parameter, and this document keeps it backwards compatible with some minor clarifications ✨. The 'profiles' parameter is brand new in this document.

By labeling content with the exact codecs needed to render the media inside, receiving systems can check whether the end system supports those codecs 👀. If it doesn't, they can take action. They could reject the content, send a notification about it, transcode the content to a supported type, fetch and install the required codecs, or do further inspection to see if supporting just a subset of the listed codecs would be enough. Iconic problem-solving, honestly 💅.

Profiles work similarly. They give the receiver an overall idea of which specifications the content complies with 🌸. It shows how compatible the container format and its contents are with some specification. The receiver may be able to figure out how well it can handle and render the content by checking which of the declared profiles it supports, and what those profiles mean 🧚.

Status of This Memo 🔍

This is an Internet Standards Track document 💜.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 📚.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6381 🔗.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. The 'Codecs' Parameter ..........................................5
   3.1. Introduction ...............................................5
   3.2. Generic Syntax .............................................7
   3.3. ISO Base Media File Format Name Space ......................8
   3.4. ISO-Family Syntax .........................................11
   3.5. Use in Additional Media Types .............................11
   3.6. Examples ..................................................12
   3.7. Additional Media Feature Details ..........................12
4. The 'Profiles' Parameter .......................................12
   4.1. Introduction ..............................................12
   4.2. Formal Declaration ........................................13
   4.3. 'Profiles' Parameter Definition ...........................14
   4.4. Profiles for Files Carrying MP4RA-Registered Brands .......14
   4.5. 'Profiles' Parameter BNF Definition .......................15
5. IANA Considerations ............................................15
6. Registration ...................................................15
7. Security Considerations ........................................16
8. Differences from RFC 4281 ......................................16
9. Acknowledgements ...............................................17
10. References ....................................................17
   10.1. Normative References .....................................17
   10.2. Informative References ...................................18

1. Introduction 🌈

One of the original reasons MIME exists is so you can tell exactly what media type a message part is 🙌. But because of various factors, you can't always look at the MIME type and subtype and know which specific media formats are inside the body part, or which codecs are needed to render the content 🤷‍♀️.

There are several media type/subtypes (some already registered, some deployed with registration still pending) that hold codecs picked from a set 🎁. Without the parameters described here, you have to examine each media element to figure out the codecs or other features needed to render the content. For example, video/3gpp can contain any of these video formats: H.263 Profile 0, H.263 Profile 3, H.264, or MPEG-4 Simple Profile. It can also hold any of these 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 [3GPP-Formats] 🎬.

Sometimes you can figure out the specific codecs by checking the header information of the media content. That's not as bad as examining the whole thing, but it still needs specialized knowledge of each format and it's resource consumptive 🥱.

This ambiguity causes problems for lots of clients and servers 😬. For example, it's a big burden on Multimedia Messaging (MMS) servers, which have to examine the media sent in each message to figure out which codecs are required to render the content. Only then can such a server tell whether the content needs transcoding or special handling before it's sent to the handset 📱.

It's also a challenge for smart clients on devices with constrained memory, processing power, or transmission bandwidth (like cellular telephones and PDAs) 🔋. These clients often need to know in advance whether they can render the content in an MMS or email message.

Ambiguity:

  • audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or Enhanced aacPlus contents as specified in [3GPP-Formats] 🎶.
  • audio/3gpp2 can contain AMR, AAC, 13K (as per [RFC3625]), Enhanced Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or Variable Multi Rate WideBand (VMR-WB), as specified in [3GPP2-Formats].
  • 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 [3GPP-Formats].
  • 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 [RFC3625]), EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats].
  • audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4, or registered at the MP4 registration authority [MP4RA].
  • video/mp4 has the same issues as audio/mp4. On top of that, many video codecs, especially the MPEG codecs, have a variety of profiles and levels, and not every implementation supports all of them 🌀.

Also, there are more media types that are ambiguous but outside the scope of this document, including:

  • video/mpeg4-generic, which can contain anything allowed by the MPEG-4 specification, or any codec registered with the MP4 registration authority [MP4RA];

With each "bucket" type, a receiving agent only knows it has a container format 🪣. It doesn't even know whether content labeled video/3gpp or video/3gpp2 actually contains video. It might be audio only, audio and video, or video only 😵‍💫.

A solution that lets a receiving agent figure out the specific codecs or profiles needed to render media content would help build efficient, scalable servers, especially for Multimedia Messaging (MMS). It would also help multimedia services grow in wireless networks 🚀.

2. Conventions Used in This Document 📖

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" [RFC2119] 🔑.

The syntax in this document uses the BNF rules specified in [RFC2045] and [RFC2231] 🧩.

3. The 'Codecs' Parameter 🦋

Part 2 is coming up next, so keep scrolling 💜🫶

3.1. Introduction

okay so this section is the one that adds a codecs parameter, which lets you spell out exactly which codecs are needed to render the content in the MIME part 💅✨ no vague guessing!! it's OPTIONAL for every type it's been added to, but bestie, future types that could be ambiguous are strongly encouraged to include it 🫶

this parameter applies to:

  1. Files in the family based on the ISO Base Media File Format [ISO14496-12], which this spec calls "ISO family files" 🎀
  2. The QuickTime file format, owned by Apple, Inc. 🍎

and it covers these media types:

  1. audio/3gpp, video/3gpp [RFC3839]
  2. audio/3gpp2, video/3gpp2 [RFC4393]
  3. audio/mp4, video/mp4, application/mp4 [RFC4337]
  4. video/quicktime
  5. application/mp21 (see note below)
note on mp21: MPEG-21 files under application/mp21 may, but don't have to, have a top-level 'moov' atom carrying timed, coded resource stuff 🧚 the codecs parameter SHOULD only be used for MPEG-21 files when that timed material is also in the file. ngl that's a very specific vibe 😭

okay now the good stuff, the parameter itself 💖

Parameter name: codecs

Parameter value: a single value, or a comma-separated list of values, identifying the codec(s) that are indicated to render the content in the body part 🌸

each value is made of one or more dot-separated elements. the name space for the first element comes from the MIME type. the name space for each later element comes from the element right before it. full syntax is in the Generic Syntax part (Section 3.2) 🦋

also, per [RFC2045], some characters (including the comma used to separate values) mean the whole parameter value has to be wrapped in quotes 🎀

an element MAY include an octet that [RFC2045] requires encoding. if that happens, [RFC2231] kicks in: you put an asterisk (*) at the end of the parameter name (so it becomes codecs* instead of codecs), the value usually starts with two single quotes (') (meaning no charset or language is specified), and each octet that needs encoding becomes a percent sign (%) followed by two hex digits 💅 BUT when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters are special, so they MUST themselves be percent encoded. wild, I know 😭

examples of generic syntax:

codecs=a.bb.ccc.d
codecs="a.bb.ccc.d, e.fff"
codecs*=''fo%2e
codecs*="''%25%20xz, gork"

when the codecs parameter is used, it MUST contain ALL codecs indicated by the content in the body part. and it MUST NOT include any codecs that aren't indicated by any media elements in the body part. no extras, no missing ones, periodt 💀🔥

sometimes not every indicated codec is absolutely needed to render the content. so when a receiver doesn't support every listed codec, it might need special handling. for example, it could look at the media elements to see if the unsupported codec is actually required (like if there are alternative tracks, English and Spanish audio, or timed text that can just be dropped, etc.) 🌈

here's the tea 🍵: even though the encoder MUST make parameter values that are complete and accurate in 'breadth' (so the encoder MUST report all four-character codes used in all tracks for ISO family files, for example), receivers MUST NOT rely on the values being complete in 'depth'. like, if the hierarchical rules for a code (e.g., 'qvxy') were written after a server was already built, that server wouldn't know what elements to put after 'qvxy' 🙈

even though a mismatch isn't allowed by this spec, the body part is the source of truth for which codecs are actually needed, and the parameter is just informative 👑 if a receiver finds a body part whose codecs parameter lists codecs that aren't indicated by any media elements, the receiver SHOULD process the body part by throwing away the info in the codecs parameter 🫧

and if a receiver finds a body part whose codecs parameter does NOT contain all the codecs the media elements indicate, the receiver MAY process the body part by throwing away the info in the codecs parameter 🦄

3.2. Generic Syntax

the codecs parameter comes in one of two forms. the first form is used when the value has no octets that need encoding. the second form uses [RFC2231] so arbitrary octets can be encoded. either way, quotes let you use commas and other characters from <tspecials> (quotes MAY be used even when they aren't required) 🎀

this BNF uses the rules from [RFC2045] and [RFC2231] 🧠

while [RFC2231] lets you specify a character set and language, this parameter doesn't hold anything meant for humans, so it doesn't use language at all. the language element SHOULD be omitted, and the character set SHOULD also be omitted too 🌷 a receiver MAY ignore language, and MAY choose to only support US-ASCII [RFC1345] and UTF-8 [RFC3629] 💜

implementations MUST NOT add comments and/or folding white space (CFWS) between the tokens, except after "," 🙅‍♀️ TOKEN is defined in [RFC2045], and <ext-octet> and <attribute-char> are defined in [RFC2231] ✨

the BNF syntax goes like this:

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)

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, so keep an eye out 👀

3.3. ISO Base Media File Format Name Space

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 [MP4RA]. values are case sensitive, so watch those capitals 🔠

heads up: a file can have multiple tracks, and each track can carry multiple sample entries (some but not all uses of the ISO Base Media File Format limit a track to one sample entry) 🎬

when the first element is 'mp4a' (some kind of MPEG-4 audio), 'mp4v' (some kind of MPEG-4 part-2 video), or 'mp4s' (some kind of MPEG-4 Systems streams, like MPEG-4 BInary Format for Scenes (BIFS)), the second element is the hexadecimal representation of the MP4 Registration Authority ObjectTypeIndication (OTI), as specified in [MP4RA] and [MP41] (including amendments). note that [MP4RA] uses a leading "0x" with these values, but that's left out here and implied 🧁

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 [MP4A] (including amendments), written as a decimal number 🎧

for example, AAC low complexity (AAC-LC) has the value 2, so a complete string for AAC-LC would be "mp4a.40.2" 🦋

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 [MP4V] (including amendments), written as a decimal number 📺

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" 💖

when the first element is a code for a codec from the Advanced Video Coding specification [AVC], specifically one of the sample entries defined in [AVC-Formats] (like 'avc1', 'avc2', 'svc1', 'mvc1', and 'mvc2'), which means AVC (H.264), Scalable Video Coding (SVC), or Multiview Video Coding (MVC), the second element (called 'avcoti' in the formal syntax) is the hexadecimal representation of the following three bytes in the (subset) sequence parameter set Network Abstraction Layer (NAL) unit specified in [AVC]:

  1. profile_idc,
  2. the byte containing the constraint_set flags (currently constraint_set0_flag through constraint_set5_flag, and the reserved_zero_2bits), and
  3. level_idc.

note that the sample entries 'avc1' and 'avc2' don't necessarily mean the media only has AVC NAL units. the media might actually be encoded as an SVC or MVC profile, so it can contain SVC or MVC NAL units instead 🤯 to figure out which codec is really used, you need more info (profile_idc). also, reserved_zero_2bits is required to be equal to 0 in [AVC], but other values might be specified in the future by ITU-T or ISO/IEC 🔮

this is as previously defined in the 3GPP File Format specification 3GPP TS 26.244 [3GPP-Formats], Section A.2.2 📚

when SVC or MVC content is coded in an AVC-compatible way, the sample description can include both an AVC configuration record and an SVC or MVC configuration record. in that case, it is RECOMMENDED that both configuration records get reported, since they may have different AVC profile, level, and compatibility indicator values. so 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' info in each one 🫶🌈

3.4. ISO-Family Syntax ✨

okay so this is where the ISO family gets its own grammar 💅 the whole thing hangs off cpid (a 4-character code point ID) and then a bunch of little sub-IDs get tacked on. literally so pretty 🎀

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

3.5. Use in Additional Media Types 🦋

okay, the 'codecs' parameter isn't just for the types listed up top. it can totally show up on other media types too! this parameter MAY be specified for use with additional MIME media types.

for ISO family file formats where the name space defined here is good enough, all you have to do is update the media type registration so it specifies the 'codecs' parameter and points back at this document. for existing media types, it's generally advisable for the parameter to be optional. for brand-new media types, the parameter MAY be optional or required, whatever fits best 🌸

if an ISO family file format needs a bigger name space than the one defined here, a new document MAY update this one by spelling out the extra detail 🧚

and for non-ISO family file formats, a new document MAY update this one by specifying the name space for the media type(s) 💜

3.6. Examples 🍓

here are the examples, bestie, and they are giving so much detail 😭

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)
Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated Amendment(s) and Corrigendum(a). The actual object types are defined in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in [MP4V], Annex K." (references adjusted).

3.7. Additional Media Feature Details 🔥

sometimes you want to give extra info about a media element, like how many X and Y pixels there are, or the color depth. those bits are called "media features" or "media characteristics," and they're honestly iconic 👑

when you do include those extra features, the content-features [RFC2912] header is the handy way to go ✨

4. The 'Profiles' Parameter 💖

4.1. Introduction 🫶

so codecs have a bunch of profiles (subsets of their functionality that a bitstream can be coded within), and the same goes for media files! a file can be associated with one or more profile identifiers, which tell you which profiles it conforms to. these can point out file format features, which codecs might be inside, the profiles of those codecs, and more. it can be really useful for a receiving system to know the overall file profile(s), because if the codecs are implied by the profile, you might not even need to know the codecs themselves 🦋

the 'profiles' parameter reports on the profile(s) of the overall container format. a container profile can restrict not only the container's own features but also which codecs are allowed, and it can even restrict the profiles of those codecs. but the 'profiles' parameter doesn't directly report any profiles of the contained media. when codec-specific profiles get reported, that info lives in the 'codecs' parameter instead. so 'profiles' only covers the profile(s) that apply to the complete container 💅

when the 'profiles' parameter is defined for a given format, that definition SHOULD say it directly reflects information in the body part. it shouldn't convey anything beyond or different from what you'd learn by inspecting the body part. a mismatch isn't allowed by this spec, and the body part is the source of truth for the actual profiles. the parameter you supply is just informative 🌈

4.2. Formal Declaration 💜

this section adds a parameter so a file can unambiguously say which profiles it claims to conform to. this parameter is OPTIONAL in all current types it gets added to 🎀

this parameter applies to Box-structured (also called atom-structured) files that have an initial box with compatibility brands, as registered at the MP4 Registration Authority [MP4RA], like a filetype or segment-type box. mainly that means the family based on the ISO Base Media File Format [ISO14496-12], plus the QuickTime file format (owned by Apple, Inc.) 🍎 a brand can signal conformance with restrictions on which codecs and file format features get used, limits like the length or size of the file, and more.

this covers these media types:

  1. audio/3gpp, video/3gpp [RFC3839]
  2. audio/3gpp2, video/3gpp2 [RFC4393]
  3. audio/mp4, video/mp4 [RFC4337]
  4. video/quicktime
  5. application/mp21

Parameter name: profiles

Parameter value: A single value, or a comma-separated list of values identifying the profiles(s) to which the file claims conformance.

the name space is determined by the MIME type 🧚

note that, per [RFC2045], some characters (including the comma used to separate multiple values) mean the whole parameter value has to be wrapped in quotes 💅

an element MAY include an octet that [RFC2045] requires encoding. when that happens, [RFC2231] comes in clutch: you put an asterisk ("") at the end of the parameter name (so it becomes 'profiles' instead of 'profiles'), the value usually starts with two single quote ("'") characters (meaning neither character set nor language is specified), and each octet that needs encoding gets written as a percent sign ("%") followed by two hexadecimal digits. ngl that's a lot, but it's so precise 😭 and when the [RFC2231] form is used, the percent sign, asterisk, and single quote characters have special meaning, so they MUST themselves be percent encoded 🔥

Examples of Generic Syntax:
    profiles="isom,mp41,qvXt"
    profiles*="''%25%20xz, gork"

4.3. 'Profiles' Parameter Definition 🌸

the 'profiles' parameter is an OPTIONAL parameter that indicates one or more profiles the file claims conformance to. like the 'codecs' parameter we covered above, it can show up as either 'profiles' or 'profiles*', with the same encoding rules. the value is, same as for 'codecs', a comma-separated list of profile identifiers 🫶

4.4. Profiles for Files Carrying MP4RA-Registered Brands 🍓

for any file format carrying a brand registered at the MP4 Registration Authority [MP4RA], especially files based on the ISO Base Media File Format ISO/IEC 14496-12 [ISO14496-12] 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 it MAY be removed from the compatible-brands list. (the file format requires that it be repeated in the compatible-brands, but that requirement is relaxed here for compactness 🙈)

for example: profiles="mp41,isom,qvXt" means MPEG-4 version 1 is the major-brand and preferred use, the file is compatible with the version of the base file format identified by 'isom', and it's also compatible with the specification/profile 'qvXt' (whatever that may be 👀)

4.5. 'Profiles' Parameter BNF Definition ✨

profiles    := pro-simple / pro-fancy
pro-simple  := "profiles" "=" unencodedv
pro-fancy   := "profiles*" "=" encodedv

5. IANA Considerations 📋

IANA has replaced references to [RFC4281] with references to this document in the "MIME Media Types" registry. that means the 'codecs' and/or 'profiles' parameters are optional for these media types (as listed in Sections 3 and 4):

  1. audio/3gpp, video/3gpp [RFC3839]
  2. audio/3gpp2, video/3gpp2 [RFC4393]
  3. audio/mp4, video/mp4, application/mp4 [RFC4337]
  4. video/quicktime
  5. application/mp21

6. Registration 🦋

the MPEG4 Registration Authority is the place to check for the most up-to-date registration of sub-parameters for the codecs type, for specific codecs 💜

7. Security Considerations 🔐

okay this one is serious, so let's be careful 🫣

the 'codecs' parameter itself does not change the security considerations of any of the media types it's used with. each audio and video media type has its own set of security considerations that still apply, no matter whether 'codecs' is used or not.

an incorrect 'codecs' parameter might cause media content to be received by a device that can't render it, or might cause media content not to be sent to a device that could receive it. so an incorrect 'codecs' parameter is capable of some types of denial-of-service attacks. however, that's most likely to happen by accident, because an attacker who can alter media data in transit could do way more damage by changing the media format itself, or even the content type header, instead of just the 'codecs' parameter of the content type header 💀

to the extent that a receiver reacts to a 'codecs' parameter that indicates an unsupported codec by fetching and installing the required codecs, that reaction needs to be handled carefully and in accord with the system's normal validity and security checks and procedures 🛡️

8. Differences from RFC 4281 🌈

okay here's the tea on what changed since RFC 4281 🍵

  1. improved the introduction and other supporting and explanatory text;
  2. improved the references;
  3. clarified the MIME types to which the parameters apply, and clarified the consequent IANA actions;
  4. added the 'profiles' parameter;
  5. fixed an error in the BNF, where it did not correspond to either the examples or common usage;
  6. added the definition of the sub-parameters for the AVC family of codecs;
  7. added a security consideration for possible triggering of downloads;
  8. updated acknowledgments.

9. Acknowledgements ✨

okay bestie, the people who helped make this spec happen deserve a whole shoutout 🫶 Harinath Garudadri gave a ton of help, and it was SO appreciated 💖 Mary Barnes and Bruce Lilly left detailed, super helpful comments 🎀 Sam Hartman, Russ Housley, and Bert Wijnen reviewed it and their input was loved 🌸 and Chris Newman carefully went through and improved the BNF, which is literally the most iconic kind of help 👑

Christian Timmerer helped with the MPEG-21 material 🦋 and Thomas Schierl and Yago Sanchez helped with SVC and MVC 🧚 slay, every one of you 💅

10. References 📚

10.1. Normative References 💜

These are the references the spec leans on hardest, so no skipping, no cap 🔥

  • [3GPP-Formats]: 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244.
  • [AVC]: "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, ISO/IEC 14496-10:2009.
  • [AVC-Formats]: "Information technology -- Coding of audio-visual objects -- Part 15: Advanced Video Coding (AVC) file format", ISO/IEC 14496-15:2010.
  • [ISO14496-12]: "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2008.
  • [MP4RA]: "MP4REG, The MPEG-4 Registration Authority", <http://www.mp4ra.org>.
  • [RFC2045]: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2231]: Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
  • [RFC2912]: Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
  • [RFC3629]: Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC3839]: Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
  • [RFC4281]: Gellens, R., Singer, D., and P. Frojdh, "The Codecs Parameter for "Bucket" Media Types", RFC 4281, November 2005.
  • [RFC4337]: Y Lim and D. Singer, "MIME Type Registration for MPEG-4", RFC 4337, March 2006.
  • [RFC4393]: Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia Files", RFC 4393, March 2006.

10.2. Informative References 🦋

These are the nice-to-know extras, bestie, not required reading 🌈

  • [3GPP2-Formats]: Third Generation Partnership Project 2, "3GPP2 File Formats for Multimedia Service", <http://www.3gpp2.org/Public_html/specs/C.S0050-0_v1.0_121503.pdf>.
  • [MP41]: "Information technology--Coding of audio-visual objects -- Part 1: Systems", ISO/IEC 14496-1:2010.
  • [MP4A]: "Information technology--Coding of audio-visual objects -- 3: Audio", ISO/IEC 14496-3:2009.
  • [MP4V]: "Information technology--Coding of audio-visual objects -- Part 2: Visual", ISO/IEC 14496-2:2004.
  • [RFC1345]: Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, June 1992.
  • [RFC3625]: Gellens, R. and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003.

Authors' Addresses 🎀

Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 US

EMail: rg+ietf@qualcomm.com

David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 US

Phone: +1 408 996 1010 EMail: singer@apple.com

Per Frojdh Ericsson AB Ericsson Research Stockholm SE-164 80 Sweden

Phone: +46 10 7190000 EMail: Per.Frojdh@ericsson.com

📦 where this page comes from