H.265, AV1, and H.264 Video Codec Comparison: x265 Underperforms, libaom Shines

It's 2023, and we have to ask: how does AV1 perform? Is it ready for production? And does H.265 really cut bandwidth in half compared to H.264?

This article compares H.265, AV1, and H.264 across performance, quality, and bandwidth efficiency. The test encoders are x264, x265, VideoToolbox, and libaom, run on a MacBook Pro 2021 with an M1 Pro chip.

Overall, x265 did not meet expectations — its CPU cost is too high for real-time communication in production. libaom performed well, delivering strong quality with acceptable performance.

Both x265 and AV1 can achieve lower bitrates and higher encoding quality than H.264.

AV1 also offers dedicated encoding settings for screen sharing, with algorithm optimizations and solid rate control. x265 and VideoToolbox do not provide equivalent options.

1. Hardware Support

H265:

• Apple added HEVC support starting with iOS 11 and the A9 chip (iPhone 6s, September 2015), including AVPlayer and Safari. Hardware encoding requires iOS 11 + A10 (iPhone 7). Reference
• Android devices began adopting H.265 encoding around 2015. Android 5.0 (Lollipop) was among the first versions to support it.

However, not every device released on Android 5.0 or later fully supports H.265 encoding, because codec support varies by device model and manufacturer. High-end and mid-range Android devices are more likely to support it. {: .prompt-warning }

• On desktop, most Intel integrated GPUs and NVIDIA GPUs support H.265. See here for detailed H.265 support.

AV1:

• Android: Qualcomm Snapdragon 8 Gen 2 added AV1 hardware decode; Xiaomi 13 was the first device, released in December 2022.
• Apple A17 Pro includes a dedicated AV1 decoder, shipped with iPhone 15 Pro in September 2023.
• Mac: M3 chips added AV1 decode support on October 30, 2023.
• PC: among Intel GPUs, only the latest Iris Xe Graphics and UHD Graphics 750 support AV1 hardware decode. Many NVIDIA GPUs support AV1 encode and decode. See here for AV1 support details.

2. Software Support

H265:

1. x265 — encoding only
2. libde265 — decoding, with a performance report
3. HM — not just a codec library; includes encoder, decoder, tools, and examples
4. ffmpeg — decoding only

AV1:

1. libaom — Google's AV1 encoder, actively maintained
2. dav1d — VideoLAN's high-performance AV1 decoder
3. SVT-AV1
4. rav1e by Xiph

3. Chrome and WebRTC Support

Chome:

Google Chrome has supported H.265 decoding by default since M107, so you can watch some H.265 videos in the browser. See the Zhihu discussion and news coverage, October 2, 2022.

WebRTC:

WebRTC does not yet support H.265 encode/decode, but Intel's owt-deps-webrtc project already offers solid H.265 hardware encode/decode support. There are also signs that WebRTC may add H.265 — see Jianchi Hu's blog and the WebRTC issue tracker, October 2023.

4. Preparation

Integrating x265 into WebRTC requires building the x265 library yourself and wrapping it similarly to OpenH264. WebRTC supports AV1 out of the box.

4.1. Building x265

Because of licensing and adoption, there is relatively little documentation on building x265, and it took some effort. The x265 source is open source and can be cloned with git:

 git clone https://bitbucket.org/multicoreware/x265_git.git

Or download it from here. I used x265_3.5.tar.gz.

My build environment:

• 2021 MacBook Pro with M1 Pro
• macOS 14.0 Sonoma

x265 uses CMake. It includes build scripts for common platforms. On macOS, enter x265_git/build/linux and run make-Makefiles.bash to open the configuration UI. Set ENABLE_ASSEMBLY to ON for better performance, and set СМАКЕ_OSX_DEPLOYMENT_TARGET to the minimum supported macOS version. Press c to configure and g to generate the Makefile.

Run make to build. If successful, you get libx265.a and the x265_config.h header in the same directory. Include both x265.h and x265_config.h; otherwise you may see:

ld: Undefined symbols:
  _x265_encoder_open_208, referenced from:

x265_encoder_open is a macro, and its definition changes between versions.

