在線視頻市場持續(xù)快速增長，越來越多的人觀看流媒體在線內(nèi)容，實(shí)時(shí)視頻的使用量正在飆升，為了能減少存儲(chǔ)空間和提升網(wǎng)絡(luò)帶寬的利用率，視頻編碼壓縮技術(shù)已經(jīng)普遍被行業(yè)采用。

如今的客戶在視頻流方面要求 360° 的用戶體驗(yàn)，除了友好的界面、簡單的內(nèi)容搜索方式，更重要的是接收低延遲無緩沖視頻。為了滿足如此高的流媒體標(biāo)準(zhǔn)，無論是個(gè)人內(nèi)容提供商、初創(chuàng)企業(yè)和行業(yè)領(lǐng)先者，都開始意識到高彈性、可擴(kuò)展的云平臺(tái)在高質(zhì)量流媒體服務(wù)中不可替代的作用。借助云服務(wù)器，內(nèi)容服務(wù)商可以在公有云中按需定制容量和算力，更輕松地應(yīng)對突發(fā)的流量高峰和更靈活的控制成本。所以測試云服務(wù)器的編碼能力有著確切的現(xiàn)實(shí)意義。

視頻編碼壓縮技術(shù)有多個(gè)標(biāo)準(zhǔn)，根據(jù) Bitmovin 視頻開發(fā)者調(diào)查報(bào)告，自 2017 年以來， AVC/H.264 一直為主要的視頻編解碼標(biāo)準(zhǔn)，使用 H.264 受訪者始終保持在 90% 以上，在 2021 年略有下降至 83%。2020 年，42% 的受訪者正在使用 HEVC，另有 47% 的受訪者表示他們計(jì)劃在 2021 年使用。實(shí)際在 2021 年，HEVC 的采用率增長到 49%，盡管與 2020 年的采訪數(shù)據(jù)有些差距，但增幅明顯。

由此， 本文將基于騰訊云 SR1 云服務(wù)器（基于 Ampere Altra 處理器）對最為主流的編碼標(biāo)準(zhǔn) H.264 進(jìn)行評測。

Ampere Altra 處理器是為云原生應(yīng)用構(gòu)建的完整片上系統(tǒng) （SOC） 解決方案。其創(chuàng)新架構(gòu)提供可預(yù)測的高性能、高能效和線性擴(kuò)展，在多租戶環(huán)境中具有最大一致頻率和單線程內(nèi)核。我們將與傳統(tǒng)架構(gòu)的騰訊云 S6 云服務(wù)器進(jìn)行性能對比，結(jié)合成本因素，最終得出性價(jià)比的差異。

云實(shí)例配置

本次測試中，SR1 和 S6 云實(shí)例配置如下：

H.264 的評測方法

我們將使用實(shí)現(xiàn) H.264/MPEG-4 AVC 標(biāo)準(zhǔn)的開源庫 libx264 和 ffmpeg 來運(yùn)行視頻編碼，測試基準(zhǔn)借鑒了 vbench，vbench 是一種針對在云上進(jìn)行視頻轉(zhuǎn)碼的 benchmark， 也是視頻即服務(wù)（Video as a Service）工作負(fù)載的測試基準(zhǔn)。

訪問 vbench：

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

vbench 提供的 15 個(gè)輸入視頻是從 Youtube 里經(jīng)過 K-means 算法篩選，代表了不同分辨率、碼率和熵特征的具有代表性的視頻源。

vbench 定義了 5 種不同的場景：Upload， Live， VOD， Popular， Platform。每個(gè)場景對視頻的碼率和質(zhì)量都有不同的要求，所以會(huì)采用不同的編碼參數(shù)。該評測中采用 Upload 場景，Upload 場景要求轉(zhuǎn)碼速度的同時(shí)不降低視頻質(zhì)量以便后續(xù)的進(jìn)一步處理，所以采用 Single Pass 并設(shè)置 Constant Rate Factor （CRF）=18 來保證編碼的視頻質(zhì)量。

