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



















master-john
校验提示文案
极客科技侠
校验提示文案
成电sugar
校验提示文案
KC熊朗布
校验提示文案
我们一起捉水母
校验提示文案
手撕鲈鱼
校验提示文案
胡侃侃
校验提示文案
爱折腾的老狐狸
校验提示文案
被演南非
校验提示文案
Geng_Le
校验提示文案
高柳乱蝉
校验提示文案
夜无语
校验提示文案
ilovekingki
校验提示文案
得意试验室
校验提示文案
高岳嘻嘻
校验提示文案
supercoolman
校验提示文案
kom1718
校验提示文案
灵猫客户机
校验提示文案
刺客东
校验提示文案
艾路艾鲁
校验提示文案
刺客东
校验提示文案
灵猫客户机
校验提示文案
kom1718
校验提示文案
supercoolman
校验提示文案
高岳嘻嘻
校验提示文案
得意试验室
校验提示文案
ilovekingki
校验提示文案
夜无语
校验提示文案
高柳乱蝉
校验提示文案
艾路艾鲁
校验提示文案
Geng_Le
校验提示文案
被演南非
校验提示文案
爱折腾的老狐狸
校验提示文案
胡侃侃
校验提示文案
手撕鲈鱼
校验提示文案
我们一起捉水母
校验提示文案
KC熊朗布
校验提示文案
成电sugar
校验提示文案
极客科技侠
校验提示文案
master-john
校验提示文案