大家好，根據我是實際收藏波導終結者。

前陣子在網上逛的需求時候，發現一個資源，次壓《妖精的制自尾巴》第一部共175集高清資源，1080P，動畫H265，根據10bit，實際收藏FLAC，需求視頻碼率在4M-5M左右，次壓目測應該是制自原片直接壓過來的，清晰度基本完美。動畫

在一些畫面動得非常厲害的打斗場景，片源仍然能保證沒有肉眼可見的需求模糊或者方塊，然而代價是偏大的容量占用。只算動畫本體的話（種子內還有原聲CD、片頭片尾、小劇場等其他資源），175集占用144G的容量，實在有點吃不消。

于是，我的二壓計劃開始了。首先，對于動畫片來說，700-800K碼率的FLAC是真的奢侈，這個是肯定要壓縮掉的。而視頻碼率的壓縮，主要還是看最終的效果，由于源是H265 10bit壓制，二壓的時候不能低于這個規格，否則會造成碼率浪費，與壓制的目的：減少體積，相矛盾。

基于此，我先寫了一段代碼，用hevc_nvenc也即顯卡編碼，目前H265顯卡會比CPU軟壓快。而為了保證畫面質量，又使用了-rc vbr_hq這個參數來提升一下預期的畫面質量，得到如上的報錯信息。

經過一番查詢與驗證，得到以下幾個信息：

1.hevc_nvenc編碼里的vbr_hq是舊版本的參數，在新版本里的中高質量Preset里已經不再支持。

2.H265(hevc)的vbr_hq參數實際上核心是2pass編碼，已經被-pset slow所包含。

3.H265的2pass又跟H264的2pass不太一樣，H264的2pass是整遍過完再過一遍，而H265里所謂的2pass是類似于預讀一段用作參考。雖然有看到老外在最新版的x265中調試兩遍分開的命令，但是權衡之下我還是選擇了hevc_nvenc顯卡編碼帶來的速度提升。畢竟170多集不是開玩笑的……

按照網上這張表格里的信息，只要寫上-pset slow便是2pass編碼，降一檔到medium就是1pass，事實真是這樣嗎？我們來親自驗證一下。

如上圖，上面是-pset slow參數，下面是medium參數，可以看到速度確實慢了一半（5倍vs10倍）。鑒于網上公認以及我實測的信息，目前認為hevc_nvenc顯卡編碼-pset slow質量不差（相當于x264 2pass），速度較快，是目前需求下的最佳方案。x265軟壓當然效果更好，但是耗時太長。

基于這些信息，第一版的代碼如下。-pixfmt p010le是指定顏色格式10bit，與指定Main10同效。雖然對于動畫來說，顏色并不復雜，但是為了避免轉換帶來的損失，還是以與片源相同的10bit為準。平均碼率1.5M，最大碼率2M，音頻AAC128K就足夠了。

壓縮完之后，第1集由860M壓縮到251M，效果還是不錯的。在非打斗場面，即使畫面有一些快速變動（圖上炸開的碎木屑），仍然能保持相當不錯的畫面質量，暫停也看不見色塊。

然而，在整體畫面變動劇烈的場景，這個碼率就扛不住了。露西手臂周圍、火焰的部分都有明顯的色塊。那么，修改參數能否改善這個現象呢？

我測試了一下平均碼率1M，最高碼率4M，與平均碼率1.5M，最高碼率4M，以及平均碼率1M，最高碼率6M的情況，得到如上兩張圖。圖1是1M+4M的情況，比1.5M+2M要來得好一些，而且文件大小由251M縮減到了208M，而1M+6M得到的結果與1M+4M幾乎完全一樣，說明已經觸及變碼率算法的上限。

圖2是1.5M+4M的結果，色塊和糊邊進一步減少，雖然達不到片源的幾乎無損，但已經達到了暫停找碴也可以接受的程度了。然而平均碼率的提高帶來的就是文件的增大，這個參數下文件有296M，大是大了點，好歹仍然壓掉了一半以上的內容，可以接受。

