緣由

自我在 2020 年 4 月末購買了 GoPro 運動相機后，我便開始了 4K 視頻的拍攝。

GoPro 在硬件層面上支持 HEVC（也就是 H.265）編碼，它相比于常用的 H.264 編碼，能夠以更低的碼率存儲同樣的視頻內(nèi)容，節(jié)省設(shè)備空間。不過，以我當時的電腦性能，連播放都困難，更別提剪輯了。所以我基本上都是把這個功能關(guān)掉，實在需要的時候再開；剪輯前，先把編碼格式轉(zhuǎn)換為 H.264——前面也說過，電腦連播放都困難，轉(zhuǎn)換就更慢了。

后來我組裝了電腦，顯卡買的是 GTX 1660S，可以硬解 HEVC。不過常用的視頻平臺仍然只接受 H.264 編碼的視頻，否則會遭到二壓，極大影響視頻畫質(zhì)。另外，我當時買了 3 TB 的硬盤，終于不需要考慮磁盤空間的限制了。因此，我輸出的視頻仍然使用 H.264 編碼。至于拍攝的視頻，就看設(shè)備的默認選項。順帶一提，我 2022 年把 GoPro 賣掉，

我買車之后，買了大疆 Pocket 2，在駕駛時把大疆 Pocket 2 固定在車前，拍攝行程街景，也就是有些人常說的 POV（Point?of?View）視頻。 自駕 POV 視頻相較于其他的（如列車、公交） POV 視頻，視野受外部干擾小，對他人影響小，接受度和質(zhì)量更高。成片一般都是快放若干倍，但考慮到后期處理方便、能夠同時生成原速視頻用于直播等場景，以及與其他的錄制（如導(dǎo)航錄屏）同步，我使用的是一般的錄制功能，而不是延時攝影。加上大疆 Pocket 2 錄制的視頻編碼固定為 H.264，導(dǎo)致生成的文件特別大，一般來說，64 GB 只能錄制不到一個半小時的 4K 25 fps 視頻。

這樣一來，那個 3 TB 的硬盤明顯捉襟見肘。于是我又買了塊 4 TB 的硬盤。結(jié)果，到了現(xiàn)在，我連那塊硬盤都不夠用了。

于是我萌生了一個想法：將硬盤里面的素材視頻都壓制成較小占用空間的格式。

這時，各大視頻平臺已經(jīng)陸續(xù)支持了 HEVC 和 AV1 編碼格式。AV1 相較于 HEVC，壓縮率和畫質(zhì)都占優(yōu)勢。只可惜，我的顯卡不支持 AV1 硬解，且我常用的 Adobe Premiere 目前還不支持該編碼，所以目前還是考慮 HEVC 編碼。

我一開始是在導(dǎo)出視頻時，即設(shè)置為以 HEVC 編碼導(dǎo)出。自己看不出畫質(zhì)差別有多大，上傳到視頻網(wǎng)站后，平臺二壓之后的結(jié)果就更看不出了。

但是，壓制視頻到 HEVC 編碼的事情，我以前也不是沒做過，但是當時網(wǎng)上的資料太少，我就自己摸索參數(shù)配置，結(jié)果給我的感覺是：畫質(zhì)縮水太嚴重。所幸現(xiàn)在我能夠搜索到許多相關(guān)的資料，而且車出車禍了，我也暫停了拍攝計劃；加之天氣炎熱，電（wǒ）腦（lǎn）也（de）閑（jiǎn）了（shì）下（pín）來（le）。所以，我正好有時間去讓電腦去測試壓制視頻的最佳方案。

環(huán)境

• CPU：AMD Ryzen 7 3700X

• GPU：NVIDIA GeForce GTX 1660 SUPER

• 系統(tǒng)：Windows 11 專業(yè)版 22H2

• 其他軟件：

• HandBrake（開源的視頻處理工具，可設(shè)置項很多，本例中使用 x265 或 NVENC 編碼視頻）

• 小丸工具箱（我平常較常用的壓制工具，本例中使用 x265 編碼視頻）

• Adobe Media Encoder（視頻處理工具，較常用于 Adobe Premiere 和 Adobe After Effects，也可以用于壓制視頻）

• FFmpeg（開源的多媒體處理工具，以 VMAF 模型評估視頻質(zhì)量）

• Adobe Premiere Pro 2023（我平常較常用的視頻剪輯工具，從原始素材生成 H.264 視頻作為待壓制視頻、生成 HEVC 視頻作為對照視頻）

