图像质量与分辨率帧率码率之间的关系
简单准确介绍视频/图像领域的分辨率、帧率、码率之间的关系。<!--more-->
Drivers of Quality 传输质量
视频传输质量由分辨率与帧率决定。
- Resulution: 分辨率是指一帧图像有多少条水平扫描线,如1080p。分辨率越大,图像越清晰。单位是数量。
- FPS(Frame Per Second): 帧率是指视频流一秒钟时间内包含多少帧图像。帧率越大,视频的动画越流畅。单位是赫兹(Hz)。
Bitrate 码率
要传输的视频,在确定了分辨率与帧率之后,编码器还需要确定码率,码率是指每秒传输多少位,单位是 bits/s
。
我们举一个实际例子计算一下码率:
- 分辨率为
1080p(1920*1080)
- 帧率为
60FPS
通过分辨率与帧率,可以计算出 像素/秒: 1920*1080*60=124416000 pixs/s
。 彩色图像每个像素由RGB三种基色组成,每种基色取值范围是0~255
,那么一个像素对应3个Byte,24bits。 由此可以计算出 码率: 124416000 pixs/s = 124416000*24 bits/s = 2985984000 bits/s ~= 2847Mb/s
。
理论上2847Mbps这个值就是我们要看分辨率为 1080p,帧率为 60FPS的视频,所需要的带宽。但我们发现这个值与实际经验并不相符。这个值接近3Gbps带宽,我们通过手机4G网络或家庭的100Mbps带宽都可以流畅观看1080p视频。这里就涉及到视频传输的压缩。
Compression 压缩
视频压缩的原理是去除冗余信息,在视频数据中冗余信息分为四种:
- 时间上的冗余信息(temporal redundancy):在视频数据中,相邻的帧(frame)与帧之间通常有很强的关连性,这样的关连性即为时间上的冗余信息。
- 空间上的冗余信息(spatial redundancy):在同一张帧之中,相邻的像素之间通常有很强的关连性,这样的关连性即为空间上的冗余信息。
- 统计上的冗余信息(statistical redundancy):统计上的冗余信息指的是欲编码的符号(symbol)的几率分布是不均匀(non-uniform)的。
- 感知上的冗余信息(perceptual redundancy):感知上的冗余信息是指在人在观看视频时,人眼无法察觉的信息。
当前视频领域的编解码算法都包含了压缩,常用的编解码算法有 H264, H265, VP9, AV1。
举个例子,在H264算法中,使用时间冗余原理,将传输的视频帧分为 I-frames, P-frames。
- I-frames: I 帧是图像的完整数据,数据量较大
- P-frames: P 帧是基于I帧的变化数据,数据量较小,如果视频内容变化不大,那么P帧的内容会很小,压缩效果也就很好。
下图是一个I帧与P帧图像。
- I 帧:
- P 帧:
压缩指标 BPP
BPP(Bits per Pix) 是编码器的一个压缩指标,通过 BPP 可以计算出实际的带宽。以 H264 编码算法为例,假设固定 BPP 为 0.21 ,那么上面 1080P@60FPS
的视频,压缩之后需要的带宽为原始带宽的: 0.21/24
倍。
2985984000*0.21/24 ~= 25Mbps
需要注意的是,BPP的值并不是固定的,而是可以动态调整的,空旷的图像要比精致的图像值要小。
Reference
Making fine prints in your digital darkroom Pixels, images, and files
How does bitrate differ for the same resolution and framerate?
更多云最佳实践 https://best.practices.cloud

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MySQL 到 ClickHouse 的高速公路
作者 | TCeason 青云科技数据库研发工程师 2000 年至今,MySQL[1] 一直是全球最受欢迎的 OLTP(联机事务处理)数据库,ClickHouse[2] 则是近年来受到高度关注的 OLAP(联机分析处理)数据库。那么二者之间是否会碰撞出什么火花呢? 本文将带领大家打破异构数据库壁垒,将 MySQL 数据同步至 ClickHouse。对QingCloud MySQL Plus[3] 平台与 MaterializeMySQL[4] 引擎进行了详细介绍,并进一步简述了 HTAP 应用场景。 背景 1、MySQL 复制的发展历程 <center>图 1-1 MySQL 复制的发展历程</center> 图1-1详细罗列了 MySQL 复制的发展历程。 2001 年的 MySQL 3.23 版本就已经支持了同构数据库异步复制;由于是异步复制,根本无法在实际生产中大批量使用。 2013 年 MySQL 5.7.2 版本支持增强半同步复制能力,才勉强算得上是企业级可用的数据同步方案。 2016 年 MySQL 5.7.17 支持了 MGR,并不断地发展成熟,变...
- 下一篇
前端性能优化实践 | 百度APP个人主页优化
性能是每个前端工程师都应该关注的话题,通用的优化手段已有许多文章和实践,就不再赘述,本篇以百度 App 个人主页为例,聊聊针对业务特点进行的一些性能优化实践。适用于:传统意义的优化手段能用的都用了:打包拆包,缩减体积和 HTTP 请求数、CDN 和按需加载等,但性能方面仍不太理想。 01 优化三部曲 下面介绍下我们的优化三部曲,这也是所有优化项目的基本步骤: 现状摸底 发现问题 解决问题 第一步:定义指标,建设报表 优秀方案的制定首先需要准确的数据做支撑。 一般来说,前端性能指标包括DOM ready、First Contentful Paint、白屏、首屏、用户可操作时间、onload 时间等,在实际中需要结合业务本身的特点进行定义,一般通用的指标定义并不能体现用户在当前业务下的真实体验。 个人主页是在百度 App 客户端内的 web 页面,有 hybrid 版(使用 file 协议直接加载本地 HTML 和 JS、CSS)和 web 版(打开一个 web URL)两种不同的打开方式。 首先,我们了解一下个人主页页面的结构: 头部区域展示当前作者的个人信息,tab 区域则是作者创作产...
相关文章
文章评论
共有0条评论来说两句吧...