WebRTC Community Update: New getStats metric, screen sharing improvements on Chrome & more
Hello, and welcome to a new edition of our WebRTC Community update!
In this post, we’ll look at some new screen sharing features, new getStats metrics, as well as bugs and updates from the WebRTC community!
If you have questions, please ask in the comments!
New getStats metrics are on their way!
W3C TPAC was mid-September, and WebRTC stats, among other things, was on the agenda. From that meeting we got a bunch of new stats that will make getting insights easier and better, and Chrome is currently leading the pack in implementing these new features.
Part of this move is also to reduce the amount of non-standard RTCStats members, such as the now deprecated Track stats.
What this means for you as a web developer is currently not too much, these new stats will take at least 12 weeks to roll out, and they are for now Chrome only. If you’re interested in tracking which stats ship in various browsers, wpt.fyi has got your back!
Daily will use these new metrics to give you better and easier insight into what goes on in a video call, and we’re working on some really good stuff that we’re excited to show you in the next couple of months!
Screen sharing improvements in Chrome
Screen sharing has long been an unloved feature in most browsers. From its feeble beginning as a Chrome extension-only API, it has slowly gotten better. That seems to be about to change, as Chrome has just released some new privacy-preserving features for screen sharing.
Our favorite new feature is the ability to switch which tab you’re sharing quickly without having to go back to the application, stop screen sharing and start it again.
Implementing large calls? Watch out for this Chrome constraint
There is a little known Chrome audio element constraint that might bite you if you’re not careful implementing large calls. On most platforms, the number of simultaneous audio outputs (even muted ones) is 50. This poses some constraints for you as a developer, as the result is that calling play() will silently fail if you exceed this limit, which is easy to do when you’re implementing really large calls. And worse yet, the Chrome bug tracking this issue was just closed for inactivity.
The best course of action is to be mindful of how you handle media elements, that is AudioElement and VideoElement, as well as AudioContext. Make sure you release them by removing them from the DOM and not have loose references around. In addition, remember that even muted video elements count towards your allotted 50, so a 49 person grid should use a single media element per stream rather than separate elements which is the usual wisdom. Be aware though, using the same element opens up some issues with autoplay!
In our own Prebuilt, we’ve solved this problem for you, and can scale calls to 15,000 participants without writing a single line of code.
Don’t use AudioContext in Safari
Would it really be a tech update if it didn’t contain some potentially shattering Safari bugs? Safari has historically had a hard time with AudioContext, which has plagued Safari version ever since. In iOS 14, the entire audio output might break if AudioContext was used on the page.
In this newest case, using AudioContext with a local audio track, for example to show that the microphone is working in a haircheck, might result in the capture unexpectedly ending. The workaround for this is to subscribe to the MediaTrack’s ended event and automatically retry, but don’t worry, Daily does all of this for you!
Regardless of that, staying away from using AudioContext in Safari is probably a good idea.
Don’t do multiple calls to getUserMedia in Safari, either
And another one! Safari on iOS has for the longest time had issues doing multiple simultaneous getUserMedia calls, which has been a real issue for hairchecks and device switchers for all WebRTC applications. The underlying OS API used does not support multiple camera captures at the same time, which luckily on an iOS device is not that big of an issue (unless you’re a fan of BeReal on the web).
Until iOS 16, that also prohibited the use of multiple capture constraints on the same camera, which should now be fixed. However, this seems to have regressed and we’re back to square one.
In other words, don’t call getUserMedia while another stream is active in Safari for iOS.
Update form Daily, removing deprecated stats
Following the deprecation of the MediaTrack stats members in getStats, we are removing these from our stats object as well. This has little impact for most users, as most fields present in the old tracks are already overwritten by other stats, so there is no change. However, interruptedCount and interruptedDuration will be permanently removed.
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.