大家好，我是波導(dǎo)終結(jié)者。

前陣子在網(wǎng)上逛的時(shí)候，發(fā)現(xiàn)一個(gè)資源，《妖精的尾巴》第一部共175集高清資源，1080P，H265，10bit，F(xiàn)LAC，視頻碼率在4M-5M左右，目測(cè)應(yīng)該是原片直接壓過來的，清晰度基本完美。

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

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

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

經(jīng)過一番查詢與驗(yàn)證，得到以下幾個(gè)信息：

1.hevc_nvenc編碼里的vbr_hq是舊版本的參數(shù)，在新版本里的中高質(zhì)量Preset里已經(jīng)不再支持。

2.H265(hevc)的vbr_hq參數(shù)實(shí)際上核心是2pass編碼，已經(jīng)被-preset slow所包含。

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

按照網(wǎng)上這張表格里的信息，只要寫上-preset slow便是2pass編碼，降一檔到medium就是1pass，事實(shí)真是這樣嗎？我們來親自驗(yàn)證一下。

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

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

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

然而，在整體畫面變動(dòng)劇烈的場(chǎng)景，這個(gè)碼率就扛不住了。露西手臂周圍、火焰的部分都有明顯的色塊。那么，修改參數(shù)能否改善這個(gè)現(xiàn)象呢？

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

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

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

另外，眼尖和經(jīng)?？磩?dòng)畫的朋友應(yīng)該會(huì)有這樣一個(gè)疑問：這片源看起來并不像原生1080P的？是的，我也有這種感覺。不知道是壓制的時(shí)候做過處理，還是更上一層的片源（比如藍(lán)光原盤）就是這樣，但很明顯，最起初繪制時(shí)應(yīng)該是沒有1080P的，估計(jì)是壓制光碟的時(shí)候處理過了吧。

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

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

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

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

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

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

藍(lán)1是壓縮分辨率，如果不壓分辨率，這個(gè)參數(shù)去掉即可。

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

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

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

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

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