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