AV1 vs H.264 vs VP9 vs VP8: Best Video Codec for Conferencing in 2026

Every codec comparison you have read this year probably told you AV1 is the future and H.264 is the past. They are not wrong, but they are writing about streaming, not video conferencing. If you are building a real-time video platform where encoding happens live, every frame matters, and your users are on everything from a 2019 Chromebook to the latest iPhone, the codec question has a very different answer.

You have probably read that AV1 delivers 30 to 50 per cent better compression than H.264. That is true for pre-encoded streaming. Now try encoding it in real time during a live video call with software on a mid-range laptop. The picture changes considerably.

In this guide, we compare AV1, H.264, VP9, and VP8 through the lens that actually matters for your platform: real-time encoding speed, cross-browser compatibility, SFU (Selective Forwarding Unit) routing complexity, and what it costs to run in production. We start with VP8 because it is the mandatory WebRTC baseline, then work through H.264, VP9, and AV1 in order of deployment maturity. We also explain why VP8, the codec most articles dismiss as 'legacy', is still running in more production WebRTC deployments than most engineers realise. By the end, there is a practical decision framework you can apply directly.

Table of contents

1. Why codec choice matters more for video conferencing than streaming
2. VP8: the codec that refuses to retire
3. H.264: the universal standard (with strings attached)
4. VP9: better compression, still underadopted
5. AV1: the future that is not quite ready for real-time
6. The comparison table
7. What about H.265, H.266, and AV2?
8. How this plays out in a real video conferencing SFU
9. What Digital Samba uses and why
10. A practical decision framework for your platform
11. FAQ

Why codec choice matters more for video conferencing than streaming

The 2026 video codec conversation is dominated by streaming engineers, and that is part of why the advice you find online is often wrong for video conferencing platforms.

In video-on-demand (VOD) and live streaming, you encode once and serve the result to thousands or millions of viewers. The CPU cost of encoding is a one-time or batch investment. AV1's notoriously slow software encoding speed is irrelevant when your encoding farm runs offline or your encoder has dedicated AV1 hardware. The codec decision in streaming is primarily about compression efficiency and storage costs.

In video conferencing, you encode in real time, per participant, continuously, on the device that the participant is actually sitting in front of. Every millisecond of encoding latency adds to the glass-to-glass delay. A codec that encodes 10 times slower than an alternative does not just use more CPU; it directly degrades the quality of every call on every device that cannot keep up.

Then there is codec negotiation. When two browsers establish a WebRTC connection, they exchange an SDP (Session Description Protocol) offer listing the codecs each side supports. The SFU or peer must select a codec that both endpoints support, not the codec you prefer or the one that performs best on your benchmark hardware. If User A is on Chrome and User B is on Safari, that negotiation produces a real constraint on what you can use.

Here is the cross-browser reality you are designing for in 2026:

• Safari and iOS: prefers H.264. AV1 support is still experimental and hardware-dependent. Every iOS browser (Chrome on iOS, Firefox on iOS, Edge on iOS) is forced to use WebKit, which inherits Safari's codec limitations.
• Chrome and Edge: support VP8, VP9, H.264, and AV1. VP8 remains a common default in WebRTC implementations; AV1 availability depends on device hardware.
• Firefox: supports VP8, VP9, and H.264. AV1 decoding is present but hardware-gated.
• Android: VP8 software decoding since Android 2.3; VP9 software decoding since Android 4.4 KitKat. AV1 hardware decoding on Android 10 and later, but only on devices with the appropriate hardware decoder.

For a conferencing platform serving users across all of these environments, there is no single right answer. The correct answer is a negotiated mix, and understanding each codec's real-world position is how you set that up intelligently.

VP8: the codec that refuses to retire

Released in 2010 by Google and open-sourced through the WebM project, VP8 was originally designed as a royalty-free alternative to H.264. It became the first mandatory video codec in the WebRTC specification, which means it is still the baseline codec that every conformant WebRTC implementation must support.

That history is why VP8 is still alive and active in production deployments in 2026, not because nobody knows better, but because it works reliably everywhere. As Tsahi Levent-Levi, one of the leading authorities on WebRTC architecture, puts it directly: 'VP8 still just works.' In his January 2026 WebRTC predictions, he explicitly recommends that vendors struggling to stabilise AV1 implementations should dial back down to VP8, stabilise, and experiment upward from there.

