腾讯 Arm 云实例评测系列

腾讯 Arm 云实例评测系列 - 视频云编码

在线视频市场持续快速增长，越来越多的人观看流媒体在线内容，实时视频的使用量正在飙升，为了能减少存储空间和提升网络带宽的利用率，视频编码压缩技术已经普遍被行业采用。如今的客户在视频流方面要求 360°的用户体验，除了友好的界面、简单的内容搜索方式，更重要的是接收低延迟无缓冲视频。为了满足如此高的流媒体标准，无论是个人内容提供商、初创企业和行业领先者，都开始意识到高弹性、可扩展的云平台在高质量流媒体服务中不可替代的作用。借助云服务器，内容服务商可以在公有云中按需定制容量和算力，更轻松地应对突发的流量高峰和更灵活的控制成本。所以测试云服务器的编码能力有着确切的现实意义。

视频编码压缩技术有多个标准，根据 Bitmovin 视频开发者调查报告，自 2017 年以来， AVC/H.264 一直为主要的视频编解码标准，使用 H.264 受访者始终保持在 90% 以上，在 2021 年略有下降至 83%。2020 年，42% 的受访者正在使用 HEVC，另有 47% 的受访者表示他们计划在 2021 年使用。实际在 2021 年，HEVC 的采用率增长到 49%，尽管与 2020 年的采访数据有些差距，但增幅明显。

由此，本文将基于腾讯云 SR1 云服务器（基于 Ampere Altra 处理器）对最为主流的编码标准 H.264 进行评测。

Ampere® Altra® 处理器是为云原生应用构建的完整片上系统 (SOC) 解决方案。其创新架构提供可预测的高性能、高能效和线性扩展，在多租户环境中具有最大一致频率和单线程内核。我们将与传统架构的腾讯云 S6 云服务器进行性能对比，结合成本因素，最终得出性价比的差异。

云实例配置

本次测试中，SR1 和 S6 云实例配置如下：

H.264 的评测方法

我们将使用实现 H.264/MPEG-4 AVC 标准的开源库 libx264 和 ffmpeg 来运行视频编码，测试基准借鉴了 vbench，vbench 是一种针对在云上进行视频转码的 benchmark, 也是视频即服务（Video as a Service）工作负载的测试基准。

vbench 提供的 15 个输入视频是从 Youtube 里经过 K-means 算法筛选，代表了不同分辨率、码率和熵特征的具有代表性的视频源。

vbench 定义了 5 种不同的场景：Upload, Live, VOD, Popular, Platform。每个场景对视频的码率和质量都有不同的要求，所以会采用不同的编码参数。该评测中采用 Upload 场景，Upload 场景要求转码速度的同时不降低视频质量以便后续的进一步处理，所以采用 Single Pass 并设置 Constant Rate Factor (CRF)=18 来保证编码的视频质量。

为了最大化 ffmpeg 吞吐量，我们运行多个 ffmpeg 进程，数量等于云服务器的可用 vCPU 数量，同时使用 GNU parallel 来并行化所有的 ffmpeg 进程。为了减少磁盘 IO 带来的影响，ffmpeg 二进制文件以及所有输入和输出文件都存储在 tmpfs 上。最终以完成 15 个视频编码所需要的时间作为性能评价指标。

基本测试命令如下：

parallel  -j${JOBS}  =/opt/cloud/ffmpeg/bin/ffmpeg -threads ${THREADS} -y -i {} -c:v libx264 -preset medium -crf 18  {.}.out.mkv &/dev/null ::: input/*.mkv

H.264 的评测结果

我们分别在 SR1.2XLARGE32 和 S6.2XLARGE32 实例上运行测试 30 次，然后对这 30 次的编码时间进行分析，以下表格是对平均时间、最大时间和最小时间的统计。

| | SR1.2xlarge32 | S6.2xlarge32 | |------------------|---------------|--------------| | Average Time (s) | 58.35 | 65.14 | | Max Time (s) | 58.59 | 65.35 | | Min Time (s) | 58.21 | 65.06 |

可以看到，SR1 和 S6 每次任务完成的时间都很稳定，完成 15 个视频编码所需要的平均时间，SR1 比 S6 节省了 10%，如果再考虑到价格因素，意味着每条视频的编码成本 SR1 将比 S6 节省约 32%。

性能的扩展性

SR1 的 CPU 处理器 Ampere Altra 采用的是单核单线程的设计，与 x86 相比一个显著的差异是在云实例中每个核都是物理核，而不是超线程下的一个线程。所以，SR1 每个核的计算资源如 L1 和 L2 缓存都是独享的。当多核运行时，核间没有资源争夺，具有很强的抗干扰性。为验证该特性，我们采用另外一种方法，逐次增加核数，以获取不同核数下的 fps 数据。总 fps 随核数的关系如图所示。

首先同样核数下，Ampere Altra 的实例的 fps 性能要高于 x86 的实例，而且明显地以线性增长。而对于 x86 的 s6 实例，可以看到单数核时和相邻偶数核时的性能增长非常小，也就是对于 SR1 实例的用户，购买的每个核都是物理核，也得到性能的回报；而 x86 架构的实例，用户购买的核数有一半是逻辑核，而这些逻辑核对整体性能的提升非常有限；

理论上，基于物理核 CPU 的实例可以售卖单数 vCPU 的产品，而对于基于 x86 超线程的云实例，售卖的产品配置就只能是偶数核。这或许也是目前云产品都是偶数配置的原因之一。

总结

我们分别在基于 Ampere Altra CPU 的实例 SR1 和基于 x86 CPU的 S6 实例上进行了 h.264 编码的测试。无论是单纯的性能，还是综合性价比，SR1 实例都优于 S6，可以为用户节省 30% 以上的成本。同时，通过本次测试，我们也验证了单线程物理核设计相对传统超线程模式设计的独特优势，即性能随着核数的增加可线性扩展。

附录

该评测中使用的 x264, x265 和 ffmpeg 的版本以及编译方法如下。

x264

git clone https://code.videolan.org/vi
deola
n/x264.git
cd x264
./configure --disable-opencl --enable-pic --enable-shared --prefix=/opt/cloud/ffmpeg
make -j `nproc`
sudo make install-lib-shared

ffmpeg

export PKG_CONFIG_
PATH=$PKG_CONFIG_
PATH:/opt/cloud/ffmpeg/
lib/pkgc
onfig
git clone https://git.ffmpeg.org/ffm
peg.git
cd ffmpeg
./configure --enable-gpl --enable-libx264  --disable-stripping  --prefix=/opt/cloud/ffmpeg
make -j `nproc`
sudo make install