RTCRtpCapabilities

The RTCRtpCapabilities dictionary is a data type used to describe the capabilities of an RTCRtpSender or RTCRtpReceiver in response to a call to the RTCRtpSender.getCapabilities() or RTCRtpReceiver.getCapabilities() static functions, both of which return an array of RTCRtpCapabilities objects.

An RTCRtpCapabilities object contains an array of objects conforming to RTCRtpCodecCapability (each describing the capabilities of one codec) and an array of the supported RTP header extensions for that codec.

Properties

codecs

An array of RTCRtpCodecCapability objects, each describing one of the codecs supported by the RTCRtpSender or RTCRtpReceiver. There are some special entries in this array, described below in the section The codecs array.

headerExtensions

An array of objects conforming to the RTCRtpHeaderExtensionCapability dictionary. Each object contains a single DOMString, uri, specifying the URI of the header extension, as described in RFC 5285.

Description

The codecs array

The codecs array is an array of objects conforming to the dictionary RTCRtpCodecCapability. Each of these objects describes a single codec and its basic capabilities. Its properties are:

channels Optional

An unsigned integer value indicating the maximum number of channels supported by the codec; for example, a codec that supports only mono sound would have a value of 1; stereo codecs would have a 2, etc.

clockRate

An unsigned long integer specifying the codec's clock rate in Hertz (Hz). The IANA maintains a list of codecs and their parameters, including their clock rates.

mimeType

A DOMString indicating the codec's MIME media type and subtype. See Codecs used by WebRTC for details about potential codecs that might be referenced here.

sdpFmtpLine Optional

A DOMString giving the format specific parameters field from the a=fmtp line in the SDP which corresponds to the codec, if such a line exists. If there is no parameters field, this property is left out.

The browser will only report distinct capability combinations separately. If two sets of capabilities can be described as one, they will be. That means that, for instance, if there are two entries for the H.264 codec (as identified by the mimeType being "video/H264"), there are other values in the capabilities objects indicating how they're different in some way.

There are three special entries that should always be present, representing underlying components of the transport. Those components are:

RED (REDundant Audio Data)

The media type of an RED entry may vary due to there being several versions of it, but it will end with red, such as video/red or video/fwdred. The base RED standard can be found in RFC 2198. There may be multiple entries for RED if different forms are supported; each will have a unique media type in that case.

FEC (Forward Error Correction)

An FEC component handles error correction data; its media type may also vary due to there being advanced versions of the standard available, but it will always end with fec. One possible value is video/ulpfec (a generic error connection model). There may also be multiple FEC entries if more than one form is supported.

RTX (Retransmission)

This component is responsible for retransmission of data; it's media type should be video/rtx. There will only be one entry for RTX, and it will not have an sdpFmtpLine property.

Don't be surprised to see these show up ijn the list; be prepared to ignore them if you're only interested in the actual codecs used for the media itself.

Specifications

Browser compatibility