為了最大化 ffmpeg 吞吐量，我們運(yùn)行多個(gè) ffmpeg 進(jìn)程，數(shù)量等于云服務(wù)器的可用 vCPU 數(shù)量，同時(shí)使用 GNU parallel 來并行化所有的 ffmpeg 進(jìn)程。為了減少磁盤 IO 帶來的影響，ffmpeg 二進(jìn)制文件以及所有輸入和輸出文件都存儲(chǔ)在 tmpfs 上。最終以完成 15 個(gè)視頻編碼所需要的時(shí)間作為性能評價(jià)指標(biāo)。

基本測試命令如下：

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 的評測結(jié)果

我們分別在 SR1.2XLARGE32 和 S6.2XLARGE32 實(shí)例上運(yùn)行測試 30 次，然后對這 30 次的編碼時(shí)間進(jìn)行分析，以下表格是對平均時(shí)間、最大時(shí)間和最小時(shí)間的統(tǒng)計(jì)。

SR1.2xlarge32S6.2xlarge32

Average Time （s）58.3565.14

Max Time （s）58.5965.35

Min Time （s）58.2165.06

可以看到，SR1 和 S6 每次任務(wù)完成的時(shí)間都很穩(wěn)定，完成 15 個(gè)視頻編碼所需要的平均時(shí)間，SR1 比 S6 節(jié)省了 10%，如果再考慮到價(jià)格因素，意味著每條視頻的編碼成本 SR1 將比 S6 節(jié)省約 32%。

性能的擴(kuò)展性

SR1 的 CPU 處理器 Ampere Altra 采用的是單核單線程的設(shè)計(jì)，與 x86 相比一個(gè)顯著的差異是在云實(shí)例中每個(gè)核都是物理核，而不是超線程下的一個(gè)線程。所以，SR1 每個(gè)核的計(jì)算資源如 L1 和 L2 緩存都是獨(dú)享的。當(dāng)多核運(yùn)行時(shí)，核間沒有資源爭奪，具有很強(qiáng)的抗干擾性。為驗(yàn)證該特性，我們采用另外一種方法，逐次增加核數(shù)，以獲取不同核數(shù)下的 fps 數(shù)據(jù)。總 fps 隨核數(shù)的關(guān)系如圖所示。

首先同樣核數(shù)下，Ampere Altra 的實(shí)例的 fps 性能要高于 x86 的實(shí)例，而且明顯地以線性增長。而對于 x86 的 s6 實(shí)例，可以看到單數(shù)核時(shí)和相鄰偶數(shù)核時(shí)的性能增長非常小，也就是對于 SR1 實(shí)例的用戶，購買的每個(gè)核都是物理核，也得到性能的回報(bào)；而 x86 架構(gòu)的實(shí)例，用戶購買的核數(shù)有一半是邏輯核，而這些邏輯核對整體性能的提升非常有限；

理論上，基于物理核 CPU 的實(shí)例可以售賣單數(shù) vCPU 的產(chǎn)品，而對于基于 x86 超線程的云實(shí)例，售賣的產(chǎn)品配置就只能是偶數(shù)核。這或許也是目前云產(chǎn)品都是偶數(shù)配置的原因之一。

總結(jié)

我們分別在基于 Ampere Altra CPU 的實(shí)例 SR1 和基于 x86 CPU的 S6 實(shí)例上進(jìn)行了 h.264 編碼的測試。無論是單純的性能，還是綜合性價(jià)比，SR1 實(shí)例都優(yōu)于 S6，可以為用戶節(jié)省 30% 以上的成本。

同時(shí)，通過本次測試，我們也驗(yàn)證了單線程物理核設(shè)計(jì)相對傳統(tǒng)超線程模式設(shè)計(jì)的獨(dú)特優(yōu)勢，即性能隨著核數(shù)的增加可線性擴(kuò)展。

附錄

該評測中使用的 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