Do WebRTC encoding/decoding types have the single-codec restrictions?

The spec is being updated to reject audio and video MIME types that do not specify a single codec.

We should determine if browsers follow this logic when the encoding and decoding type is webrtc, by updating WPTs, and then discussing the desired behavior.

If they do not, we will have to fork the algorithms for determining the validity of a MIME type further.

WebRTC treats codecs as single entities, and uses WebRTC APIs to handle bundles of them.
Representing them as single codecs in capabilities sounds good to me.

I think the parameter restrictions for WebRTC single codec types should be relaxed. We can't pack the codec information into a MIME type string for a single codec, so for additional details e.g. profile level we need to include fmtp parameters. Without them, we're limited to raw codec type support only. Chrome and WPT already support/rely on fmtp attributes being supported.

@ashleyz

Prior to #222, parameters were allowed for webrtc mime types:

        Please note that the definition of MIME subtypes and parameters is
        context dependent. For {{file}}, {{media-source}}, and {{record}}, the
        MIME types are specified as defined for [[#http|HTTP]], whereas for
        {{MediaDecodingType/webrtc}} the MIME types are specified as
        defined for [[#rtp|RTP]].
(...)
          The MIME types used with RTP are defined in the specifications of the
          corresponding RTP payload formats [[RFC4855]] [[RFC6838]]. The codec
          name is typically specified as subtype and zero or more parameters
          may be present depending on the codec.

Chrome (146) and Safari (26.3.1) support parameters for WebRTC requests, against the current wording of the spec. As mentioned by @ashleyz, WPT still tests for this.

It seems reasonable to change the spec to allow parameters given that both Chrome and Safari has shipped support. I wanted to see how they behave wrt invalid parameters though, as that is a case that wasn't entirely clear prior to #222, and isn't part of the happy path.

It seems like most are ignored. A couple of examples:

await navigator.mediaCapabilities.encodingInfo({
  type: 'webrtc',
  audio: { contentType: 'audio/opus; stereo=2;foo=bar;maxplaybackrate=0' },
})

in Chrome gives

{powerEfficient: true, smooth: true, supported: true, keySystemAccess: null}

in Safari gives

{powerEfficient: false, smooth: false, supported: true, configuration: {audio: {contentType: "audio/opus; stereo=2;foo=bar;maxplaybackrate=0"}, type: "webrtc"}}

await navigator.mediaCapabilities.encodingInfo({
  type: 'webrtc',
  video: {
    contentType: "video/H264; profile-level-id=xxyyzz",
    width: 800,
    height: 600,
    bitrate: 3000,
    framerate: 24,
  }
})

in Chrome gives

{powerEfficient: false, smooth: false, supported: true, keySystemAccess: null}

in Safari gives

{powerEfficient: true, smooth: true, supported: true, configuration: Object}

but there's a difference in Chrome here with the supported profile-level-id=42e01f, which gives

{powerEfficient: false, smooth: true, supported: true, keySystemAccess: null}

not so much in Safari:

{powerEfficient: true, smooth: true, supported: true, configuration: Object}

It becomes difficult for an application to know which parameters are accounted for in the response, when there is no such feedback.

Not sure how restrictive the spec can become here on unsupported parameters given that Chrome already ships this. Safari seems to ignore them.

@ashleyz

Thanks for the investigation @ashleyz. There are two separate issues here:

Whether MC should accept multiple codecs for `webrtc` in a single call to `decodingInfo`

So far the feedback is "no".

Differences in implementations on how codec parameters are handled for `webrtc`

Chrome does take the codec parameters and maps them to SDP, before evaluating codec support.

For #2, it's not clear what the intention of the current spec is. The two references listed are:

https://www.iana.org/assignments/media-types/ lists all registered MIME types
RFC 6838 describes the syntax for MIME types but not what is considered valid for WebRTC

@chrisn it looks like you dropped the WebRTC specific RFC 4855 from the spec that describes how to map MIME types to WebRTC codec formats. Do you know what should be used instead?

If we have some algorithm for knowing what is a valid/invalid codec parameter for webrtc, we could add it to the spec.

I think the mismatch is the idea of a single set of "valid" mime types. The old language acknowledged two different kinds:

file/recording mime types, e.g. video/mp4;codecs="avc1.42e01f"
rtp transport mime types, e.g. video/H264;profile-level-id=42e01f

These use different disambiguation techniques to identify the uniquely supported codec configuration.

But the spec as written only works with (1) above:

This seems designed to allow only two valid outcomes from (1):

a combined type and subtype allowing a single codec, and empty parameters
a combined type and subtype allowing multiple codecs, but with a codecs=<single codec> disambiguator

The spec seems to assume the only purpose of parameters is to contain codecs=, but (2) relies on parameters to disambiguate the codec using syntax from sdpFmtpLine. So part of recognizing (2) needs to include dropping the "empty parameters" requirement.

... but there's a difference in Chrome here with the supported profile-level-id=42e01f, which gives ...

I see the same thing using https://jsfiddle.net/jib1/4wtvjsuz/17/ in Chrome.

If we have some algorithm for knowing what is a valid/invalid codec parameter for webrtc, we could add it to the spec.

There's no codecs parameter for webrtc. RFC8834 says webrtc uses only RTP payload formats, and RFC4855 defines how RTP payload formats are registered. Required/optional parameters are defined in those payload formats. Also note RFC9751 that directs to the Media Types registry for RTP payload formats.

Examples of these RTP payload formats that list parameters in the Media Types registry are:

rate tends to be required for audio formats (per RFC4855) but is perhaps redundant here. In sdp it's not provided through fmtp (e.g. a=rtpmap 111 opus/48000/2 or a=rtpmap 8 PCMA/8000; see sdp-anatomy), and here it's AudioConfiguration.samplerate?

@chrisn

@chrisn it looks like you dropped the WebRTC specific RFC 4855 from the spec that describes how to map MIME types to WebRTC codec formats. Do you know what should be used instead?

I think that's still the right one to use, so we should probably add it back. Confusion may have arisen because RTP Payload Format Media Types registry has been closed (per RFC9751).

If we have some algorithm for knowing what is a valid/invalid codec parameter for webrtc, we could add it to the spec.

I'd prefer if we can define this, yes.

[MediaCapabilities] Check MIME Type Validity should reject MIME types…

Add reference to RFC4855

Navigation Menu

Repository navigation

Do WebRTC encoding/decoding types have the single-codec restrictions? #238

Whether MC should accept multiple codecs for `webrtc` in a single call to `decodingInfo`

Differences in implementations on how codec parameters are handled for `webrtc`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Do WebRTC encoding/decoding types have the single-codec restrictions? #238

Description

Activity

alvestrand commented on Nov 14, 2025

ashleyz commented on Mar 4, 2026

Pehrsons commented on Mar 17, 2026

markafoltz commented on Mar 17, 2026

Whether MC should accept multiple codecs for webrtc in a single call to decodingInfo

Differences in implementations on how codec parameters are handled for webrtc

jan-ivar commented on Mar 17, 2026

Pehrsons commented on Mar 17, 2026

chrisn commented on Mar 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Whether MC should accept multiple codecs for `webrtc` in a single call to `decodingInfo`

Differences in implementations on how codec parameters are handled for `webrtc`