For the past several years, AV1 has been generating real excitement in the WebRTC and real-time communications space. Better compression, no licensing fees, and backing from the biggest names in tech made it look like the codec the industry had been waiting for. Then, on March 23, 2026, Dolby Laboratories filed patent infringement suits against Snap Inc., targeting Snap’s use of HEVC and AV1 to encode and transcode videos in its Snapchat application. For developers who had been planning to adopt or expand their use of AV1, this lawsuit raises some uncomfortable questions.
Important Disclaimer: I’m no lawyer! Nothing in this blog post should be construed as legal advice of any kind. We are WebRTC software developers and our goal in presenting this information is to offer technical advice to teams in light of possible legal concerns.
This post covers AV1’s compression advantages and browser support, what Dolby’s patent claims mean for teams building on WebRTC, and how to configure codec priorities if you want to reduce your exposure while the case plays out.
This is a topic I discussed with Tsahi Levent-Levi in our April 2026 WebRTC Industry Analysis segment: Is AV1 truly royalty-free? It was also a topic in February 2025: Is the AV1 Video Codec Taking Over WebRTC?
AV1 Performance and Browser Support in WebRTC
AV1 was developed by the Alliance for Open Media (AOMedia), a consortium that includes big names such as Google, Apple, Microsoft, Amazon, Netflix, and Mozilla. It was designed from the ground up to deliver better compression than HEVC and VP9 while being available under a royalty-free license.
In practical terms, AV1 delivers roughly 30% lower bitrates than VP9 at equivalent visual quality, and 50% lower than H.264 (source: https://en.wikipedia.org/wiki/AV1). For users on constrained mobile networks or in regions with poor connectivity, that efficiency can be transformative.
In WebRTC contexts specifically, AV1 performs exceptionally well and the perceptual quality advantage over VP8 and even VP9 is meaningful. For applications where video quality is a competitive differentiator or where mobile network performance is a critical concern, AV1 is worth considering.
Hardware acceleration support is also improving steadily, with support for hardware decoding on many modern mobile devices, desktop and laptop CPUs and smart TVs. This growing number of devices supporting AV1 hardware encoding and decoding addresses the historically prohibitive CPU cost of software-only AV1 encoding. The CPU penalty that has held back AV1 adoption is becoming less of a barrier.
Browser support has matured considerably as well. Chrome supports AV1 since version 70, Firefox since version 67, and Edge supports AV1 since version 121. Safari on iOS and Mac supports it as well, but only on devices with hardware encoding (iPhone 15 Pro and M3 Macs or later). It is not supported on older devices. (source: https://caniuse.com/av1)
Why AV1 Has Been Considered Royalty-Free
The “royalty-free” claim for AV1 is rooted in AOMedia’s patent policy, under which member companies contribute their relevant patents and commit to licensing them on a royalty-free basis. The idea was to create a clean, unencumbered codec by getting all the major players into the same tent before the specification was finalized.
The basis of Dolby’s lawsuit appears to be that the tent had a limited guest list. AOMedia’s royalty-free commitments only bind its own members. So in theory (and again, I’m not a legal expert!) any company that holds patents covering techniques used in AV1 but never joined AOMedia could argue that they made no such commitment and are under no legal obligation to offer royalty-free terms.
As Dolby has argued in its complaint, it never participated in AV1’s development and therefore never agreed to AOMedia’s licensing policies. Dolby is asserting that its patents cover methods present in AV1 implementations, regardless of the codec’s intended open-source status.
Possible Implications of Dolby Snap AV1 lawsuit
The lawsuit is significant for reasons that extend well beyond Snap.
If this lawsuit is successful, it could establish a legal precedent that AV1 is not necessarily immune from patent claims by non-AOMedia members. It may also open the door for others besides Dolby to consider seeking damages from companies that use AV1 in their products.
This does not mean that AV1 is broken or that every WebRTC application is immediately at risk. The Dolby patents in question are specific, the outcome of the litigation is uncertain, and the technical and legal merits of the claims will be tested in court. But for teams that were planning to adopt AV1, this may be a good time to pause and think carefully.
WebRTC Codec Alternatives to AV1: VP8, VP9, and H.264
If you want to reduce your patent exposure while the case develops, your most practical options in the WebRTC codec stack are VP8, VP9, and H.264.
- VP8 is one of the two Mandatory-to-Implement (MTI) codecs in the WebRTC specification, meaning every compliant browser must support it. It is widely supported, computationally inexpensive, and has a clean patent history through AOMedia. For many applications, especially those running on constrained devices or targeting the broadest possible compatibility, VP8 is still a perfectly solid choice.
- VP9 is where most serious WebRTC applications should be looking if they are not already using it. Google Meet and Jitsi Meet both use VP9. It delivers 25 to 35 percent better compression than VP8, supports Scalable Video Coding (SVC) for group calls, and has the same clean royalty-free lineage. It is not yet as widely deployed as it should be, largely because many open-source media servers default to VP8 and most teams do not change defaults. If you are currently on VP8 and looking for a meaningful quality improvement without patent uncertainty, VP9 is your best move.
- H.264 remains important for Safari and iOS compatibility. Safari supports VP8 in modern versions but has inconsistent VP9 support, and all iOS browsers inherit Safari’s codec constraints through the WebKit requirement. If your application serves a significant iOS user base, H.264 needs to stay in your codec priority list.
The safest codec priority order for broad compatibility and low patent risk right now is VP9, then VP8, then H.264, with AV1 and HEVC excluded or deprioritized.
How to Disable AV1 in WebRTC
Controlling which codecs your application uses requires intervention during SDP negotiation. There are several approaches depending on your stack.
Option 1: Using setCodecPreferences() Before Negotiation
Using setCodecPreferences() before negotiation is the cleanest modern approach and should be your default. It sets codec preferences before the offer/answer exchange occurs, so no SDP manipulation is needed afterward.
const transceiver = peerConnection.addTransceiver('video', { direction: 'sendrecv' });
const supportedCodecs = RTCRtpSender.getCapabilities('video').codecs;
const allowedCodecs = supportedCodecs.filter(codec => !codec.mimeType.includes('AV1'));
transceiver.setCodecPreferences(allowedCodecs);By removing any mimeType that includes AV1 in the filter, you prevent the codec from being proposed or accepted during negotiation.
Option 2: Configuring Your Media Server
Client-side codec preferences are only half the picture. If you are running a Selective Forwarding Unit or media server, you need to apply a matching configuration there as well, or the server may attempt to fall back to AV1 on a renegotiation.
- For mediasoup, restrict codecs in your router configuration when defining the media codec list.
- For Jitsi and Jicofo, the preferred codec can be set via options in your jicofo.conf file.
- For LiveKit, codec preferences are set in room and track publish options.
- For Janus, codec preferences are configured in the VideoRoom plugin settings.
Each of these platforms has documentation covering codec restriction in detail, and it is worth reviewing that documentation specifically in the context of excluding AV1 until the patent landscape becomes clearer.
The Bottom Line
AV1 is a genuinely better codec for many real-time communication scenarios, and its momentum in the industry is real. The Dolby lawsuit does not change the technical case for AV1, but it does add meaningful legal uncertainty that developers and product teams should consider.
If you have legal questions about the implications of the Dolby AV1 patent lawsuit, please speak to your legal counsel.
If you need a WebRTC architect to help you navigate codec selection, media server configuration, or real-time video application development, contact our team!
Further Reading:
