视频帧率的故事与一些细节

Adapt what is useful, reject what is useless, and add what is specifically your own. --- Bruce Lee

视频帧率这个部分,虽然表面上蛮简单基础的,但是其实深挖起来,也够写大半本书的。我们还是秉承着温故知新的逻辑,从眼前的一些东西整理一下,也可能会有一些你不曾想到或深入的点。

帧率的含义

视频是由连续运动的图像播放而来的,不知道当时第一次把电影活灵活现的播放出来的时候,是不是现场看到过电影的人们一定是张大了嘴,瞪大了眼睛,世界也从此不同了。以下的这个1887年拍摄的最早期的视频为例,它是由15张300x200的图像组成,在1.5秒播放完成的。仔细看每张图的左下角,每一张都标注了它的图像号:

我们可以看到组成这个视频的所有画面。

每秒钟视频要播放的图片数,这个值即被定义为帧率,单位为fps(frames per second)。它不只在视频技术中被应用,也在动画、游戏、相机、显示设备等所有采集和显示有关的地方应用着。比如上面的视频,它的帧率为:

Video_Frame_Rate = 15 / 1.5 = 10fps

帧率标准

在电影电视发展早期,每个国家使用的帧率制式是有区别的,一个比较典型的设定是:

• 24fps(电影、ATSC、2k、4k、6k)

• 25fps(PAL(主要用在中国、欧洲、乌拉圭、阿根廷、澳大利亚等)、SECAM(中东、法国、东欧等)、DVB、ATSC)

• 29.97fps(NTSC(美洲、日本、韩国、东南亚等),ATSC、PAL-M(巴西))

• 30fps(ATSC)

造成这个局面的原因主要因为在黑白电视时代,各国家电网的不同,比如美国电力系统频率为60Hz(传输30fps信号),而中国、欧洲电力系统频率为50Hz(传输25fps信号),所以各国电视信号都按各国自己传输网络的情况进行了设定。彩色电视被发明之后,为了兼容黑白信号并防止出现显示异常,所以做了信号微调,把帧率调整到NTSC制式,即30/1.001 = 29.970。

但具体是如何将30fps的内容控制在29.970呢?这就不能不提一下timecode的概念。

timecode

早年间在拍电影的时候,因为有多个机位,多个摄像机采集的信号如何很难保证精准的对齐时间戳。这样在做后期的时候非常困难。timecode是在1967年由一家叫EECO的从事视频摄像机和视频后期视频的公司发明的,后来SMPTE采纳了这个概念,并将它标准化。它的格式非常直白:

这样不同内容间同步的问题被完美的解决掉了。而且你可以使用timecode定位到一个准确的视频帧。

这里需要明确一个点,因为每秒里的帧数有可能不确定,所以不能完全用timecode去推断帧率(而且两者概念不一样,timecode主要为了定位视频帧的,帧率主要是为了给录制和播放两侧图像显示速度的)。

29.97如何而来

这个问题的定义是我们如何在后期制作的环节获得29.97fps的内容,以保证完全的帧同步。

如果从内容生产端解决这个问题,可能会是个噩梦。因为不同种类的摄像机拍摄,设置不同,回来的内容就不可控,到了后期通过其他手段进行帧率填充成本极高(尤其在老式的视频编辑设备上)。所以这条路径被封死了。

于是大家想到了timecode,发明了Drop-Frame Timecode的方法。

具体的流程是这样的,如果你采集的信源是30fps,但是制作需要29.97fps,那么在每个10分钟区间里,除了第一分钟外,每分钟的前两个timecode的帧都被丢弃掉(即.00, .01两个帧)。这样的话,10分钟内的视频帧一共有:

TotalFrames = 10 x 60 x 30 - 9 x 2 = 17982 frames

所以最后的帧率为

OutputFrameRate = 17982 / (10 x 60) = 29.97 fps

这是个非常物理的设计,信源其实没有任何变化,但是输出却自动适配了。一方面跟原来30fps的黑白信号频率岔开了,另一方面帧率尽可能接近30fps,并达到了一个准确的值。这样的设计在那个半自动化半机械的年代里,有很多案例,由于当时的客观技术与平台因素制约,最终解决方案都给人一种工程美感。

这个事情在数字化之后,其实一来没有那么多制式的限制了,二来数字化时代,所有的采样灵活度更高,帧率设定大部分情况下,只是一个参数设置,软件可以做的事情越来越多,但了解历史会让人更清楚它的来龙去脉。

帧率多高算够

这个问题真没有特别明确的答案。

