音视频有许多概念,帧率跟码率,是其中两个常见的概念。
读者经常会听到“刷新的帧率是多少”或“码率比较高所以要求网速要比较好”等表达。
本文介绍音视频的帧率与码率的概念。
小程之前还介绍了音视频的其它概念,读者可以关注“广州小程”微信公众号,并在“音视频->基础概念与流程”菜单项中查阅相关的文章。
(1)帧率
帧率,表示的是频率,也就是在一段时间,操作的频度。
帧率的具体含义,需要分两个场景来介绍,一个是采集时的场景,另一个是显示时的场景。
(a)采集时
对于自然界的声音或图像来说,要转换成为计算机里面的物件,采集是必须的。
对于图像的采集,一般以摄像头或屏幕作为输入,按一定的规则拍摄图片或截取图片(小程之前介绍过录制视频,读者可以参考这篇文章)。
这个获取图片的规则中,有一项指标,可以称为“取图速度”。明显,取图越快,就越能把变化的细节捕捉到,但图片的总数量也越多,如果这些图片存放在磁盘或在网络上传输,那存储空间与占用的带宽就是要考虑的因素,而这个跟“取图速度”有关。
“取图速度”,一般用单位时间(比如一秒钟)内取几张图来界定,也就是一秒钟有多少帧,单位为fps,比如“我的这个电影是25fps”,就是1秒内我取了25张图。
小程之前介绍“从视频中提取图片”时,传给ffmepg的参数-r,就是一秒钟拿几张图,也是“取图速度”的概念,但这个是从已有视频中提取,而不是从摄像头或屏幕提取。
(b)显示时
采集到图片,经过编码压缩、存储或传输、解码,最终被展示出来。
展示图片时,也有一些展示的规则,这些规则中有一项指标,可以称为“画图速度”。
“画图速度”,就是一秒画出几张图,单位同样为fps。
同样,在源图片连续的情况下,如果画得越快,理论就越平滑。但是,画得越快,就越费劲,甚至根本就没有能力画得那么快。
到底“画图速度”要多快,要看你的目的与实际能力。一般理想的效果是,既让图片展示得平滑,又让显示组件不太忙。
小白:那么,多少fps,才算是平滑?
小程:得看内容变化的情况,如果不经常运动的,那15fps都可能够用了;如果运动剧烈的,那就要画得更快一些,比如30fps、60fps或更高。当然,前提是,采集到的是平滑的。
画得太慢或画得太快,会导致什么问题?这个跟代码逻辑有关。一般来说,对于视频,有声音跟图像,那就要考虑声画同步的问题,其中一个实现逻辑,可以用声音为主,图像落后于声音的pts就渲染图片,否则就等待,如果按这样的逻辑,那么,画得太慢就会出现图像跟不上声音的问题,画得太快则问题不大(只是多一些判断的执行)。如果是其它处理逻辑,则要具体问题具体分析。
总的来说,采集时的“取图速度”以及显示时的“画图速度”,就叫帧率。
一般来说,如果说一个视频的帧率,那指得是采集时的帧率。
小白:我可以这一秒15fps,一下秒就变成30fps吗?
小程:这个叫动态帧率(vfr),不在这里展开了。
接下来,小程演示一下如何改变视频的帧率。
这里用FFmpeg来改变视频的帧率。对于FFmpg的安装与使用,读者可以参考小程之前介绍的文章。
帧率更改前,是这样的:
使用ffmepg命令来修改帧率,更改为1fps(类似于采集,1秒钟拿一张图):
ffmpeg -i moments.mp4 -y -r 1 moments_1fps.mp4
帧率更改后,是这样的:
然后,这两个不同的采集帧率(左边1fps,右边25fps),对应的视频的效果是这样的:
(2)码率
码率也叫比特率,是在编码压缩时使用的概念。音视频数据,最终用二制数(bit)来表示,1秒钟的数据量,就是码率。单位为bps,或者kbps,比如“我用128kbps来编码mp3文件”。
1秒钟的比特量越多,能表达的细节就越多(比如声音的高频段信息等),占用的磁盘空间越大,如果传输则占用的带宽也越大。
这里演示一下,用ffmepg命令来更改码率。
码率更改前,是这样的:
用ffmpeg命令修改码率:
ffmpeg -i moments.mp4 -y -b:v 50K -b:a 0K moments_50k_br.mp4
码率更改后,是这样的:
两个不同码率(左50kbps,右388kbps),对应视频的播放效果是这样的:
可以看到,左边的非常模糊,甚至出现了马赛克,因为码率太小,压缩得太严重了。
最后,说一下文件大小与码率的关系。
文件大小 = 码率 * 时长。这个适用于固定码率的情况,码率为总的码率(音频+视频+其它)。一般可以根据这个公式,推算出音视频的时长。
同样,可以用ffmpeg命令来修改文件大小(从头截取一段):
ffmpeg -i moments.mp4 -y -fs 100K moments_fs_100k.mp4
总结一下,本文介绍了帧率与码率的概念。帧率,一般反映了采集时采集的速度;码率,是编码时的概念,反映了单位时间内用多少bit去描述音频或视频数据。
原文地址:http://blog.51cto.com/13136504/2106787