在線視頻市場持續快速增長，越來越多的人觀看流媒體在線內容，實時視頻的使用量正在飆升，為了能減少存儲空間和提升網絡帶寬的利用率，視頻編碼壓縮技術已經普遍被行業采用。

如今的客戶在視頻流方面要求 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：

http://arcade.cs.columbia.edu/vbench/

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.2xlarge32S6.2xlarge32

Average Time （s）58.3565.14

Max Time （s）58.5965.35

Min Time （s）58.2165.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 的版本以及編譯方法如下。

軟件編譯

x264git 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

ffmpegexport 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