How Daily is working around the H.264 bug in Safari 15.1

Daily Keyframes are byte-sized tips from our engineers. We hope they help you remove roadblocks so you can focus on building.

Unfortunately, Safari 15.1 (on both MacOS and iOS) has a critical regression which crashes the tab when a video track is muted and H.264 is in use. You can read more about the bug here: https://bugs.webkit.org/show_bug.cgi?id=232006. Or try to reproduce it using this codepen.

For those of you more familiar with the inner workings of a Daily call, you will know that there are two key operating modes: peer-to-peer (p2p) and SFU (server). Today we want to explain a Safari-specific issue that affects p2p calls and how we’re mitigating it.

In p2p calls, we let the peers’ browsers negotiate which codec should be used. In most cases this ends up being either H.264 or VP8. Typically, both are offered, but the one offered first is chosen. Daily provides a flag to override listing both codecs, and forces the use of H.264. This can be beneficial for certain use cases, such as embedded and IoT devices.

This Safari regression only affects daily-js users in p2p calls, when browsers negotiate H.264 or developers override to force H.264 and chromeExperimentalCamMuteLightOff is not set, or the underlying track is manually disabled by application code while the track is attached to an RTCRtpSender.

This does not affect Daily Prebuilt.

How we’re mitigating this

We are automatically working around this regression if daily-js users are not explicitly forcing H.264 by using VP8 for outgoing tracks in Safari 15.1. For customers who are explicitly forcing H.264, we can work with you to make sure your application isn't impacted by this.

For the vast majority of Daily customers and their users this will be a completely transparent change, which will only make your applications more stable.

If you have any questions, or would like our help in navigating this, please feel free to reach out.