Compared to H.264, the VP8 trade-off is less about quality and more about where each codec fits in your infrastructure. VP8's practical advantages in a conferencing context are:

• Encoding speed: VP8 is fast. Software encoding of 720p video is achievable in real time on modest hardware without dedicated encoding acceleration. This matters enormously for mobile clients and budget devices.

• CPU predictability: VP8's encoding complexity is low and predictable. You will not see CPU spikes that cause frame drops mid-call.

• Universal support: VP8 is supported in Chrome, Firefox, Edge, and Safari (since Safari 12.1 for WebRTC). It is the one codec you can reliably use across essentially every browser combination without transcoding at the server.

• Compression efficiency: This is VP8's weakness. Achieving good 1080p quality requires roughly 4,500 to 6,000 kbps. That is significantly higher bandwidth than VP9 or AV1 need for equivalent quality. On constrained connections or mobile data plans, VP8's bitrate requirements become a real problem.

When to stick with VP8:

• when your user base includes older mobile devices,
• when CPU budget on client devices is tight,
• when you need maximum cross-platform compatibility without server-side transcoding,
• when your platform is already running VP8 reliably, and the quality is acceptable for your use case.

Switching codecs costs real engineering time, so make sure the gain justifies it before you start.

H.264: the universal standard (with strings attached)

H.264 (also known as AVC, or Advanced Video Coding) is the most widely deployed video codec in history. Standardised by ITU-T and ISO/IEC, it was the codec that made HD video over the internet practical, and it is not going anywhere soon.

For video conferencing specifically, H.264 has one attribute that makes it non-negotiable for most platform teams: it is Safari's preferred WebRTC video codec, and hardware encoding support for H.264 exists on essentially every device manufactured in the last decade. If your users include any Apple device users, and they almost certainly do, you need H.264 support.

• Encoding speed: fast, well-optimised, with excellent hardware acceleration on virtually every device. Intel, AMD, NVIDIA, Qualcomm, Apple Silicon, and Exynos all have mature H.264 hardware encoders. This means real-time encoding at 1080p is achievable on mobile devices without significant battery drain.

• Compression efficiency: H.264 delivers good quality at roughly 4,000 to 5,000 kbps for 1080p. That is meaningfully better than VP8 in the same scenario, but significantly behind VP9 and AV1. For video conferencing at typical 720p resolutions, H.264 is generally adequate.

• Licensing: H.264 is not open source. It is covered by patents, now administered under the Via Licensing Alliance (formerly MPEG LA), and using it in commercial products technically requires a licence. For browser-based WebRTC platforms, this is largely handled by the browser vendors, who have their own H.264 licences. If you are doing your own server-side H.264 encoding, such as in a recording or transcoding pipeline, you are outside the browser licence and should review your obligations with legal counsel.

• The interoperability case: when you are uncertain which codec two endpoints share, H.264 is the common denominator. Chrome, Firefox, Edge, and Safari all support it. Android and iOS all support it with hardware acceleration. For platform teams that need a single codec that will work in all circumstances, H.264 is the pragmatic answer, and not a shameful one.

VP9: better compression, still underadopted

VP9 is Google's successor to VP8, released in 2013, royalty-free, and used by YouTube for the majority of desktop playback on Chrome and Firefox. On paper, VP9 is a compelling choice for video conferencing: it offers better compression than VP8 at the same visual quality, bringing 1080p down to roughly 2,400 to 3,200 kbps versus VP8's 4,500 to 6,000 kbps.

That bandwidth saving is real and meaningful, especially for platforms serving users on variable mobile connections or markets where data costs are high.

The challenge with VP9 is encoding speed, though in a slightly less extreme form than AV1 faces. Software VP9 encoding is significantly slower than H.264 at comparable quality settings. At mid-range quality presets on libvpx, this gap is substantial enough to make real-time software VP9 encoding impractical on most hardware without GPU acceleration.

