WebRTC Community Update - Codecs, bugs, screensharing and super resolution!

daginge Moderator, Daily Alumni
edited March 2023 in Tech Updates

Welcome to a new edition of our WebRTC Community update!

Today we’ll update you on alternative codecs in WebRTC, a resolution to the Firefox bug we reported, screensharing privacy improvements in Chrome, and Nvidia super resolution support for the web.

If you have questions, please ask in the comments!

Alternative codecs in WebRTC start getting traction

WebRTC has come a long way since its inception. For a long time, VP8 and H264 were the only options available, but things have changed with the arrival of newer codecs like VP9, H265 and lately AV1. While VP8 remains the most widely used codec in WebRTC to this day, there are movements that suggest we might see alternative codecs start growing in usage.

The main advantage of newer, more modern codecs are the bitrate savings you get with comparable or better quality, especially for higher definition content. This is great for both video calls, recording and broadcasting, as saving on bitrate usually means less congested networks, less chance of packet loss, and cheaper bandwidth costs, all without sacrificing quality. However, it does come with a significant drawback of higher computational costs, as well as battery life unless hardware encoding is in place, which historically has been problematic.

What we’re seeing now is increased focus on these newer codecs. All from fixing simulcast issues for VP9 in Chrome, to Discord rolling out AV1 support for certain Nvidia cards in their application. We have also previously reported on AV1 support in Safari, and in their latest update on Safari 16.4, they originally announced AV1 support, but have since pulled that update. Should we expect a bigger announcement for WWDC 2023?

However, these new codecs are not ready for widespread adoption just yet. Since many browsers and mobile platforms don’t support hardware acceleration yet, we need good fallbacks, and understanding the tradeoffs and when to use it can be daunting. Shameless plug, but get in touch with us if you’re considering alternative codecs, or are unhappy with the current quality in your video streaming application, we’d be happy to help!

[Follow up] Firefox with new console warnings when using setParameters impacts Daily, and others

Two weeks ago, we reported that Firefox users were seeing new console warnings when using setParameters, which were impacting Daily and other WebRTC providers. We were able to reproduce the issue and have reported it to Mozilla. They have confirmed that a fix will be included in the upcoming release of Firefox 112.

This is great news for WebRTC developers and users who have been experiencing these console warnings. Once Firefox 112 lands, the warnings should disappear, and users should be able to use setParameters without any issues. However, if you still see the console error after upgrading to Firefox 112, it may indicate a problem with your provider.

We appreciate Firefox's prompt response in addressing this issue and improving the WebRTC experience for its users!

Chrome switches the default share action form “Entire screen” to “Share tab”

In a recent push for user privacy, Google Chrome has switched its default screen share option from "Entire screen" to "Tab sharing." This move comes in response to concerns around privacy and security, as sharing your entire screen can inadvertently reveal sensitive information, such as passwords or personal data.

When sharing your entire screen, you give the other party access to all the windows and applications currently open on your computer. This can be risky, particularly if you're in a shared workspace or have confidential information on your screen. By switching to tab sharing, users can choose which specific tabs they want to share, minimizing the risk of accidental disclosure of sensitive information.

While this change has led to some user complaints, the privacy benefits of tab sharing far outweigh those concerns. For those who still prefer to share their entire screen, there are workarounds available. One such workaround is to use the getDisplayMedia API and displaySurface parameter to switch the default screen share selection back to "Entire screen."

Here's some sample code to achieve this:

const mediaStream = await navigator.mediaDevices.getDisplayMedia({
  video: {
    displaySurface: 'monitor'

You can then pass on that stream object to Daily’s startScreenshare method:

callObject.startScreenshare({ mediaStream });

You can also play around with the different options in this WebRTC Sample.

If you are using Daily APIs, you can achieve the same thing by passing in the constraints in the — handler.

Nvidia launches “super resolution” for Chrome and Edge

Nvidia has launched "super resolution" support in Chrome and Edge for their 30xx and 40xx graphics cards. While it is still unclear whether this feature will work with WebRTC calls, it opens up the possibility of upscaled video in video calls and broadcast scenarios with WebRTC.

"Super resolution" technology is powered by artificial intelligence and allows users to upscale video content while maintaining the quality of the original image. This can be particularly useful for low-resolution videos, as it can enhance their visual quality and make them appear more lifelike.

We are excited about the advances in AI surrounding video and audio, and the potential impact it can have on the WebRTC community. We will continue to monitor the development of AI use cases in WebRTC and report back on any updates or progress in this area. 

We hope these updates are useful for you! Is there anything in particular you would like to see us talk about next time, or do you have any questions? Let us know below!

This tech update is based on information from WebRTC Insights, a biweekly newsletter that provides information on things happening in the WebRTC ecosystem. Learn more about WebRTC Insights.