文章

H.265、AV1和H.264视频编码对比:x265性能不及预期,Libaom表现亮眼

都2023年了,我们不禁要问,AV1编码的性能如何?是否已经适用于生产环境?另外,H.265相对于H.264真的能够节省一半的带宽吗?

本文详细比较了H.265、AV1和H.264等视频编码标准在性能、质量和带宽利用率等方面的表现。测试中使用了x264、x265、VideoToolbox和libaom等编码器,并选择了MacBook Pro 2021年款(搭载M1 Pro芯片)作为测试设备。

总体测试结果显示,x265的表现并不如预期,性能消耗甚至不能满足实时通信的生产环境需求。而libaom则表现出色,既具备优秀的质量,又具备良好的性能。

无论是x265还是AV1,相较于H.264,都能够实现较低的码率和更高的编码质量。

此外,AV1针对屏幕共享方面进行了专门的编码参数设置,进行了编码算法的优化,并且对码率控制进行了良好的处理。而x265和VideoToolbox则没有提供相关的设置。

1. 硬件支持

H265:

  • 苹果从iOS 11 + A9芯片(iPhone 6s,于2015年9月发布)开始对HEVC的支持,系统控件AVPlayer,以及Safari浏览器的支持; 硬编码需要iOS11 + A10(iPhone 7)芯片, 参考
  • Android手机从2015年开始逐渐支持H.265编码,Android 5.0(Lollipop)是首批开始支持H.265编码的Android版本;

然而,并非所有在Android 5.0及之后发布的设备都能够完全支持H.265编码,因为支持的编解码器可能因设备型号和制造商而异。通常情况下,高端或中高端的Android设备更有可能支持H.265编码。

  • 桌面端intel核显和英伟达显卡大部分已经H265, H265具体支持情况可以查看 这里

AV1:

  • Android平台:高通 8 Gen2 开始支持 AV1硬解, 小米13首先搭载,2022年12月发布;
  • 苹果A17 Pro包含一个专用的AV1解码器,随iPhone15 Pro一块发布,2023年9月发布;
  • Mac端 M3 芯片芯片开始支持 AV1解码,2023年10月30日发布;
  • PC端,目前Intel只有最新的Iris Xe GraphicsUHD Graphics 750支持AV1硬解,英伟达很大一部分显卡支持AV1编解码,AV1具体支持情况可以查看 这里

2. 软件支持

H265:

  1. x265 仅支持编码;
  2. libde265 支持解码, 性能报告
  3. HM 不仅仅是一个编码库,还包含了编码器、解码器以及各种工具和示例;
  4. ffmpeg 仅支持解码;

AV1:

  1. libaom 谷歌维护的AV1编码库,看git记录一直在积极更新;
  2. dav1d videolan维护的高性能 AV1 解码器;
  3. SVT-AV1
  4. rav1e by Xiph

3. Chrome 和 WebRTC支持情况

Chome:

谷歌浏览器 从M107版本默认支持H265解码,也就是说可以用浏览器看一些H265在线视频。 关于此消息它的讨论可以看知乎讨论资讯,2022年10月2日

WebRTC:

WebRTC目前还不支持H265编解码,但Intel维护的owt-deps-webrtc项目已经有对H265硬编硬解的比较好的支持,但有消息称WebRTC正在考虑将H265引入,可以参考剑痴乎 博客和 WebRTC官方论坛, 2023年10月;

4. 准备工作

WebRTC集成x265需要自己编译x265的库,并参考openh264调用做相应的封装。 WebRTC默认支持AV1,直接使用就可以。

4.1. x265编译

可能由于版权以及普及率的原因,网上关于x265编译的介绍比较少,编译x265也费了一些力气。x265本身代码是开源的,可以通过git 克隆下代码

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

或者从 这里下载 ,我使用的版本是 x265_3.5.tar.gz

我的编译环境是

  • 2021年 M1 Pro版本的Mac笔记本
  • MacOS 14.0 Sonoma

x265使用的是cmake管理源文件,已经内置了一些主流平台的编译脚本,对于MacOS 用户可以进入源码目录 x265_git/build/linux 执行 make-Makefiles.bash,会出现配置界面。注意ENABLE_ASSEMBLY置为ON,提高编码性能, СМАКЕ_OSX_DEPLOYMENT_TARGET 设置最低支持系统版本。最后按 c 进行配置,按g生成 makefile.

执行 make命令开始编译,没有错误的话会在同级目录生成 libx265.a, 以及 x265_config.h头文件,使用的时候 x265.hx265_config.h 要同时引入,否则可能会报错:

1
2
ld: Undefined symbols:
  _x265_encoder_open_208, referenced from:

x265_encoder_open是一个宏,每个版本的x265_encoder_open定义都不同。

4.2. H265 Profile

x265的Profile只有main一个级别,不像x264有base, main, high 多个级别, 另外 x265videotoolbox 都不支持 SCC(屏幕内容编码,Screen Content Coding),实测下来屏幕共享场景还是优于x264,后面会有对比数据。


5. 编码质量

为了能较明显的区别出编码的好坏,选取了比较极限的分辨率和码率测试,320x180p,40kbps.

整体上看x265比x264画质是要有较明显提升,但是性能消耗也提高很多。AV1画质表现比x265要好,且性能消耗也能较好的控制,优于x265很多。

x265 软编(ultrafast)效果 180p, 比Videotoolbox硬编(H265)差很多, 忘了截图了,就不放了。

