TA的每日心情 | 无聊 2023-3-18 18:33 |
---|
签到天数: 3 天 [LV.2]偶尔看看I
星辰大海
- 积分
- 406057
|
本帖最后由 Lambholl 于 2023-12-28 21:21 编辑
就我们 LPSub 的制作而言,在某个时间点注意到了这个问题之后,就开始将对话轴的起止位置贴紧关键帧位置。
由于我们从一开始,打轴的时候便贴紧对话,在全部对话轴完成之后,使用 Aegisub 的「时间后续处理器」进行延长。
这是两次延长的操作:
如此处理完,就没有闪轴了,但是就会有如楼主所说的问题。
因此我们开始选择用 x264/x265 重新压一遍片源,以便在场景切换时插入关键帧,其中发现 x265 对于这个需求来说更加准确(而且 HEVC 版本是要在制作完成之后发布的,因此我们的流程变成了在出稿之前先压一份 HEVC 版本,顺便可以打轴用)
而延长的操作就变成了这样:
这里需要说明一下,为什么 250ms 的延长改成了 150ms 呢?是为了防止和贴紧关键帧冲突。当然其实要用 250 也是可以的,只是打轴的时候多加注意一些就行了,这一点需要理解这几个数字的工作逻辑后灵活变化了。
我知道这套数字肯定不是最优解,而且也知道优化空间可能在哪,不过贸然改动可能会让效果变得更差,而且改动这里的数字必然要配合打轴习惯的改变,因此暂时就不改了,各位可以按实际情况修改。
处理前:
这里需要稍微注意一点,就是为了吸附关键帧,倘若说话结束的频谱正好在关键帧上,或者像下图一样,稍稍超出了关键帧一点,这时我们选择将轴的结束时间稍微提前一点,打在关键帧以内的位置,以便后处理的吸附。
处理后:
效果还是挺不错的。
但是受限于 x265 压制版本需要发布,keyint 毕竟是不能太大,再加上编码器的 IDR 帧是按照开销计算的,并不是真正的画面变换位置,因此也不是很准确。
再后来,我拿到了 MIR 佬的一份脚本,用来计算画面动态,计算出场景变换的帧编号,发现这个结果比起 x264/x265 等编码器来说,生成的关键帧位置对于打轴来说最准确。
(大佬应该不介意我发出来吧)
脚本是基于 VapourSynth 的,把 bat 里面的 vspipe 位置替换掉即可。生成完成的是一个 txt 文件,可以用 Aegisub 视频=>打开关键帧。
对于我们组来说,因为我们压制所使用的思路是单脚本输出多个视频,因此使用这个脚本生成关键帧文件,可以将 HEVC 版本的压制延后到轴完后和 AVC 两个版本一起压制,省去一次视频预处理的算力(毕竟我们的 WebRip 脚本里面常年都有 bm3d,省去一次预处理还是能省下不少电的)
如果想参考一下,之前我有录过打轴的视频传B站:BV19H4y1y7Aw,不过是在没用上生成脚本的时候,也不是自家的稿子
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|