This hits hardest when you factor in mobile devices. Hardware VP9 decoding is widespread (Android has had software VP9 decode since Android 4.4 KitKat, with hardware decode following on SoCs manufactured from roughly 2016 onwards), but hardware VP9 encoding is much less available on mobile hardware. This means client-side encoding of VP9 in WebRTC often falls back to slow software encoding, spiking CPU and draining battery.

• Browser support: Chrome, Firefox, and Edge natively. Safari added VP9 decoding support in macOS Big Sur and iOS 14 (Safari 14 and later), but VP9 is not Safari's preferred WebRTC codec and encoding support on Safari/iOS remains limited and inconsistent. This creates the same transcoding pressure at the server that VP8 avoids.

• The adoption puzzle is real: VP9 has been available for years, offers clear compression benefits, and is royalty-free. Yet many WebRTC platforms have not fully adopted it. As Tsahi Levent-Levi notes, this reluctance is a useful signal about AV1. If the industry has not fully moved to VP9 after more than a decade, expecting AV1 to dominate by 2026 is not realistic.

• When VP9 makes sense: for controlled environments where you know both endpoints are on Chrome or Firefox with hardware acceleration; for recording pipelines (encode once, benefit from the compression savings across playback); or for platforms specifically targeting desktop users where you have more confidence in CPU headroom.

AV1: the future that is not quite ready for real-time

AV1 is the codec developed by the Alliance for Open Media (AOMedia), a coalition that includes Google, Netflix, Amazon, Microsoft, Intel, Mozilla, and Cisco, with Apple joining in January 2018 shortly before the spec was finalised. The bitstream specification was published in March 2018. Its compression efficiency is genuinely impressive: roughly 30 to 50 per cent better than VP9 and 50 to 60 per cent better than H.264 at equivalent visual quality, bringing 1080p down to approximately 1,800 to 2,200 kbps.

AV1 was designed to be royalty-free under AOMedia's patent licence. In practice, however, that royalty-free commitment only binds AOMedia members. Patent holders who declined to join AOMedia can assert any patents they believe are relevant to AV1. As of March 2026, this has become an active issue: Dolby filed patent infringement suits against Snap Inc. in the United States and Brazil targeting its use of AV1, and InterDigital, Nokia, and Sisvel (which claims a pool of over 1,500 relevant patents) have all asserted IP rights related to AV1 implementations. WebRTC.ventures specifically flagged this as a meaningful procurement risk in April 2026. The practical position for a platform team today: AV1's royalty-free status reflects AOMedia's internal commitment, but non-members are actively litigating. Check with legal counsel before deploying AV1 commercially.

For streaming and VOD, AV1 has already won regardless of those complications. YouTube, Netflix, and most major streaming platforms use AV1 for a significant portion of their traffic. The question for this article is whether those advantages translate to real-time video conferencing, and the honest answer in 2026 is: not yet for most platforms.

• The encoding speed problem: software AV1 encoding is 5 to 10 times slower than VP9, and can saturate multiple CPU cores during active encoding on desktop hardware. For live video calling, where encoding happens per-participant per-frame in real time, this makes software AV1 encoding impractical on most current hardware without dedicated AV1 silicon.

• Hardware AV1 encoder availability in 2026: the situation is improving but uneven. Desktop and laptop hardware with AV1 hardware encoders includes Intel Arc discrete GPUs (note: 12th-generation Alder Lake integrated graphics support AV1 decoding only; hardware encoding is specific to Arc discrete GPUs and 14th-generation Core Ultra integrated graphics), AMD RDNA 3 and later (RX 7000 series), NVIDIA RTX 40 series (Ada Lovelace), and Apple M5 Pro and M5 Max (released March 2026; earlier Apple Silicon generations including M1, M2, M3, and M4 have hardware AV1 decoding only). These cover a meaningful share of recent enthusiast hardware, but not the general consumer device population, and essentially not mobile.

• Mobile AV1 hardware encoding is the critical gap. The Samsung Exynos 2200 added AV1 hardware decoding, but hardware encoding support on Snapdragon and other mobile SoCs remains limited. Notably, Qualcomm has publicly stated it is not planning to add AV1 hardware encoding to Snapdragon at all, with its intention being to skip AV1 encoding and move directly to VVC (Versatile Video Coding) when that is ready. Given Snapdragon's share of Android flagships and mid-range devices, this makes the often-cited 2027 to 2028 timeline for ubiquitous mobile AV1 encoding a reasonable prediction for Apple and PC hardware, but much less certain for Android. The reality for most smartphone users in 2026 is that AV1 real-time encoding means software encoding, which is not viable for sustained video calls.

