{"id":428,"date":"2024-05-16T18:20:28","date_gmt":"2024-05-16T18:20:28","guid":{"rendered":"https:\/\/blog.mozilla.org\/webrtc\/?p=428"},"modified":"2024-06-26T14:04:35","modified_gmt":"2024-06-26T14:04:35","slug":"cross-browser-support-for-choosing-webrtc-codecs","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webrtc\/cross-browser-support-for-choosing-webrtc-codecs\/","title":{"rendered":"setCodecPreferences is now in all browsers!"},"content":{"rendered":"

WebRTC enables video calls directly in browsers. Effectively managing the codecs that encode and decode media streams is a crucial component of delivering high-quality audio and video. The setCodecPreferences<\/code><\/a> method allows developers to specify which codecs their applications prefer to receive. <\/p>\n

With Firefox Nightly 128, setCodecPreferences<\/code> is now available<\/a> in all browsers! Let’s explore how it functions, its implications for web developers, and its role in harmonizing browser behaviors.<\/p>\n

Firefox supporting this WebRTC 1.0 feature is a big deal. It helps webpages work the same across all browsers, eliminating browser-conditional code or having to resort to munging WebRTC’s signaling messages written in SDP<\/a>, by hand.<\/p>\n

But what made it seem blog-worthy was this question: do people know how it works? Looking at MDN<\/a> and recent spec changes<\/a> suggested not. Contrary to popular belief, it doesn’t control what you send. At least not directly.
\n<\/p>\n

How does setCodecPreferences work?<\/h2>\n

setCodecPreferences<\/code> is a method on a WebRTC transceiver. It lets webpages sort and filter the decoders to be considered when negotiating with a peer over a connection. The following illustrates a baseline for usage e.g. on a video transceiver:<\/p>\n

\r\ntransceiver.setCodecPreferences(RTCRtpReceiver.getCapabilities(\"video\").codecs)<\/code>\r\n<\/pre>\n
This sets the browser’s whole array of available decoders unmodified. Perhaps surprisingly, this is not<\/em> a no-op. It restricts the browser to consider all its codecs in this specific order. This technically differs from the default transceiver.setCodecPreferences([])<\/code> which doesn’t restrict the browser in this way. E.g. a browser may choose to leave out some codecs by default.<\/p>\n
It’s also an imperfect API for other reasons. The codecs<\/code> array contains a mix of real decoders (often repeated with different profile levels) along with special entries for features called RTX, RED and ULPFEC (thanks to JSEP<\/a>).<\/p>\n
As such, it’s not advisable to brute-force your own fixed array e.g. setCodecPreferences([h265, h264])<\/code>, as this would inadvertently disable RTX, RED and ULPFEC. Instead, we’ll demonstrate best practice: carefully sort the array, using a sortByMimeTypes(codecs, preferredOrder)<\/code> function below.<\/p>\n
setCodecPreferences sets what encodings you prefer to receive<\/em><\/h2>\n
The important part to remember is that setCodecPreferences<\/code><\/a> sets what media encodings you prefer to receive<\/em>, not what you want to send. Take this example:<\/p>\n