大家好，我是波導終結者。
前陣子在網上逛的時候，發現一個資源，《妖精的尾巴》第一部共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編碼，已經被-preset slow所包含。
3.H265的2pass又跟H264的2pass不太一樣，H264的2pass是整遍過完再過一遍，而H265里所謂的2pass是類似於預讀一段用作參考。雖然有看到老外在最新版的x265中調試兩遍分開的命令，但是權衡之下我還是選擇了hevc_nvenc顯卡編碼帶來的速度提升。畢竟170多集不是開玩笑的……
按照網上這張表格里的信息，只要寫上-preset slow便是2pass編碼，降一檔到medium就是1pass，事實真是這樣嗎？我們來親自驗證一下。
如上圖，上面是-preset slow參數，下面是medium參數，可以看到速度確實慢了一半（5倍vs10倍）。鑑於網上公認以及我實測的信息，目前認為hevc_nvenc顯卡編碼-preset 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的手動指定等，但其實這些大部分都已經包含在preset裡面了，不再闡述，也請不懂裝懂的不要在我面前秀，今天分享的是人人可用且易懂的方案，並不是壓縮比絕對最高或者畫質絕對最佳的方案。
壓制效果帶字幕截圖如上。字幕由於是文本方式壓進MKV（非覆寫畫面硬字幕），暫不考慮字體效果問題。
至此，這次的壓制差不多就這樣了，最終得到的效果是1/3左右的容量占用，除了激烈打鬥鏡頭有點色塊外，其他基本完美。原來144G的源壓至1/3左右的話，就是可以省下差不多100G的空間，也不小了。
當然，這樣的方案並不是理論上最高壓縮比的，而是權衡時間、容量、解析度、觀感等因素，得到的一個最佳的通用方案。隨著FFmpeg的更新，也可能有更佳的方案，這個就到時候再討論了。
感謝大家觀看，如果對你有用，不妨點個讚關注一下吧。也歡迎大家評論區交流。我們下期再見。