版面规则
提问时请注意:尽量详细描述操作过程、AVS脚本内容等,最好能写出片名,只贴图有时无法看出问题原因。
提示:发布原创内容请尽量使用附件上传。使用网盘会出现过期失效的问题,请注意。
头像
猫耳幽香
帖子: 22
注册时间: 2014-12-22 12:24

浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

近期刚好在做doc中文化和莳乃字幕屋的教程编写工作,所以就把教程中提到的这块索性就丢上来了,因为还没正式翻译FPS这块,所以并未包含完整翻译(也就是因为教程需求才进行的翻译),有错误敬请指出。
本文中的翻译部分遵循CC-BY-SA 3.0发布。

(……前略)
现在继续看第二个案例:
LwlibavVideoSource(“1.mp4”,threads=1)
Spline36Resize(1280,720)
AssumeFPS(“ntsc_film”)

AssumeFPS (http://avisynth.nl/index.php/AssumeFPS)是时间轴编辑滤镜中的一种,用于重定义帧率(不对帧序列内容做改变,只对帧间隔时间做修正),下表为AssumeFPS中自带的帧率表:
图片

这些帧率中,在番剧/动画中常见的帧率有:23.976、29.97、59.94、24、30、60(30、60并未列出)。
一般来说,AVSP的右下角就有这样的帧率:
图片
为什么是这么奇怪的帧率,不是30、不是24,而是什么29.970、23.976呢?英文wiki是这样说的:

* When a transmitter broadcasts an NTSC signal, it amplitude-modulates a radio-frequency carrier with the NTSC signal just described, while it frequency-modulates a carrier 4.5 MHz higher with the audio signal. If non-linear distortion happens to the broadcast signal, the 3.579545 MHz color carrier may beat with the sound carrier to produce a dot pattern on the screen. To make the resulting pattern less noticeable, designers adjusted the original 60 Hz field rate down by a factor of 1.001 (0.1%), to approximately 59.94 fields per second. This adjustment ensures that the sums and differences of the sound carrier and the color subcarrier and their multiples (i.e., the intermodulation products of the two carriers) are not exact multiples of the frame rate, which is the necessary condition for the dots to remain stationary on the screen, making them most noticeable.
* 当发射机广播NTSC信号时,它以调幅的方式将上文提到的NTSC信号调制进无线电波中,但它调制的调频波频率要比声音信号高4.5MHz。如果广播信号受到了非线性干扰,3.579545MHz的颜色载波就会与音频载波产生差频(拍频),在屏幕上生成点状图案。为了让产生的图案不那么明显,设计师将原来60赫兹的场频调低了0.1%,大约每秒59.94Hz。这样调整可以保证音频和颜色载波的和或差不是帧率的整数倍,因此斑点也不会停留在同一位置,也就更难被注意到。(Translated by Kilo19 & Beining, using CC-BY-SA 3.0.)

看不懂没关系。你只要知道这是历史原因就行了。
同时,这里还会引出一个概念叫timebase(时间坐标),也就是上表中的denominator(分母),你大可理解为单位。比如:在一个一维的坐标中,每格的单位为1,那么此时的base是1。这里只是将1换成了1.001,在引入到视频的背景下,出现了timebase这么一个词。
图片
你问为什么这里是1.001而不是1001?比如是24/1.001=23.976024而不是24000/1001=23.976024?
就是2种写法而已,其实本质都一样。

说了这么多,为啥字幕菌需要知道这个。是因为Horriblesub这个坑货。
Horriblesub是一个自己付费购买webdl源的英语字幕组,字幕有时内挂有时内嵌(如:《死亡游行》就是内嵌字幕)。在下面的拖肉教程中,我会介绍不同源的优劣。在这里,我们先下结论:使用webdl的Horriblesub源是最好的源,一般是最优先选择,所以一般能选Horrible的源时,就算它有点小问题还是要处理的。
总而言之先看下面的截图吧:
图片
注意到右下角没?Horrible坑就坑在这里:帧率错误。
前面提到过标准帧率有:23.976、29.970……他们是根据24000/1001=23.976024和30000/1001=29.97003(详见上文表格)得出的。
于是这里明显就不对头了——出来的帧率不是标准帧率。发生的原因是:不同容器的timebase的精准度和基准是不同的。(其中,这里的基准你可以理解为坐标原点。)而Horriblesub在做容器转换工作时,并未顾及到这一点,进而出错。
其实关于源滤镜挂载这块,mp4理论上应该使用lwlibav挂载更好,实际上之所以用FFVS是因为这是我最初学压制的时候喜欢用的源滤镜,而这个视频也是我最初学压制时拿到的示例。不过真用lwlvs挂载的话:
图片
这帧率更夸张了。当然,这并不是Lwlvs的锅,在源滤镜挂载这块用法照旧即可。

当我们看见这种错误的时候,就要使用AssumeFPS进行帧率的重定义工作了,用法示例:
LwlibavVideosource("[HorribleSubs] Sword Art Online II - 08 [1080p].mkv",threads=1)
AssumeFPS("ntsc_film")
此时帧率恢复了正常。
图片或许有心人会知道,AssumeFPS()里面是能填数字的,比如:AssumeFPS(30),但这里为什么不能用?
前面提到过timebase的问题,这里的timebase明显是1.001,24/1.001=23.976024,我们通常意义上所说的23.976,只是一种简称罢了。实际上位数可不只是23.976这点数字,后面可跟着一串呢。
比如:23.97600000000001和23.97600000000000,你看上去就差那么0.00000000000001,但是它们就是2个帧率,差一点也是2个帧率,是不兼容的。
所以我们一般情况下,都是调用预置的字串来定义视频的帧率,如AssumeFPS(“ntsc_film”)。具体都有哪些字串是预置的,详见上文中《AssumeFPS中自带的帧率表》。

你问我修正了有啥意义?如果遇到一个屏幕字多的字幕的话,你用一个异常的帧率做字幕,出来的屏幕字字幕和实际的帧位置是对不上的(虽然对非屏幕字是没有影响的,因为那个是按照音频进行计时制作,但屏幕字可是对帧而不是对音频啊,而且就是没有屏幕字这也是习惯问题),拿给压制的人后,压制的人一看:字幕怎么都偏的?平移还不解事!?要调轴不蛋疼死。

还需要再强调的是,尽管上文已经提到过:AssumeFPS只是表面上重定义了帧率,此处也是因为Horriblesub在做容器转换的时候没能正确处理导致的帧率错误,实际帧率根据过往的压制经验,一般不会出现23.976以外的情况,所以敢这样重定义回正确的帧率。但是如果你是想实际意义上更变帧率, 比如你想把一个120fps的视频转换成60fps,AssumeFPS是无法做到的,示例中的例子是需要调用SelectEvery (http://avisynth.nl/index.php/SelectEvery)+AssumeFPS滤镜,或者直接调用ChangeFPS滤镜来进行操作的。当然实际上根据需求的不同调用的滤镜也不同,此处就不再展开描述了。

同时还需要注一下ChangeFPS (http://avisynth.nl/index.php/ChangeFPS#ChangeFPS)这滤镜,它确实也改变了帧率,但是它不是单纯意义上的“仅重定义帧率”,而是通过删除或重复(duplicating)帧来维持指定帧率,其中在high fps -> low fps的时候,ChangeFPS会做删除帧处理,即ChangeFPS会优先检查是否有相同帧,若有则将这些帧删除(delete)。(但若没有重复帧那么情况将变得不确定)。像这种只是由于timebase导致的问题不应该使用ChangeFPS。但是如果要做low -> high FPS处理时,ChangeFPS则是会将理论上原本空的地方freeze成相同帧。


还有一个滤镜叫ConvertFPS (http://avisynth.nl/index.php/ConvertFPS#ConvertFPS),这滤镜尽管不会做任何的重复和删除帧工作,但是:

* The filter attempts to convert the frame rate of clip to new_rate without dropping or inserting frames, providing a smooth conversion with results similar to those of standalone converter boxes. The output will have (almost) the same duration as clip, but the number of frames will change proportional to the ratio of target and source frame rates.
* 这个滤镜尝试将片段的帧率转换到(新的帧率),但是不增加或删除帧,以期提供与单独转换器类似的平滑转换体验。滤镜的输出将同源视频(几乎)相同,但是其帧数会与源视频和目标视频的帧率之比成正比。(Translated by Beining, using CC-BY-SA 3.0.)
* ConvertFPS doesn`t drop or insert frames.It instead either blends multiple frames into one (to decrease fps) or "switches" one frame into two by literally breaking it into parts. Blend obviously results in motion blurring, and switch introduces wobble during pans.(From URL (http://forum.videohelp.com/threads/1801 ... -changeFPS))
* ConvertFPS不删除或插入帧。ConvertFPS将多个帧混入(Blend)一个帧(以减少帧率)或者将一个帧“拆分”(Switch)成两个帧。很明显,Blend模式会造成画面模糊,Switch在动作场景会加大摇晃程度。(Translated by Beining, using CC-BY-SA 3.0.)

打个比方说:如果你使用ConvertFPS这滤镜,副作用不能避免:就像从颈部截肢,人会不可避免地出现死亡。同样地,使用SVP会不能避免地破坏原画面一样。
SVP是什么?本技术文档中不做解释。

离题
其实,我之所以在FPS这块解释那么多,是因为我永生难忘有个人,他在和我论学习这个的必要性时(当时他开始大幅度反驳我的时候就是我在解释FPS的时候),居然和我提到了这样一个因果结论:
因为nnedi3_resize16()是世上最好的缩放滤镜,所以我们打轴的时候应该用这个滤镜挂载视频。所以你干嘛要教我们用Spline来缩放?这不是误导人吗?

看完这句话我就懵了。

给看不懂这句话错在哪里的人的一个比喻:
因为Linux是世界上最好的系统,所以学习用Windows就是误导人。
你让我用Wine玩游戏么?

还有一句:当时我提到Aegisub是使用FFmpegsource调用视频的,结果他回复道:
人家是利用ffms2_FFVideoSource这滤镜调用视频的,它是基于ffms2.dll的。

我再一次懵了。

我凭良心说话,像mawen1250这样的高手根本不知道,现在压制的学习环境实际上有多么糟糕。半吊子的屡见不穷——摆太多论据尝试说服别人的自恋倾向:我掌握了一切,所以一定要说服别人,又或者:我不阻止你加入ISIS,但是你敢炸我你试试。
以为我为啥要主持doc中文化工作?如果只是英文不会也就算了,问题是:环境真TM糟糕。
上次由 猫耳幽香 在 2015-06-17 11:34,总共编辑 6 次。
mawen1250的签名档里有好多教程 | 带2+5.1ch声道ts的处理方法 | AssumeFPS、ChangeFPS、ConvertFPS的区别 | 关于音频抽出却延迟不同的一些疑问(未解决)
一些常用的文档和工具:(大多收录非记载在nmm论坛的内容)
H.264Level计算器 | x264参数介绍(中文翻译可以戳这里,但是不全) | x265参数介绍 | BillyTC下载链接修复
► 显示剧情透露 致那些“我看不懂”的人
► 显示剧情透露 我不懂为啥有人说HEVC慢Orz
► 显示剧情透露 鸠子的愤怒:我不明白
► 显示剧情透露 芳乃琴里樱这名字太长了,叫我琴乃多好。
头像
猫耳幽香
帖子: 22
注册时间: 2014-12-22 12:24

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

好吧,我好像放错版块了,希望管理员帮我移到Avisynth那个版块去。
mawen1250的签名档里有好多教程 | 带2+5.1ch声道ts的处理方法 | AssumeFPS、ChangeFPS、ConvertFPS的区别 | 关于音频抽出却延迟不同的一些疑问(未解决)
一些常用的文档和工具:(大多收录非记载在nmm论坛的内容)
H.264Level计算器 | x264参数介绍(中文翻译可以戳这里,但是不全) | x265参数介绍 | BillyTC下载链接修复
► 显示剧情透露 致那些“我看不懂”的人
► 显示剧情透露 我不懂为啥有人说HEVC慢Orz
► 显示剧情透露 鸠子的愤怒:我不明白
► 显示剧情透露 芳乃琴里樱这名字太长了,叫我琴乃多好。
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

简单补充几点:
1. AssumeFPS除了指定一个float值、指定一个string,还支持指定两个int分别作为numerator和denominator,也就是直接AssumeFPS(24000, 1001)、AssumeFPS(30000, 1001),一般我更习惯这样做。
2. mkv的帧率问题,实质上是由于它(容器本身)的timebase不精确导致的(并且也与muxer有关,比如mkvmerge比Haali的精度低1个数量级),直接AssumeFPS的前提是你能确保源是cfr的。相对的,在源的情况不确定的情况下,鲁棒性更高的做法(但也更麻烦)是抽出timecode,然后用taro的tctool这类工具修复,再在压制时用--tcfile-in输入x264(因为x264的rate control是和局部帧率关联的,所以更建议在这一步就输入)。
3. 源滤镜的问题,mp4不建议用ffms2或LWLibav,容易出问题(后者可能相对好一点)。mp4用L-SMASH作为demuxer和muxer是最靠谱的,在AVS里也就是LSMASHVideoSource,在VS里就是lsmas.LSMASHSource。
4. 关于LWLibavVideoSource帧率相关的一些其他问题,它默认情况下是会ignore soft pulldown的flag的。像是很多DVD源和某些ts源都是包含了soft pulldown的。在这种情况下,如果全程都是24p的话,读出来就是24000/1001fps,这种自然最方便,完全不需要再去考虑IVTC的问题。但还有一种情况(在MPEG-2的ts会很常见),它(内部编码的)是24p和30i的混合,这时候ignore flag你会得到一个介于23.976和29.970之间的fps,因为lsmas并没有提供输出timecode的功能,所以就完全没法正确处理了。这时候就需要设置repeat=True来强制honor flag,得到30000/1001的视频,再去根据情况做IVTC/deint。
5. 对于MPEG-2的源,最好还是用DGIndex/d2vsource,因为TIVTC支持输入d2v,会参考soft pulldown flag的信息来做IVTC,这样准确性就有保证了。
fch1993
帖子: 213
注册时间: 2012-06-12 11:56

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

mawen1250 写了:简单补充几点:
1. AssumeFPS除了指定一个float值、指定一个string,还支持指定两个int分别作为numerator和denominator,也就是直接AssumeFPS(24000, 1001)、AssumeFPS(30000, 1001),一般我更习惯这样做。
2. mkv的帧率问题,实质上是由于它(容器本身)的timebase不精确导致的(并且也与muxer有关,比如mkvmerge比Haali的精度低1个数量级),直接AssumeFPS的前提是你能确保源是cfr的。相对的,在源的情况不确定的情况下,鲁棒性更高的做法(但也更麻烦)是抽出timecode,然后用taro的tctool这类工具修复,再在压制时用--tcfile-in输入x264(因为x264的rate control是和局部帧率关联的,所以更建议在这一步就输入)。
3. 源滤镜的问题,mp4不建议用ffms2或LWLibav,容易出问题(后者可能相对好一点)。mp4用L-SMASH作为demuxer和muxer是最靠谱的,在AVS里也就是LSMASHVideoSource,在VS里就是lsmas.LSMASHSource。
4. 关于LWLibavVideoSource帧率相关的一些其他问题,它默认情况下是会ignore soft pulldown的flag的。像是很多DVD源和某些ts源都是包含了soft pulldown的。在这种情况下,如果全程都是24p的话,读出来就是24000/1001fps,这种自然最方便,完全不需要再去考虑IVTC的问题。但还有一种情况(在MPEG-2的ts会很常见),它(内部编码的)是24p和30i的混合,这时候ignore flag你会得到一个介于23.976和29.970之间的fps,因为lsmas并没有提供输出timecode的功能,所以就完全没法正确处理了。这时候就需要设置repeat=True来强制honor flag,得到30000/1001的视频,再去根据情况做IVTC/deint。
5. 对于MPEG-2的源,最好还是用DGIndex/d2vsource,因为TIVTC支持输入d2v,会参考soft pulldown flag的信息来做IVTC,这样准确性就有保证了。
1.貌似TIVTC不支持DGdecNV/DGdecIM等源的导入。

2.目前hevc编码的TS似乎只有LWLibavVideoSource一个能搞定,ffms目前因为没人更新10bit hack版了,只能输出8bit。
fch1993
帖子: 213
注册时间: 2012-06-12 11:56

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

其实,我之所以在FPS这块解释那么多,是因为我永生难忘有个人,他在和我论学习这个的必要性时(当时他开始大幅度反驳我的时候就是我在解释FPS的时候),居然和我提到了这样一个因果结论:
因为nnedi3_resize16()是世上最好的缩放滤镜,所以我们打轴的时候应该用这个滤镜挂载视频。所以你干嘛要教我们用Spline来缩放?这不是误导人吗?

看完这句话我就懵了。

给看不懂这句话错在哪里的人的一个比喻:
因为Linux是世界上最好的系统,所以学习用Windows就是误导人。
你让我用Wine玩游戏么?

还有一句:当时我提到Aegisub是使用FFmpegsource调用视频的,结果他回复道:
人家是利用ffms2_FFVideoSource这滤镜调用视频的,它是基于ffms2.dll的。

我再一次懵了。

我凭良心说话,像mawen1250这样的高手根本不知道,现在压制的学习环境实际上有多么糟糕。半吊子的屡见不穷——摆太多论据尝试说服别人的自恋倾向:我掌握了一切,所以一定要说服别人,又或者:我不阻止你加入ISIS,但是你敢炸我你试试。
以为我为啥要主持doc中文化工作?如果只是英文不会也就算了,问题是:环境真TM糟糕。

嘛嘛,反正尝试说服别人的东西我也干过。

我最常说的一句话就是:x265和x264的差距就像星际1和星际2,很多东西看似类似实际上使用起来完全不同。请在使用x265的时候不要把x264的理解带上去,尤其是那些参数名称一致的不要想当然认为设置同样的数值就有同样的效果。目前x265是很不user friendly的,参数设置稍稍不合理就会面临压缩率不如同码率x264的问题。(当然这里是针对x264 10bit转x265 10bit的某些人说的)
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

fch1993 写了:
mawen1250 写了:简单补充几点:
1. AssumeFPS除了指定一个float值、指定一个string,还支持指定两个int分别作为numerator和denominator,也就是直接AssumeFPS(24000, 1001)、AssumeFPS(30000, 1001),一般我更习惯这样做。
2. mkv的帧率问题,实质上是由于它(容器本身)的timebase不精确导致的(并且也与muxer有关,比如mkvmerge比Haali的精度低1个数量级),直接AssumeFPS的前提是你能确保源是cfr的。相对的,在源的情况不确定的情况下,鲁棒性更高的做法(但也更麻烦)是抽出timecode,然后用taro的tctool这类工具修复,再在压制时用--tcfile-in输入x264(因为x264的rate control是和局部帧率关联的,所以更建议在这一步就输入)。
3. 源滤镜的问题,mp4不建议用ffms2或LWLibav,容易出问题(后者可能相对好一点)。mp4用L-SMASH作为demuxer和muxer是最靠谱的,在AVS里也就是LSMASHVideoSource,在VS里就是lsmas.LSMASHSource。
4. 关于LWLibavVideoSource帧率相关的一些其他问题,它默认情况下是会ignore soft pulldown的flag的。像是很多DVD源和某些ts源都是包含了soft pulldown的。在这种情况下,如果全程都是24p的话,读出来就是24000/1001fps,这种自然最方便,完全不需要再去考虑IVTC的问题。但还有一种情况(在MPEG-2的ts会很常见),它(内部编码的)是24p和30i的混合,这时候ignore flag你会得到一个介于23.976和29.970之间的fps,因为lsmas并没有提供输出timecode的功能,所以就完全没法正确处理了。这时候就需要设置repeat=True来强制honor flag,得到30000/1001的视频,再去根据情况做IVTC/deint。
5. 对于MPEG-2的源,最好还是用DGIndex/d2vsource,因为TIVTC支持输入d2v,会参考soft pulldown flag的信息来做IVTC,这样准确性就有保证了。
1.貌似TIVTC不支持DGdecNV/DGdecIM等源的导入。

2.目前hevc编码的TS似乎只有LWLibavVideoSource一个能搞定,ffms目前因为没人更新10bit hack版了,只能输出8bit。
1. d2v就是专门对付MPEG-2的,然而目前我还没见过非MPEG-2源有soft pulldown的,而dgi有没有包含soft pulldown flag的信息都是未知数。
2. 你需要VapourSynth。
fch1993
帖子: 213
注册时间: 2012-06-12 11:56

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

说起来如何实现字幕的FPS转换?

我遇到有一个片源,早期放流的R版是MPEG2编码的24FPS BD,然后实际零售版是23.976FPS,而网上几乎所有的字幕都是24fps的。怎样才能将字幕做出时间轴的转换。
sherry22422
帖子: 1
注册时间: 2012-06-01 1:16

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

遇到过四次LSMASH花屏LWLibav正确的视频后我就对LSMASH不报期望了。现在的MP4并不是都合乎标准,用LWLibav做索引依旧是最安全的做法。
头像
feisty2
帖子: 274
注册时间: 2012-08-05 10:03

Re: 浅谈AssumeFPS、ChangeFPS、ConvertFPS的区别

changefps非常有用 怎么会"不允许使用" 当非整数提高帧率时 损失最小的办法一定要用changefps 比如24变30 用changefps制造的重复帧一是非常好压缩 基本不占体积 (时域上没有dif 简直就是me/mc的最最最理想状态) 而且以后可以去掉还原 反观convertfps 制造出各种可怕的鬼影 增大了压缩难度 而且后期不可逆 (至少有限精度下无法逆转) 至于用mc提高帧率 最好只有整数提高时使用 比如30变120 整数提高不影响已有帧 后期也是可逆 如果是大倍数非整数提高 最好mc+changefps 比如30到130 先mc整数到120 120changefps成130 这样的话 也是可逆的

回到 “AviSynth”