the iamf.* codecs parameter

grammar

Per IAMF §6.4, the codecs parameter string for an IAMF track SHALL be:

iamf.<primary_profile>.<additional_profile>.<sub-codec codecs elements>

1. The first element is the fourcc iamf.
2. The second element indicates the primary_profile — three digits in the range 0 to 255.
3. The third element indicates the additional_profile — three digits in the range 0 to 255.
4. The fourth element (and any additional elements) SHALL be the elements of the codecs parameter string the stream would carry in its own track, unencapsulated.

The spec's own examples: iamf.xxx.yyy.Opus, iamf.xxx.yyy.mp4a.40.2, iamf.xxx.yyy.fLaC, iamf.xxx.yyy.ipcm, where xxx/yyy are the three-digit profile fields.

field reference

chromium parser behavior

Chromium's ParseIamfCodecId (compiled when IAMF audio is enabled) accepts a string as IAMF when:

• it starts with iamf — and, “for test purposes only”, the bare string iamf with no further elements is accepted;
• otherwise it must split into at least four period-delimited elements: iamf, a three-digit primary profile ≤ 255, a three-digit additional profile ≤ 255, and a sub-codec element;
• the sub-codec element (lower-cased) must be exactly opus, mp4a, flac, or ipcm; for mp4a two further elements are required — object type indication hex 40 and audio object type hex 2 (i.e. AAC-LC);
• the whole string is length-capped (fourcc + two profile fields + one sub-codec element at most).

Strings that fail parsing are simply not recognized as IAMF (support queries fall through to “unrecognized codec id”). A code comment (crbug.com/438106645) records that profile handling after parsing is still to be completed, “especially if [IAMF streams] end up containing xHE-AAC audio” — so profile fields currently identify the family rather than gate fine-grained capability.

examples

Rejected by the Chromium parser (non-exhaustive): iamf.0.0.opus (profile fields must be three digits), iamf.256.000.opus (profile > 255), iamf.000.000.vorbis (sub-codec not in the accepted set), iamf.000.000.mp4a (mp4a requires the 40.2 fields), and any string with extra elements beyond the length cap.

// Feature-detect a specific packaging before fetching media:
const candidates = [
  'audio/mp4; codecs="iamf.000.000.opus"',
  'audio/mp4; codecs="iamf.001.001.mp4a.40.2"',
];
const supported = candidates.find((m) => MediaSource.isTypeSupported(m));
if (!supported) throw new Error('no supported IAMF packaging');
const sourceBuffer = mediaSource.addSourceBuffer(supported);

usage context

The parameter appears wherever an MP4 MIME type is declared for MSE: MediaSource.isTypeSupported(mime) support queries and MediaSource.addSourceBuffer(mime). Chromium registers the iamf and iamf.* codec patterns for both audio/mp4 and video/mp4 containers (stream_parser_factory.cc), so an IAMF audio track can ride alongside video in the same MP4 or be delivered audio-only. It has no meaning for direct file playback (<audio src>), which does not route through the IAMF-capable parser in the sources read — delivery is MSE-only, matching the explainer’s framing (“zero changes to existing MSE workflows”).

compatibility

Interim table. No BCD or web-features entry exists for the iamf codecs string (2026-07-29); rows are compiled from the linked primary sources.

security and privacy

• The string is declarative metadata: it describes the bitstream a page intends to append and reveals nothing about the user beyond the same codec-support bit every MSE codec exposes.
• Parser robustness for malformed strings is bounded — unknown or malformed values fail closed (treated as unsupported) rather than producing partial matches.
• The bitstream-level security considerations (software decoding of remote media) are covered on the overview.

see also

• IAMF decoding support — overview
• AOM IAMF specification (v1.1.0) · v1.0.0
• Chrome Platform Status — feature 5113656292540416
• RFC 6381 — 'Codecs' and 'Profiles' parameters