本文中的翻译部分遵循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糟糕。
因为nnedi3_resize16()是世上最好的缩放滤镜,所以我们打轴的时候应该用这个滤镜挂载视频。所以你干嘛要教我们用Spline来缩放?这不是误导人吗?
看完这句话我就懵了。
给看不懂这句话错在哪里的人的一个比喻:
因为Linux是世界上最好的系统,所以学习用Windows就是误导人。
你让我用Wine玩游戏么?
还有一句:当时我提到Aegisub是使用FFmpegsource调用视频的,结果他回复道:
人家是利用ffms2_FFVideoSource这滤镜调用视频的,它是基于ffms2.dll的。
我再一次懵了。
我凭良心说话,像mawen1250这样的高手根本不知道,现在压制的学习环境实际上有多么糟糕。半吊子的屡见不穷——摆太多论据尝试说服别人的自恋倾向:我掌握了一切,所以一定要说服别人,又或者:我不阻止你加入ISIS,但是你敢炸我你试试。
以为我为啥要主持doc中文化工作?如果只是英文不会也就算了,问题是:环境真TM糟糕。