Browser support for AV1:

• Chrome (desktop and Android with hardware): AV1 decode supported since Chrome 70; hardware encode on compatible chips
• Firefox: AV1 decode; limited real-time encode support
• Edge: matches Chrome via Chromium
• Safari: AV1 decode on Apple Silicon M3 and later Macs, and iPhone 15 Pro and later. Older Apple devices have no AV1 support at all. AV1 WebRTC encoding in Safari is still marked experimental.

Tsahi Levent-Levi's assessment, from his December 2025 session with WebRTC.ventures, is the clearest public statement of where AV1 stands for conferencing: 'AV1 will not be the dominant codec in 2026, and may need until around 2028 to reach that status, while VP8 and H.264 stay strong.' His January 2026 blog post adds that many vendors may find codec implementations burdensome on device resources.

When AV1 makes sense today: for recording and VOD transcoding pipelines where the encoding cost is paid once; for controlled enterprise environments where you can verify all endpoints have AV1 hardware encoders; for screen sharing on supported devices where AV1's content-adaptive tools excel; and for bandwidth-constrained scenarios where the device has confirmed AV1 hardware support and the bandwidth savings justify the implementation complexity.

The comparison table

The AV1 vs H.264 comparison looks very different when you focus on real-time constraints rather than streaming benchmarks.

What about H.265, H.266, and AV2?

Before looking at how these codecs interact in a real SFU, it is worth covering the codecs that come up in comparison articles regularly but cannot practically serve as your primary conferencing codec today.

H.265 (HEVC, or High Efficiency Video Coding): excellent compression, comparable to VP9 and better than H.264, with mature hardware encoder support. The patent licensing situation is fragmented: three separate patent pools (MPEG LA via Via Licensing Alliance, HEVC Advance, and Velos Media) each claim royalties, which is a significant commercial risk and has historically kept H.265 out of Chrome and Firefox. Chrome 136 (mid-2025) did add H.265 WebRTC support by default on Windows, macOS, and Android, subject to hardware availability, so H.265 is no longer a Safari-only story for WebRTC. Firefox, however, still does not support H.265 in WebRTC. The conclusion for most teams is the same: the fragmented patent pool remains a real barrier, and the absence of Firefox support makes H.265 impractical for general cross-platform conferencing. Apple's Vision Pro uses H.265 for spatial video, which may extend its relevance in Apple-specific enterprise contexts.

H.266 (VVC, Versatile Video Coding): offers even better compression than AV1 in some benchmarks, and has an even more complicated patent situation than HEVC. Zero browser support for WebRTC. Not relevant to video conferencing platforms in 2026 or the foreseeable future. (This is also the codec Qualcomm has stated it intends to target for future mobile hardware encoding, rather than AV1.)

AV2: the Alliance for Open Media's planned successor to AV1, designed to improve on AV1's compression while maintaining royalty-free licensing. Still in early specification development as of 2026. No production timeline. Watch for 2028 to 2029 at the earliest.

LCEVC (Low Complexity Enhancement Video Coding): an MPEG standard that works as an enhancement layer on top of an existing base codec, whether VP8, H.264, VP9, or AV1. It claims roughly 40 per cent compression improvement for any base codec at low additional encoding complexity. This is an interesting architectural approach because it sidesteps the 'which codec to switch to' problem and can improve efficiency on existing codecs without replacing them. Still at an early stage for WebRTC adoption, but worth monitoring as a path to better compression that does not require abandoning H.264 or VP8 infrastructure.

How this plays out in a real video conferencing SFU

Individual codec characteristics tell you part of the story. How they interact in a multi-participant SFU-based conferencing architecture is where the real engineering complexity lives.

• Codec negotiation in WebRTC: when a browser establishes a WebRTC connection, it sends an SDP offer listing its supported codecs in preference order. The SFU or peer selects the highest-priority codec that both sides support. You do not get to choose the codec you want to use; you get the codec the negotiation produces. This means the cross-browser problem is not a theoretical concern: it is what your SFU handles on every call.