Adobe 相關(guān)的軟件均開啟 GPU 加速。

測試視頻信息

測試視頻為我于 2023-05-13 發(fā)布于各大視頻平臺的《南京“中軸線”（中央北路-鐵心橋大道）自駕 POV》。它幀率較高，畫面、場景變換較復(fù)雜，用來測試畫質(zhì)效果較明顯。

其中一個使用大疆 Pocket 2 拍攝的素材，小丸工具箱內(nèi)使用 MediaInfo 解析信息如下：

工程先前已生成 H.264 視頻，以此測試各配置的壓制效果。解析信息如下：

用 Adobe Premiere Pro 從工程文件中生成 HEVC 視頻，以“4K UHD”為藍本修改，一些參數(shù)如下：

• 視頻

• 基本視頻設(shè)置：匹配源，以最大深度渲染、使用最高渲染質(zhì)量

• 編碼設(shè)置：

• 性能：硬件加速

• 配置文件：主要（匹配源）

• 級別：5.1（匹配源）

• 層：高

• 比特率設(shè)置

• 比特率編碼：VBR, 1 次

• 目標比特率 [Mbps]：60

• 質(zhì)量：好

預(yù)設(shè)名為?adobe，作為對照視頻，作為參考。

壓制選項

整個測試過程中，因設(shè)備、時間等限制，我均會考慮前面的測試結(jié)果，忽略無意義的測試組合，動態(tài)調(diào)整接下來的測試預(yù)設(shè)。限于篇幅，我僅給出測試方法和最終的測試結(jié)果，而實際上我會多次比對已有的測試結(jié)果，制定接下來的測試組合。

我主要采用 HandBrake 進行壓制。

在 HandBrake 中，我以自帶預(yù)設(shè)“Vimeo YouTube HQ 2160p60 4K”為藍本，修改如下（下列選項如有斜杠，表示此處有多種預(yù)設(shè)的排列組合，實際上僅取部分組合進行測試，以測試結(jié)果為準）：

• 尺寸 > 分辨率限制：無

• 視頻

