大家好，我是波导终结者。
前阵子在网上逛的时候，发现一个资源，《妖精的尾巴》第一部共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的更新，也可能有更佳的方案，这个就到时候再讨论了。
感谢大家观看，如果对你有用，不妨点个赞关注一下吧。也欢迎大家评论区交流。我们下期再见。