• The Chrome-and-Safari problem: a user on Chrome (which prefers VP8 or VP9 for WebRTC) and a user on Safari (which prefers H.264) joining the same session creates a negotiation mismatch. Without server-side transcoding, which adds latency, cost, and complexity, the SFU must either route to the lowest common denominator (H.264, which both support) or selectively transcode for specific participants. Most production SFUs handle this by supporting H.264 as the universal fallback.

• Simulcast and codec interaction: simulcast, where a client sends multiple resolution layers of the same stream, is codec-dependent. VP8 and VP9 support temporal scalability layers. H.264 has SVC extensions that are not widely implemented in browsers. AV1 has native SVC (Scalable Video Coding) support across all three dimensions (spatial, temporal, and quality), which looks good on paper, but only on devices that can actually afford the AV1 encoding cost.

• The routing architecture: Digital Samba's SFU, based on Janus, routes encrypted media streams directly between participants without decoding or mixing in the media path. This keeps latency low and the architecture clean. The trade-off is that every additional codec your SFU supports adds operational cost: codec fallback paths, renegotiation when a participant joins mid-call on a different browser, and engineering time to test and maintain each combination across the device matrix.

Some platforms absorb that complexity to chase per-codec efficiency gains. Others, including Digital Samba, take the opposite view: pick the one codec that works reliably in every browser without server-side transcoding or mid-session renegotiation, and invest engineering effort into call quality, AI features, and reliability instead. Both are legitimate production choices. The right answer depends on whether your bottleneck is bandwidth or engineering capacity.

What Digital Samba uses and why

The best codec for video conferencing is the one that delivers acceptable quality across all the browsers and devices your users actually have, not the one that wins benchmarks on reference hardware.

Digital Samba runs a deliberate VP8-only real-time stack. Safari has supported VP8 for WebRTC since Safari 12.1 (2019), Chrome, Firefox, and Edge support it natively, and that single codec covers every browser combination Digital Samba sessions actually encounter. Here is the reasoning:

• VP8 is not legacy - it is production: VP8 runs across a significant share of Digital Samba sessions. It delivers reliable quality, consistent encoding behaviour across device types, and works in every browser combination without server-side transcoding. The performance is not glamorous in benchmark comparisons, but it is predictable, and predictability matters in production.
• VP8 works on every browser, including Safari: Safari added VP8 support for WebRTC in 2019, and every Apple device shipped since then handles VP8 in real-time sessions without fallback. Standardising on VP8 across the entire user base removes the codec renegotiation step that happens when a Chrome user and a Safari user join the same room on a multi-codec platform. Skipping that complexity is the reason mid-call reconnects on Digital Samba are not codec-driven, and the engineering time saved goes into call reliability and AI features instead.
• Recordings and AI pipelines are codec-agnostic: when sessions are recorded, Digital Samba's recording pipeline can transcode to more efficient codecs for storage and archival. The AI features, such as live captions, transcription, and meeting summaries, work at the decoded media level, not the compressed bitstream level, which means they operate independently of which codec the session negotiated. You get the full AI feature set regardless of whether the call ran VP8, H.264, or VP9.
• AV1 is on the watchlist, not the immediate roadmap: Digital Samba is tracking AV1 hardware encoder availability across consumer devices, but a real-time AV1 rollout is not on the near-term plan. The decision point sits a few years out, when hardware AV1 encoding is standard on mid-range consumer devices and the cost of negotiating a second codec is justified by user-visible bandwidth savings. Until then, VP8 stays the production codec.

A practical decision framework for your platform

Step 1: Check your user base, but do not assume Apple users force you onto H.264. Safari has supported VP8 for WebRTC since 2019, so a VP8-only stack works across Chrome, Firefox, Edge, and Safari without server-side transcoding. H.264 becomes worth adding if you want to align with Safari's preferred codec for marginal quality gains, or if you specifically want hardware H.264 encoders on Apple Silicon doing the work. It is a trade-off against engineering complexity, not a hard requirement. 

