Closing the quality gap in mobile RTC
Camera technology and on-demand streaming have pushed video quality forward dramatically, but real-time communication (RTC) has consistently trailed behind. At Meta, where RTC underpins Messenger, Instagram, and WhatsApp, closing that gap has meant rethinking the entire encode path—from how video is scaled before encoding to which codec does the heavy lifting. The clearest wins have come from adopting AV1, but the road to better quality ran through a set of complementary fixes for low-bitrate conditions and CPU-constrained mobile devices.
Defining the low-bandwidth problem
The discussion here centers on peer-to-peer (P2P, or 1:1) calls, where two participants connect directly. Network conditions vary widely across the user base, and the bandwidth available to the video encoder is often far below what the connection nominally offers.
Video encoder bandwidth is only a slice of the total: audio, RTP overhead, signaling, and retransmission or redundancy mechanisms (RTX/FEC/duplication) all consume their share, and the calculations assume the bandwidth estimator is accurate. For this analysis, low-end networks are defined as under 300 Kbps, mid-range as 300–800 Kbps, and high-end or HD-capable as above 800 Kbps. A significant number of calls operate at 50 Kbps or even below 25 Kbps. In these conditions, simply upgrading the codec offered the largest headroom; better video scalers and region-of-interest (ROI) encoding delivered incremental but meaningful gains.
Sharper downscaling with custom scalers
WebRTC is the foundation in most Meta apps, but its default video scalers produce mediocre results at the resolutions RTC actually uses. At low bitrates, the encoder frequently downscales to quarter resolution (from 640×480 or 1280×720 captures). Replacing the default libyuv box filter with in-house scalers improved peak signal-to-noise ratio (PSNR) by 0.75 dB on average in public tests.
Bitrate that follows the face
ROI encoding directs more bits to the part of the frame viewers care about most—typically the speaker's face. Most mobile platforms expose face-detection APIs that run without taxing the CPU. Once the face region is located, encoder APIs can adjust quantization parameters (QP) so that region receives a larger share of the bitrate while the background gets less. The result was a measurable bump in metrics like PSNR.
Why AV1 for RTC
H.264 has dominated RTC for two decades, with broad hardware support across devices. But it is an aging codec, and the Alliance for Open Media (AOMedia) standardized AV1 in 2018 as a royalty-free alternative. Meta, along with YouTube and Netflix, has since deployed it at scale for streaming. Moving from H.264 to AV1 produced the single largest quality improvement for low-bitrate RTC, and the reasoning goes beyond compression efficiency.
Licensing was a critical factor. Hardware codecs on a device typically incur no additional licensing cost, but shipping a software codec usually does. This matters because mobile hardware encoders, while capable of handling 4K 60 FPS for camera capture, are not tuned for RTC workloads such as 7 FPS, 320×180, or 200 Kbps streams. In those regimes, software encoders deliver better quality with acceptable power use. AV1's royalty-free model makes it practical to ship those software encoders.
Compression efficiency across the bitrate range
The core advantage of a newer codec is that it delivers the same quality at a lower bitrate—or higher quality at the same bitrate. The Bjontegaard Delta-Bit Rate (BD-BR) metric quantifies this by comparing the rate-distortion (RD) curves of different codecs across multiple sample bitrates. In local tests, AV1 consistently produced higher quality than H.264 across all bitrate ranges tested.
Built for screen content
AV1 includes tools that matter for emerging RTC use cases like screen sharing, game streaming, and VR remote desktop. Text and other high-frequency screen content are traditionally hard for video encoders, and viewers notice blurry text quickly. AV1's palette mode handles screen content by signaling color clusters rather than transform-domain coefficients, which suits frames where pixel values concentrate on a limited palette. Intra-block copy finds repetitive patterns within the same frame and predicts blocks from them, improving compression efficiency. Both tools are available in AV1's baseline profile.
RPR eliminates key-frame overhead
RTC bandwidth fluctuates constantly, and resolution changes are a common adaptation strategy. With H.264, each resolution change forces a key frame—a large, independently encoded frame that spikes latency and can cause congestion. Reference picture resampling (RPR) in AV1 allows resolution changes to occur without generating a key frame, avoiding that overhead entirely.
Quality improvements come with real trade-offs on mobile
AV1's coding efficiency doesn't come for free. The codec demands significantly more CPU and battery than H.264, which matters for real-time communication (RTC) on phones. Lab measurements with a power meter showed roughly a 4 percent expected increase in battery usage, and public tests landed in the 5–6 percent range. The AV1 encoder alone tripled CPU usage versus H.264, but that was a small share of total battery drain; the display, radio, and other processes dominate. Still, for users who already watch battery levels closely during calls, any added drain needs to justify itself through visible quality gains.
Our approach was to negotiate both AV1 and H.264 up front using WebRTC and Session Description Protocol (SDP). That lets us switch codecs mid-call without signaling or handshakes, so there's no glitch or pause. A custom "hybrid" encoder wraps both codecs and switches based on triggers like CPU usage, battery level, or encoding time—falling back to the more battery-efficient H.264 when needed.
Memory is another concern. AV1 uses more memory than H.264 even without new leaks, which pushes apps closer to out-of-memory (OOM) crashes, especially with other system demands. To reduce that risk, we disabled AV1 on devices with low memory. Further encoder memory optimization remains an open area for improvement.
Measuring quality without a reference
Comparing AV1 and H.264 in public tests needed a low-complexity metric. Bitrate and frame rate won't show codec gains because total bandwidth is fixed by network capacity. Composite metrics that combine quantization parameter (QP), resolution, and frame rate also fail here—QP isn't comparable across AV1 and H.264. PSNR is standard but reference-based, which doesn't fit RTC. Non-reference metrics like BRISQUE (Blind/Referenceless Image Spatial Quality Evaluator) work but are too CPU-intensive, though we're still exploring them.
We built a lightweight framework for PSNR computation instead. The encoder was modified to report compression distortion (most software encoders already support this). Then we designed a scaling-distortion algorithm that estimates quality loss from resolution changes and combines it with the encoder's distortion to produce an output PSNR. This locally verified method showed AV1 giving roughly 2 dB improvement over H.264. We'll publish the details in academic venues over the next year.
Pushing quality on high-bandwidth networks
For high bandwidth—greater than 800 kbps—user expectations have risen with camera quality. People want RTC video to look like local camera capture. From local testing, we settled on what we call HD mode: H.264 at 3.5 Mbps, 30 frames per second, 720p. Subjective tests showed 720p vs. 1080p wasn't noticeable on most devices, except larger screens. For high-end phones with good CPUs, batteries, hardware codecs, and network speeds, improving quality seems trivial—just raise bitrate, resolution, and frame rate. But higher bitrates put more stress on bandwidth estimation and congestion detection algorithms.
Higher bitrates hit congestion more frequently. A 1 Mbps stream triggers more congestion than 500 Kbps; 3 Mbps more than 1 Mbps. Below network minimum throughput, congestion never occurs. To handle this, we improved congestion detection, including custom ISP throttling detection that the traditional WebRTC delay-based estimator missed. Bandwidth estimation is where RTC products differentiate themselves with custom algorithms tailored to their users.
Oscillation in video quality is also unwelcome—users dislike high quality for a few seconds followed by a drop due to congestion. We added support in bandwidth estimation to prevent these swings.
Audio takes priority over video
When congestion causes packet loss, both video freezes and broken audio occur. Broken audio—so-called robotic audio—prevents conversation entirely and often leads to hang-ups or redials. Broken video is less delightful but less likely to end a call. At bitrates of 2.5 Mbps and higher, you can send three to five times more audio packets or duplicates without noticeable video degradation. But those high bitrates on cellular connections brought more congestion, packet loss, and ISP throttling issues, so we adjusted our network resiliency algorithms. Given user sensitivity to mobile data usage, we disabled high bitrates on cellular connections entirely.
Enabling HD mode isn't automatic. We used ML-based targeting on network stats from previous calls to predict whether a call should be HD-capable. We also checked both caller and callee device capabilities—model, battery level, Wi-Fi vs. mobile—before enabling these resource-intensive configurations. Most battery regressions from HD didn't come from higher bitrates or resolution, but from capture frame rates.
Audio remains more important than video in RTC, a fact that shapes how we prioritize network resilience and feature enablement.
Road ahead for RTC codecs
Hardware support for AV1 is arriving: Apple's iPhone 15 Pro includes an AV1 hardware decoder, and the Google Pixel 8 supports AV1 encoding and decoding. Hardware codecs are essential for high-end networks and HD resolutions. As video calling becomes as common as audio calling, collaboration between RTC app creators and hardware manufacturers to optimize encoders becomes more feasible.
On the software side, we'll continue optimizing AV1 encoders and developing new implementations. Users should have control over trade-offs—choosing higher quality at the cost of battery and data, or vice versa. We plan to work with IHV partners on hardware codec development suitable for RTC scenarios, including low-bandwidth use cases.
Forward-looking features include receiver-side video processing to raise resolution and frame rates, and AI/ML to improve bandwidth estimation (BWE) and network resiliency. We're also investigating Pixel Codec Avatar technology, which transmits a model once, then only geometry and vectors for receiver-side rendering—potentially using far less bandwidth than traditional video codecs for RTC.