如果要求不高的朋友，已經可以選擇1M+4M，或者1.5M+4M來批量壓制成片。這里壓完，我看了一下文件信息，發現有點喜感。不知道是FFmpeg的BUG還是咋的，視頻和音頻屬性里，一部分參數還是源文件的（寫著視頻4171K，音頻743K），只有在全局里顯示的Overall bit rate:1694 kb/s才是準確的，不影響播放，我就不折騰了。另外，源文件里的菜單（章節分段）在MKV to MKV直轉的時候，是會被默認保留的，這個好評。

另外，眼尖和經?？磩赢嫷呐笥褢摃羞@樣一個疑問：這片源看起來并不像原生1080P的？是的，我也有這種感覺。不知道是壓制的時候做過處理，還是更上一層的片源（比如藍光原盤）就是這樣，但很明顯，最起初繪制時應該是沒有1080P的，估計是壓制光碟的時候處理過了吧。

所以這里我也試了一下壓縮分辨率的情況，圖1是壓到1280x720的效果，仍然是1.5M+4M，基本接近片源，不在乎非要1080P的可以這么壓。

圖2是壓到960x540的效果，參數是1M+4M，由934M壓至203M，效果也還行了。事實上，由于壓到540P是縮小一半，整數倍的算法效果更好，對容量很在意，又想保持效果的不妨試試。當然理論上慢慢調參數可以得到更好的壓縮比，只是大部分朋友沒那個精力和時間慢慢折騰。

然而，分辨率壓縮大法也并非沒有缺點。由于畫面分辨率的壓縮需要計算，而且這部分是顯卡加速不了的，于是可以得到上圖：不改變分辨率的時候，CPU解碼，顯卡編碼吃滿。而改變分辨率后，CPU全滿，顯卡沒滿，會影響一點速度。當然，這里也是由于我現在這臺電腦CPU還不夠強制，如果換上更強勁的U，雙滿就是更完美的方案了。

看到這里，肯定有小伙伴想問了：你這片源是不是無字幕的呀？字幕呢？別急，馬上來。字幕壓制進MKV是小事情，所以放到最后，先把核心問題攻下來再考慮它。首先，我們下載回來的字幕是上圖如左的文件名，通過批量改名工具改成與MKV文件同樣的文件名會比較好操作點，批量更改文件名我之前和大家分享過，不再重復，有疑問可以留言。

將所有視頻源文件、字幕文件放到同一個文件夾下，并運行上圖的腳本，剩下的就是等了。簡單的講一下這個腳本，有其他需求的可以自行更改。

紅1是導入2個文件，一個是MKV，一個是ASS字幕，~ni表示不含后綴的文件名，不要問我為什么，微軟的Bat語法就是這樣。

藍1是壓縮分辨率，如果不壓分辨率，這個參數去掉即可。

紅2是指定MKV的視頻、音頻，以及字幕文件作為輸入。-map 0:0，前面的0表示輸入的順序，從0開始，后面的0表示第幾軌，也是從0開始。

藍2是碼率指定，平均碼率和最大碼率。我知道有朋友想說其他參數，比如qp或者crf，level等，甚至I幀B幀P幀和GOP的手動指定等，但其實這些大部分都已經包含在pset里面了，不再闡述，也請不懂裝懂的不要在我面前秀，今天分享的是人人可用且易懂的方案，并不是壓縮比絕對最高或者畫質絕對最佳的方案。

壓制效果帶字幕截圖如上。字幕由于是文本方式壓進MKV（非覆寫畫面硬字幕），暫不考慮字體效果問題。

至此，這次的壓制差不多就這樣了，最終得到的效果是1/3左右的容量占用，除了激烈打斗鏡頭有點色塊外，其他基本完美。原來144G的源壓至1/3左右的話，就是可以省下差不多100G的空間，也不小了。

當然，這樣的方案并不是理論上最高壓縮比的，而是權衡時間、容量、分辨率、觀感等因素，得到的一個最佳的通用方案。隨著FFmpeg的更新，也可能有更佳的方案，這個就到時候再討論了。

感謝大家觀看，如果對你有用，不妨點個贊關注一下吧。也歡迎大家評論區交流。我們下期再見。