Step 2: Assess your current codec. Running VP8 and quality is acceptable for your users? Do not switch just because a blog told you AV1 is better. Switching costs real engineering effort: migration work, testing across device and browser combinations, and potential regression handling. Invest that effort where it creates user-visible value.

Step 3: Evaluate bandwidth constraints. Paying significant CDN or bandwidth costs? Consider VP9 for recording/VOD pipelines where the encode-once cost is justified by compression savings at scale. Consider AV1 for archival transcoding where you are optimising long-term storage costs.

Step 4: Check your target device hardware. Can you verify that a meaningful share of your endpoints have AV1 hardware encoders? If yes, and you have the engineering resources, piloting AV1 in a controlled rollout is worth doing now. If your users are on general consumer or mobile hardware, wait. Software AV1 encoding will hurt more than it helps.

Step 5: Monitor the hardware timeline. AV1 hardware encoding is likely to be standard in PC and Apple hardware by approximately 2027 to 2028. That is when the math changes for real-time video conferencing on those platforms. For Android-heavy user bases, the picture is less certain given Qualcomm's stated intention to skip AV1 encoding entirely. Set a checkpoint to revisit the AV1 decision at that point, and factor in your platform's device mix when you do.

A note on LCEVC: if you want meaningfully better compression without changing your base codec, keep an eye on LCEVC as an alternative path. It is not production-ready for WebRTC in 2026, but it could be a practical upgrade option for platforms that are not ready to migrate to VP9 or AV1.

FAQ

Conclusion

The codec you should use in 2026 depends almost entirely on the devices and browsers your users have, not on which codec wins the latest compression benchmark.

If you are running VP8 and your users are happy with the quality, that is a legitimate production choice that millions of sessions validate every day. Significant bandwidth costs or a Chrome-centric user base? VP9 for recording and high-quality connections is the practical next step. If you have Apple users, you have two legitimate paths: add H.264 to align with Safari's preferred codec for marginal quality gains, or stay on VP8 (which Safari has supported since 2019) and save the engineering effort that codec fallback functionality would otherwise consume. And if you are planning for 2027 to 2028, which is when Tsahi Levent-Levi and the broader WebRTC community expect AV1 hardware encoding to become mainstream on PC and Apple platforms, the time to start evaluating AV1 in controlled environments is now. Just keep an eye on the patent litigation as you plan. AV1's royalty-free status is currently being tested in court, and that is worth a conversation with legal counsel before you commit.

The best codec for video conferencing is not one codec. It is a negotiated stack, and understanding the trade-offs of each option is how you build a platform that works for every user you actually have.

See how Digital Samba handles cross-platform video quality: digitalsamba.com/features

Explore the DS architecture in detail: docs.digitalsamba.com/reference

References

1. Ant Media. (2026, February 11). WebRTC browser support 2026: complete compatibility guide.
2. Alakkadshaw, A. (2026, February 2). 7 WebRTC trends shaping real-time communication in 2026. DEV Community.
3. Digital Samba. (2026). Security whitepaper: architecture, encryption, and compliance. Digital Samba S.L.
4. Fraunhofer HHI. (2020). LCEVC: Low Complexity Enhancement Video Coding.
5. GetStream.io. (2025). WebRTC codecs: what is supported?
6. GetStream.io. (2026, March 3). The future of video technology in 2026: 5 shifts developers need to know.
7. Hashimoto, K., et al. (2025, November). Evaluation of hardware-based video encoders on modern GPUs for UHD live-streaming. arXiv.
8. Hashimoto, K., et al. (2025, December 2). Evaluation of GPU video encoder for low-latency real-time 4K UHD encoding. arXiv.
9. Levent-Levi, T. (2026, January 5). My WebRTC predictions for 2026. BlogGeek.me.
10. NVIDIA. (2023). NVIDIA claims to have better AV1 encoder than AMD and Intel. VideoCardz.com.
11. Oppenheimer, J. (2025, December 3). Five WebRTC predictions for 2026: Tsahi Levent-Levi on AV1, MOQ, and what might break next. WebRTC.ventures.
12. Red5. (2026). AV1 vs VP9 vs VP8: codec comparison guide 2026.
13. VideoSDK. (2025). WebRTC Safari: the 2025 developer's guide to features, limitations, and optimization.