• 編碼器：H.265 (x265 / NVEnc）

• 幀率：Same as source，固定幀率

• 編碼器預(yù)設(shè)：

• x265：Medium / Slow / Slower

• NVEnc：Medium / Slowest

• 質(zhì)量：固定質(zhì)量：

• x265：21 / 18 / 17 RF

• NVEnc：21 / 18 / 0 CQ

• 音頻 > 編碼：AAC (avcodec) Bitrate: 320

最后生成的視頻有以下預(yù)設(shè)，放到文件前綴，此后對比也采用此名稱：

• handbrake_cq21_nvenc_medium

• handbrake_cq21_nvenc_slowest

• handbrake_crf21_x265_medium

• handbrake_crf21_x265_slow

• handbrake_crf21_x265_slower

• handbrake_crf17_x265_medium

• handbrake_crf17_x265_slow

• handbrake_cq18_nvenc_medium

• handbrake_cq18_nvenc_slowest

• handbrake_crf18_x265_medium

• handbrake_crf18_x265_slow

• handbrake_cq0_nvenc_medium

• ??handbrake_cq0_nvenc_slowest

小丸工具箱中，我設(shè)置如下：

• 編碼器：x265_64-8bit[gcc].exe

• 音頻模式：復(fù)制音頻流

• CRF：18

• 保持原分辨率

預(yù)設(shè)名為?maruko_crf18_x265。

另外，我使用 Adobe Media Encoder 進行了測試，配置與?adobe?一樣，預(yù)設(shè)名為?adobeme。兩者的區(qū)別是：前者從工程文件中生成視頻，后者根據(jù)已生成的視頻文件壓制視頻。

寫這篇文章的時候，我才發(fā)現(xiàn)，上面 HandBrake 相關(guān)的預(yù)設(shè)里面原先有一些高級選項參數(shù)，但因為它原本是為了進行 H.264 編碼，故切換到 H.265 編碼時，高級選項內(nèi)容為空。H.265 相關(guān)的預(yù)設(shè)中，是有一些高級選項的。簡單查了一下參數(shù)表達的含義后，我想：如果有參數(shù)的話，結(jié)果應(yīng)該還會有不同吧。

于是，我又以自帶預(yù)設(shè)“H.265 MKV 2160p60”為藍本，修改如下：

• 摘要 > 格式：MP4，網(wǎng)頁優(yōu)化、音視頻起始對齊、保留常見元數(shù)據(jù)

• 尺寸 > 分辨率限制：無

• 視頻

• 編碼器：H.265 (x265 / NVEnc）

• 幀率：Same as source，固定幀率

• 編碼器預(yù)設(shè)：Medium

• 高級選項（實際上我未動，是預(yù)設(shè)帶出的）：

• x265：strong-intra-smoothing=0:rect=0:aq-mode=1

• NVEnc：rc-lookahead=10

• 質(zhì)量：固定質(zhì)量：

• x265：18 RF

• NVEnc：18 CQ

• 音頻 > 編碼：AAC Passthru

由于時間限制，我參考此前的結(jié)果，只做了兩種預(yù)設(shè)的排列組合。預(yù)設(shè)名如下：

• handbrake_crf18_x265_medium_prefs

• handbrake_crf18_nvenc_medium_prefs

視頻質(zhì)量分析

考慮到素材可能還要用，我優(yōu)先考慮視頻的畫質(zhì)。

但是，如果僅憑肉眼，視頻畫質(zhì)并不好對比。如果畫質(zhì)差別明顯的話，還好對比；但是如果不明顯的話，就很難看出來了；此外，我的每個視頻都挺長的，就更難憑肉眼比對了。所幸，我可以憑借 VMAF 來讓電腦評價視頻質(zhì)量。

VMAF（Video?Multimethod?Assessment?Fusion，視頻多方法評估融合）是 Netflix 與南加州大學、南特大學以及德克薩斯大學奧斯汀分校聯(lián)合開發(fā)的開源視頻質(zhì)量評價指標，通過轉(zhuǎn)碼視頻和原視頻每一幀畫面對比評分，最后給出所有幀的平均分即為轉(zhuǎn)碼視頻的畫質(zhì)質(zhì)量。

FFmpeg 集成了 VMAF 的畫質(zhì)模型，對于 4K 的視頻，可以借助下面的命令使用：

如：

一般來說這種對比是取一小段的，對時長為 13 分 38 秒的視頻，對比花費的時間就超過了 5 小時。

本例中，我均以 H.264 視頻作為對照文件，包括工程生成的 HEVC 視頻也是以 H.264 視頻對照。

執(zhí)行最后會輸出一個平均的 VMAF 值：

一般可以把它當成百分數(shù)看，表示相比于對照文件，檢測文件的畫質(zhì)。

據(jù)網(wǎng)上他人的說法，98 分以上和原片幾乎無法區(qū)分，95 分以上基本沒有差異，93 ~ 95 分能感知到差異但可接受，91 分以下通常差異比較明顯。

實際上，熟悉壓制的人應(yīng)該知道，不能簡單拿一個平均值去評價畫質(zhì)。視頻里各片段的復(fù)雜度不盡相同，一些簡單的片段很容易壓制好，而復(fù)雜的片段用相同的標準去壓制，就會一團糟。

如下面的例子：

A 和 B 截取自 H.264 視頻的不同幀，C 和 D 截取自預(yù)設(shè)為?handbrake_cq21_nvenc_medium?的 HEVC 壓制視頻的對應(yīng)幀處。在 Adobe Photoshop 中將 A 覆蓋在 C 上、B 覆蓋在 D 上，設(shè)置 A、B 的圖層模式為“差值”，再使用曲線工具，在反色的基礎(chǔ)上調(diào)整，得 E 和 F。

G 為 A 的局部，H、I 為 B 的局部；J、K 和 L 分別與 G、H 和 I 在同一位置上，但截取自 C 和 D；M、N 和 O 分別與 G、H 和 I 在同一位置上，但截取自 E 和 F。

我們可以發(fā)現(xiàn)，同樣的預(yù)設(shè)下，較為復(fù)雜的幀易出現(xiàn)失真嚴重的情況。因此，我們需要得到每一幀的畫質(zhì)信息。

之前執(zhí)行 FFmpeg 命令的時候，輸出最終結(jié)果的時候，F(xiàn)Fmpeg 會把每一幀的對比結(jié)果輸出到上面給定的 JSON 文件中，格式形如：

對于我來說，需要取每幀的 VMAF 值，以檢查畫質(zhì)是否出現(xiàn)極端情況（如某些幀的 VMAF 遠小于平均值）。所以，需要把每幀的 VMAF 值取出來，編寫 Python 腳本如下：

以上會對每個 JSON 文件在原位輸出一個名稱相同的 UTF-8 帶 BOM 的 CSV 文件，以便用 Excel 打開。其實改一下可以合并到一個文件里面，但是我懶得改了。

最后，把所有數(shù)據(jù)放在 Excel 中，并處理。

當原視頻與原視頻對比時，VMAF 不一定能到 100 分，不過足夠接近。所以我進行了該對比，結(jié)果為 100。因此，可以將每幀的 VMAF 值視為畫質(zhì)相較于源文件的質(zhì)量的百分比。

這里我放一張圖，展示兩個預(yù)設(shè)在每幀上的 VMAF ，以及 VMAF 的 180 周期（3 s）移動平均值的變化情況。

數(shù)據(jù)處理

Excel 內(nèi)的源數(shù)據(jù)除了每幀的 VMAF 值、文件的平均 VMAF 值?avg_vmaf?外，還有如下的指標：

• 編碼用時?time

• 壓制后文件大?。ㄎ胰〉氖窍噍^于源文件的壓縮比）sizex

另外，對于 VMAF，我按照前面提到的 VMAF 值與畫質(zhì)的關(guān)系，劃分了 4 個區(qū)間：

• VMAF ≥ 98

• 95 ≤ VMAF < 98

• 93 ≤ VMAF < 95

• VMAF < 91

計算屬于對應(yīng)區(qū)間的幀的比例。由于也可視為某一幀落在對應(yīng)區(qū)間上的概率，故可以概率的方式記做?p(條件)。

另外，我還計算下面的值：

• VMAF < 98 的幀中，VMAF ≥ 95 的比例?p(vmaf>=95|vmaf<98)

• VMAF < 95 的幀中，VMAF ≥ 93 的比例?p(vmaf>=93|vmaf<95)

除此之外，我引入了 VMAF 積分的概念，為落在不同 VMAF 區(qū)間的幀的 VMAF 值賦予權(quán)重。權(quán)重如下：

• VMAF ≥ 98：1

• 95 ≤ VMAF < 98：0.6

• 93 ≤ VMAF < 95：0.2

• 91 ≤ VMAF < 93：-0.5

• VMAF < 91：-1

結(jié)果為各幀的 VMAF 值乘以各自權(quán)重的結(jié)果之和。

我想把結(jié)果繪制成雷達圖。為了保證數(shù)值增長方向的一致性（數(shù)值越大表示越好），以下指標需要取倒數(shù)：

• 編碼用時

• 壓縮比

• VMAF < 91 的幀的比例

各記為?1/指標。

本來我還要把倒數(shù)處理到 1 以下。但是，我發(fā)現(xiàn)前面關(guān)于 VMAF 比例的計算結(jié)果過于集中，放在雷達圖上會擠成一片。為了能夠在雷達圖上呈現(xiàn)明顯的差別，我決定最后把得到的值以指標為集合，最差值記為 0，最好值記為 1，轉(zhuǎn)換為 0-1 區(qū)間?？梢杂上旅娴墓降贸觯?/p>

由于一些預(yù)設(shè)的效果太差，我并沒有對全部生成的視頻做上述的檢測與分析。

數(shù)據(jù)可視化與比對

由于數(shù)據(jù)量太大，處理花了很長時間，這里只放排名前的計算結(jié)果：

排名、制作圖表時，我分了這幾種情況去排名：

• 全部預(yù)設(shè)參與排名（Adobe 相關(guān)預(yù)設(shè)主要用以對照，下同）

• 軟解 + Adobe 相關(guān)預(yù)設(shè)參與排名（因為硬解相關(guān)畫質(zhì)結(jié)果普遍不好）

• 軟解 - 小丸工具箱 + Adobe 相關(guān)預(yù)設(shè)參與排名（小丸工具箱壓制的視頻 VMAF 太低，但檢查視頻發(fā)現(xiàn)畫質(zhì)并不低，故需排除，以查看其他軟解預(yù)設(shè)的數(shù)據(jù)）

由于軟解用時普遍偏高，而用以對照的?adobeme?預(yù)設(shè)用時極低，在雷達圖上難以看清各軟解預(yù)設(shè)的壓縮用時效率，故另外畫條形圖展示軟解相關(guān)預(yù)設(shè)的用時情況。

結(jié)果如圖：

上面的圖中，不帶星號?*?的指標都是越高越好，帶星號的指標僅為參考用。

上述過程花費 10 天左右。

無法通過計算發(fā)現(xiàn)的問題

此前提到過，小丸工具箱生成的視頻，VMAF 非常低，但是實際觀看視頻發(fā)現(xiàn)，畫質(zhì)并沒有像 VMAF 一樣有著非常大的下降。但除此之外，還有一個僅憑上述計算無法發(fā)現(xiàn)的問題。

原視頻 1:31 ~ 1:41 處，畫面右側(cè)的居民樓上有百葉箱。

但是壓制后，?handbrake_?開頭的預(yù)設(shè)的文件中出現(xiàn)了嚴重的摩爾紋：

沒有出現(xiàn)該情況的預(yù)設(shè)，除了 Adobe 的那兩個外，就只有小丸工具箱的了。應(yīng)該是小丸工具箱對 x265 有另外傳入的參數(shù)。

查看日志，當時處理視頻時的參數(shù)如下，供參考：

在自定義命令行中，我將?--preset?改為?medium?，壓制時速度明顯提升。但是，視頻在定點播放時，播放器卡得不行。后來發(fā)現(xiàn)，小丸工具箱直接把其他參數(shù)忽略了。但是，視頻中的百葉箱還是比較正常的。

但是我把上面一長串參數(shù)放進 HandBrake，生成的視頻里面又出現(xiàn)之前的摩爾紋了。不知道是為什么。

分析結(jié)果

正如標題所述，這次測試結(jié)果僅能代表城市街景題材 SDR 4K 視頻的情況，其他的我手頭沒什么資料。

• 硬解僅在壓縮用時上占優(yōu)勢，畫質(zhì)遠遠不如軟解。但軟解耗時遠超過硬解。如果必須用硬解，優(yōu)先選擇 Adobe 的工具。

• 相較于壓制時設(shè)定的質(zhì)量（[C]RF/CQ)，編碼器預(yù)設(shè)對畫質(zhì)、耗時的影響更大。

• 以?_prefs?為后綴的預(yù)設(shè)中，高級選項的加入僅對耗時和壓縮率有輕微的正面影響，對畫質(zhì)反而起到反作用。

• 如果用 x265 壓制，編碼器預(yù)設(shè)最慢調(diào)至 slow 即可， slower 的畫質(zhì)提升效果不明顯，且極為耗時。

• 上面添加的高級選項并未對壓制起到正向效果。

• 如果優(yōu)先考慮畫質(zhì)，handbrake_crf17_x265_slow?預(yù)設(shè)不錯。

• 如果稍微考慮一下時間，可以考慮?handbrake_crf17_x265_medium?預(yù)設(shè)。

• 小丸工具箱壓制出的視頻，雖然 VMAF 值極低，但是目測畫質(zhì)并不差；而且也沒有出現(xiàn)上面提到的摩爾紋的情況。

結(jié)尾

總之，十幾天的測試，耗費了我不小的力氣?？上ВY(jié)果還是沒有我滿意的。沒法調(diào)動顯卡算力，單靠 CPU 得壓制到猴年馬月——我這次測試的是 13 分半的視頻，原文件 19.5 GB，此前積累的素材少說有幾個 T 了，就算是電腦 24 小時開機，我什么都不做，也要兩個多月。更別說還要抽查畫質(zhì)、清理文件、干別的事情了。這兩個多月，就算是電費也要花一大筆錢。

我還是決定：手頭有錢了，把電腦主板找人修一下（此前裝硬盤時，用力過猛，螺絲刀直接撞在一塊電容上，把電容撞掉了，于是目前的主板只能識別兩個 SATA 通道），再買塊硬盤裝上吧。

當然，就算你壓制得再好，如果以流媒體方式分享的話，平臺仍然會給你二壓到極致。比如說嗶哩嗶哩，這次使用的視頻發(fā)布時，4K 下壓縮到 8% 的體積，代價是 83% 的幀的 VMAF 值都低于 91。與小丸工具箱的情況不同，視頻質(zhì)量明顯差了一大截。更別說其他分辨率下的情況了。

這十幾天也不算是白費力氣，至少給了大家這篇文章吧。

參考資料

[1]?視頻壓縮畫質(zhì)對比工具VMAF使用記錄 - 少數(shù)派:?https://sspai.com/post/77442
[2]?H.265視頻壓制參數(shù)分享 - 嗶哩嗶哩:?https://www.bilibili.com/read/cv19292062
[3]?【資料匯編】不同視頻編碼器質(zhì)量對比——NVENC、QuickSync、X264和X265 - 知乎:?https://zhuanlan.zhihu.com/p/78829414
[4]?H264內(nèi)容轉(zhuǎn)為H265如何確定最優(yōu)碼率？ - 知乎:?https://www.zhihu.com/question/294488136