另外在码率较大或者说充足的情况下,x264, x265,av1的编码质量很难分辨出优劣。

5.1. VideoToolbox与AV1对比

分辨率:320x180

码率:40kbps,ABR

复杂度级别:AV1: Speed-6 , VideoToolbox:无

结论: 图一画面AV1的背景控制部分略优于VideoToolbox,整体画面VdieoToolbox硬编要好一点;图二,AV1运动画面要明显优于VideoToolbox硬编。

5.2. x265与AV1对比

分辨率:320x180

码率:40kbps,ABR

复杂度级别:AV1: Speed-6 , x265: ultrafast

结论: AV1编码质量明显优于x265 ultrafast档

5.3. x265与x264对比

分辨率:320x180

码率:ABR,图1:40kbps, 图2:100kbps

复杂度级别:x264: veryfast, x265: ultrafast

结论: x265 ultrafast档 要优于 x264 veryfast档

5.4. x265 Very Fast 对比 Ultra Fast

分辨率:640x360

码率:100kbps,ABR

复杂度:x265: veryfast, x265: ultrafast

结论: x265 veryfast档 要优于 x265 ultrafast档

6. 编码性能

  • x265 360p ultrafast的性能 CPU 55% ~ 65%,比veryfast低10%左右
  • x265 720p ultrafast的性能 CPU 85% ~ 95%,比veryfast低50%左右
  • x265 720p 硬编的性能 CPU 45% ~ 50%,比x265 720p ultrafat低50%左右, 比360p x265 ultra fast低5%-15%
  • av1的编码性能要明显优于x265, 比x265的ultrafast档还有很大优势
  • av1 支持 SCC 屏幕共享编码,屏幕共享清晰度,编码性能和带宽都比x265优非常大优势

手机端只在iPhone 11上进行了AV1编码测试,360p和720p的性能表现竟然比Macbook Pro 2021 (M1 Pro) CPU低一点点,可能Demo的基础CPU消耗不一样。 这个结果可以说非常惊喜了,证明了AV1完全可以应用生成环境了。忘记截图,见谅😅

6.1. 360p

分辨率编码器CPU备注
640x360VideoToobox45%~50%基准CPU
640x360X265 ultrafast55% ~ 65% 
640x360X265 veryfast70% ~ 75%高于ultrafast
640x360AV150% ~ 55%优于x265

6.2. 720p

分辨率编码器CPU备注
1280x720VideoToobox45%~50%基准CPU
1280x720X265 ultrafast85% ~ 95% 
1280x720X265 veryfast145% ~ 160% 
1280x720AV1暂缺 

6.3. 桌面共享:

分辨率编码器CPU备注
1920x1246VideoToobox45%~50% 
1920x1246X265 veryfast180% ~ 204% 
1920x1246AV159% ~ 90%静止低,滑动高

VideoToobox 编码基本不占用CPU,45%~ 50% CPU占用可以认为是Demo的基本CPU占用。
AV1支持SCC, X265不支持

6.4. 低端机测试情况

机器分辨率编码器CPU
🍎360P   
iphone6640x360x26495-142%
iphone6640x360av193-127%
iphoneXR640x360x26456-59%
iphoneXR640x360av164-67%
荣耀畅玩20640x360x26412-17%
荣耀畅玩20640x360av114-22%
Honor 30640x360x2649-17%
Honor 30640x360av116-21%
🍎720P   
iphone61280x720x264112-129%
iphone61280x720av1144-167%
iphoneXR1280x720x26488-101%
iphoneXR1280x720av1120%
荣耀畅玩201280x720x26419-26%
荣耀畅玩201280x720av125-47%
Honor 301280x720x26417-27%
Honor 301280x720av122-30%

AV1略高于 x264,但质量高于x264非常多,这点性能差距完全可以接受!

7. 码率控制

7.1. 视频场景

180p场景,Webrtc中码率设置 min: 30kbps,start:40kbps,max:80kbps实际发送码率表现。红色:AV1, 绿色:H265, 可以看到两者相差不大,表现都非常不错

7.2. 屏幕共享

AV1在WebRTC发送码率实测表现,可以说非常优秀,桌面画面变动大,滚动文字页面等场景码率变大,静止画面码率非常低。

x265忘记了截图😓。

使用Elecard分析,可以看到H265的关键帧和整体码率是要小于H264的,画质清晰度相当。

H264码流:

H265码流:

8. 解码性能

通过ffplay播放视频来测试,并没有使用WebRTC。 可以看到360p分辨率H265解码比H264解码性能消耗要提高不少,720p略高于H264;AV1略高于H264,但低于H265

8.1. 360p

分辨率解码器CPU备注
640x360H264-ffplay13% 
640x360H265-ffplay24.3% 
640x360AV1(ffplay-dav1d)22.2% 

8.2. 720p

分辨率解码器CPU备注
1280x720H264-ffplay34.6% 
1280x720H265-ffplay40.3% 
1280x720AV1(ffplay-dav1d)36.9% 

9. 结尾

整个测试持续了非常长时间,检测记录数据非常繁琐。

通过这个测试整体对主流编码器的性能,质量和码率方面的表现有了定性和定量的认识,也为实际业务开发选择提供的参考。

本文测试属于个人测试,难免有测试错误,尤其想av1的性能表现,欢迎大家也做类似测试,如有问题欢迎留言反馈交流。

本文由作者按照 CC BY 4.0 进行授权