4.2. H265 Profile

x265 only has a main profile, unlike x264's base, main, and high. Also, neither x265 nor videotoolbox supports SCC (Screen Content Coding). In practice, screen sharing still looks better than x264; comparison data follows below.

5. Encoding Quality

To make differences more visible, tests used an extreme resolution and bitrate: 320x180p at 40 kbps.

Overall, x265 looks noticeably better than x264, but at a much higher CPU cost. AV1 looks better than x265 while keeping performance under control — a clear win over x265.

x265 software encoding (ultrafast) at 180p was much worse than VideoToolbox hardware H.265 encoding. I forgot to capture screenshots, so those are omitted.

At higher or sufficient bitrates, x264, x265, and AV1 are hard to tell apart.

5.1. VideoToolbox vs AV1

Resolution: 320x180

Bitrate: 40 kbps, ABR

Complexity: AV1: Speed-6, VideoToolbox: none

Conclusion: In image 1, AV1 is slightly better on background control; overall VideoToolbox hardware encoding looks a bit better. In image 2, AV1 is clearly better on motion.

5.2. x265 vs AV1

Resolution: 320x180

Bitrate: 40 kbps, ABR

Complexity: AV1: Speed-6, x265: ultrafast

Conclusion: AV1 quality is clearly better than x265 ultrafast

5.3. x265 vs x264

Resolution: 320x180

Bitrate: ABR — image 1: 40 kbps, image 2: 100 kbps

Complexity: x264: veryfast, x265: ultrafast

Conclusion: x265 ultrafast beats x264 veryfast

5.4. x265 Very Fast vs Ultra Fast

Resolution: 640x360

Bitrate: 100 kbps, ABR

Complexity: x265: veryfast, x265: ultrafast

Conclusion: x265 veryfast beats x265 ultrafast

6. Encoding Performance

• x265 360p ultrafast: CPU 55% ~ 65%, about 10% lower than veryfast
• x265 720p ultrafast: CPU 85% ~ 95%, about 50% lower than veryfast
• x265 720p hardware encode: CPU 45% ~ 50%, about 50% lower than x265 720p ultrafast, and 5%–15% lower than 360p x265 ultrafast
• AV1 encoding is clearly better than x265, with a large advantage even over x265 ultrafast
• AV1 supports SCC screen-sharing encoding — clarity, performance, and bandwidth are all much better than x265 for screen share

I only tested AV1 encoding on iPhone 11 on mobile. At 360p and 720p, CPU usage was slightly lower than on MacBook Pro 2021 (M1 Pro), possibly because baseline demo CPU usage differed. That result was a pleasant surprise — AV1 looks ready for production. Sorry, no screenshots 😅

6.1. 360p

6.2. 720p

6.3. Screen sharing:

VideoToobox encoding uses almost no CPU; 45%–50% can be treated as the demo's baseline CPU usage.
AV1 supports SCC; X265 does not {: .prompt-warning }

6.4. Low-end device results

AV1 is slightly higher than x264 in CPU, but quality is much better — an acceptable tradeoff.

7. Rate Control

7.1. Video scene

At 180p in WebRTC, with min: 30 kbps, start: 40 kbps, max: 80 kbps, actual send bitrate. Red: AV1, green: H265 — both are close and perform well.

7.2. Screen sharing

AV1 send bitrate in WebRTC is excellent: bitrate rises with large desktop changes and scrolling, and stays very low on static frames.

Forgot to capture x265 screenshots 😓.

Elecard analysis shows H265 keyframes and overall bitrate are lower than H264 at similar visual quality.

H264 stream:

H265 stream:

8. Decoding Performance

Tested with ffplay playback, not WebRTC. At 360p, H265 decode uses noticeably more CPU than H264; at 720p it is slightly higher. AV1 is slightly above H264 but below H265.

8.1. 360p

8.2. 720p

9. Closing

These tests took a long time, and recording the data was tedious.

They gave a qualitative and quantitative picture of mainstream encoders on performance, quality, and bitrate — useful for choosing codecs in real products.

This is personal testing; mistakes are possible, especially around AV1 performance. If you run similar tests, feedback is welcome.