我们都知道物理上有个实验结果,大脑反应图像的速度接近于0.1秒每张。这个说明,人眼每秒可以处理10张到12张图片,并可以独立的识别与认知它们。如果一秒里包含了更多图像,它们将被认知为运动。而如果显示设备的显示频率较低的话,人眼会感觉到明显的闪烁,并随着暴露时间的变长产生严重的疲劳感。久而久之,将罹患比较严重的眼部疾病,或是严重的近视。

一般显示设备的亮度越高,人眼感觉不到闪烁需要的帧率越高,反之,越低。我们用电影银幕为例,无闪烁感要求关系如下:

所以显示器的刷新率一般至少都在50Hz以上。另外电影院因为屏幕亮度高,对于帧率的要求就更高,诺兰之类的大导演经常会要求120Hz的片源,会让人观看体验提升非常明显(越专业的人看到的提升越明显)。另外高帧率看惯了,低帧率就再也回不去了。

夜里关灯看手机也真的是影响眼睛,屏幕亮度高,近距离看,屏幕刷新率固定的,一定会有屏幕闪烁的感觉,一定会视疲劳,非常容易加深眼睛伤害。

目前看现在应用级别的视频,上限帧率应该是120Hz,特殊场景,如医学、微观世界研究,可能会需要更高的帧率,它们也不是像我们看电影这样快速的看,会放慢动作,看得更精细。所以回到我们的判断,没有明确的答案,只有应用场景的要求。

帧率是否有其他的研究点

Video Framerate Up Conversion

视频帧率提高(Video Framerate Up Conversion或Video Frame Interpolation等),是非常典型的一个研究点,这几年还在继续有一些新的技术产出。

一般做这个事情是出于两个目的:

• 在不改变信源的情况下,将原有视频内容以更高帧率展示,观感更平滑(加强运动感知),用在播放器上,提升观看体验

• 在不改变信源的情况下,将原有视频的帧数变多,以相对低的帧率进行展示,实现慢动作、慢镜头效果(Slomo),用在特效制作上,提出某些特效。

有一个比较老的项目,在帧率拉升上做的真的不错,叫SVPFlow[1]。它是运行在AviSynth上的一个效果插件,底层用到另外一个视频运动分析工具MVTools2[2],在绝大部分视频源上跑下来的结果都非常平滑(本身MVTools2这个插件也非常棒,在帧间运动分析上效果还是不错的,对于一些CV算法有帮助的)。

当然另外就是通过CNN等这些AI算法去进行更高级别的运动分析,然后生成新的视频帧。如2017年发表在CVPR上的Video Frame Interpolation via Adaptive Convolution[3],就是这样一个算法。这个算法作者也提供了开源的实现,有兴趣也可以到github项目页[4]去下载测试。

每个视频的算法,都有机会使用AI技术进行加强(当年参加ICME发文章的讲论文的时候,也是这么说,跟一个美国教授在探讨这个事情,他极不认可这个说法,这么多年过去了,各新的压缩标准已经把AI逐渐用在各个地方了,也算是给当年的一个判断的了断吧)。

Video Framerate Down Conversion

与提升视频帧率作用相反,大量的非编和后期软件现在都提供了这个功能,虽然它不能给人愉悦感,但是在某些场合下,是可以实现一些特效的,比如香港80年代鬼片里,经常会用到这种效果,然后再配个阴森的音乐,来给人一种害怕的感觉。案例效果太晦气,就不放在文章里了,大家有兴趣可以自行寻找。

写在最后

当我们沿着这个行业里最基础的这些部分一点点整理过去的时候,很多时候会发现过去的技术人跟现在的技术人关注点真的有比较大的差异了,有好多原来非常复杂的问题,现在变简单了或是更夸张,变没了。但是解决问题的思路没有变,解决问题的时候人的智慧给人带来的愉悦感没有变。

我有一本2008年从北航的一个二手书店里购买的《影视技术概论》,应该是当时某个专业里的教材,现在也只有二手书还有可能能买到了。当时购买人叫伊能,他买于2006年9月30日。书里还留着他的签名,以及他学习里详细的笔记,也不知道15年过去了,他在哪,现在怎么样。虽然里面的技术好多现在只用在电影制作里,但是里面的信息都扎根好深,说得好透。所以有时候真的感慨,技术发展那么快,基础技术是否受到关注度太低了。我们还是继续守好初心,在五年计划里,把能整理的一点点整理出来,也许会使有些人受益吧。

 

References

[1] SVPFlow: http://avisynth.nl/index.php/SVPFlow
[2] MVTools2: http://avisynth.nl/index.php/MVTools
[3] Video Frame Interpolation via Adaptive Convolution: https://arxiv.org/abs/1703.07514
[4] github项目页: https://github.com/sniklaus/sepconv-slomo

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Jiheng_Yang

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值