文章目录




像素
- 定义:像素是图像的基本组成单位,英文pixel由picture(图片)与element(元素)组合而来,简写为px,含义为图像元素。
- 规格计算:图片尺寸宽×高代表横向、纵向的像素点数,二者相乘为总像素数量;例:2500×2000的图片,总像素为500万,俗称500万像素照片。
分辨率

分辨率基础定义
分辨率用来描述图像/视频的尺寸大小,以横向像素 × 纵向像素 的形式表示,宽高数值分别对应画面水平、垂直方向的像素点数量。
主流标准规格(16:9通用宽高比):360P(640×360)、720P(1280×720)、1080P(1920×1080)、4K(3840×2160)、8K(7680×4320)。
P规格命名规则
720P、1080P里的数字,代表画面垂直方向的像素总数,结合16:9比例可以反向算出水平像素数;
- 720P:总像素约92万
- 1080P:总像素约207万,像素总量约为720P的2倍多
核心结论:同等尺寸观看下,总像素数量越多,分辨率越高,画面清晰度越高,因此1080P清晰度优于720P。
定义误区
原文表述「分辨率是指图像的大小或尺寸」表述片面。
✅ 正确定义:
像素尺寸(宽×高像素)只是像素分辨率,分辨率是统称,完整分为两类:
- 像素分辨率(图片尺寸):宽×高像素,决定图像总像素量;
- 物理分辨率(DPI/PPI,像素密度) :单位长度内的像素数量(像素/英寸),代表打印、屏幕的精细度。
简单说:像素尺寸≠分辨率全称,只能说像素尺寸是像素分辨率的表达方式。
结论逻辑漏洞
原文结论:分辨率越高,图像就越清晰 ,这句话缺少前提,并不严谨。
✅ 完整正确结论:
- 观看画面的物理尺寸固定时(比如都在同一块显示器、同一尺寸屏幕观看),分辨率越高、总像素越多,画面细节越清晰;
- 脱离观看尺寸,该结论不成立:
举例子:一张1080P的超大户外巨幕画面,和一张720P的手机小屏画面,近距离观看手机720P会更清晰。
清晰度由分辨率 + 观看距离 + 画面物理尺寸共同决定,并非单纯分辨率越高就一定更清晰。
补充小知识点
日常视频标注的720P、1080P,默认是16:9影视通用比例,是行业约定标准;如果画面比例不是16:9,就不能用垂直像素直接推算水平像素。
位深

帧率
一、基础概念
帧率英文缩写 FPS(Frames Per Second) ,直译:每秒帧数 ,指1秒钟时间里画面刷新、播放的静态图片数量。
视频本质是连续快速播放的静态画面,人眼会产生视觉暂留效果,把一张张静态图看成流畅的动态画面,帧率就是衡量画面更新速度的核心参数。
二、常见帧率标准与用途
- 24FPS(电影标准)
传统院线电影通用帧率,是影视行业经典规格,画面自带柔和的电影质感,符合电影的拍摄叙事风格。 - 30FPS(流媒体通用)
国内短视频、网络视频、电视直播主流帧率,画面流畅均衡,兼顾文件体积与观感,日常刷视频、追剧大多是30帧。 - 60FPS(高流畅帧率)
画面顺滑度大幅提升,动作、移镜时几乎看不到拖影。多用于游戏、直播、运动赛事、慢动作回放、日常vlog拍摄。 - 120FPS / 240FPS(超高帧率)
极致丝滑,多用于手游/端游电竞、高速运动画面,还可以后期做成慢动作视频;需要高性能设备解码、高规格屏幕支持。
三、帧率核心特点
- 帧率越高,动态画面越顺滑
帧数越多,画面切换间隔越短,快速移动、打斗、镜头横移时,拖影、卡顿感越少。比如玩射击游戏,60帧远优于30帧,操控跟手度差距明显。 - 帧率越高,文件体积越大,硬件要求越高
相同分辨率下,60帧视频的数据量约为30帧的2倍,录制、存储、剪辑、播放都需要更强的CPU、显卡性能,占用存储空间也会翻倍。 - 帧率和分辨率互不干涉
- 分辨率决定画面静态清晰度(画面细节、画质精细度)
- 帧率决定动态流畅度 (画面动起来顺不顺)
例:1080P 30帧 = 清晰但动态一般;720P 60帧 = 画质稍弱,但动作极其顺滑。
四、补充常识
- 人眼临界感知:大多数人能明显区分30帧和60帧;普通日常观看,30帧完全够用,高帧率的优势只在高速动态场景体现。
- 录制/播放匹配原则:录制帧率要和显示器刷新率匹配,比如144Hz电竞屏搭配144帧游戏,才能完整发挥高帧率效果。
码率
1、基础定义
码率(也叫比特率 ),单位:bps(比特每秒) ,常用单位换算:
1Mbps(兆比特)=1024Kbps,1KB(字节)=8bit(比特)
含义:单位时间内视频/音频文件传输的数据体量 ,简单理解:每秒视频占用的数据大小,是决定视频压缩画质、文件大小的核心指标。
2、核心作用
-
直接决定画质上限
在分辨率、帧率完全相同 的前提下:码率越高,画面画质越好 。
高码率会保留更多画面色彩、细节,画面压缩失真少,色彩更饱满,复杂场景(爆炸、快速运动、繁杂纹理)不容易出现马赛克、色块模糊、锯齿、拖影 ;
低码率会强行压缩画面数据,丢失大量细节,画面容易糊、出现色块。
-
决定文件体积大小
时长一样、参数一致的视频,码率和文件大小成正比 。
计算公式:
文件大小 ≈ 码率 × 时长
例:一段1分钟1080P视频
- 1Mbps码率:文件大约 7.5MB
- 8Mbps码率:文件大约 60MB
- 影响在线播放流畅度
在线看视频时,视频的实时码率不能超过你的网速带宽 。
比如视频实时码率4Mbps,你的网速只有3Mbps,就会频繁缓冲、卡顿;网速充足才能完整加载高码率画面。
3、分辨率+帧率 常规参考码率(通用H.264编码)
| 规格 | 日常流畅码率 | 高清优质码率 |
|---|---|---|
| 720P 30帧 | 1.5~3Mbps | 4~6Mbps |
| 1080P 30帧 | 3~6Mbps | 8~12Mbps |
| 1080P 60帧 | 6~10Mbps | 12~18Mbps |
| 4K 30帧 | 15~25Mbps | 30Mbps以上 |
4、码率 VS 分辨率、帧率(三者区别)
- 分辨率:管静态画面有多清晰(画面精细度)
- 帧率:管画面动起来流不流畅(动态顺滑度)
- 码率 :管画质的保存质量 ,是画质的"承载上限"
举个直白例子:
把视频比作自来水水管
- 分辨率=水管口径大小
- 帧率=水流快慢
- 码率=水的纯净度,码率越高,水里杂质越少(画面压缩损耗越少)
5、补充关键知识点
- 编码会影响码率效率
新一代编码(H.265/HEVC、AV1)压缩效率更高,同等画质下,H.265只需要H.264一半左右的码率,就能达到相同画质,更省空间、省流量。 - 恒定码率CBR / 可变码率VBR
- CBR恒定码率:全程码率固定,适合直播、实时推流,网速稳定不易卡顿,但复杂画面容易画质不足。
- VBR可变码率:简单画面自动降码率,画面复杂(打斗、夜景)自动拉高码率,画质利用率更高,本地录制、剪辑首选。
- 码率不是越高越好
超出设备/平台上限后,继续拉高码率画质几乎不会提升,只会白白占用存储空间与网速,按需设置即可。
多角度补充说明
分辨率、帧率固定,码率完全可以自由调节,并不是固定死的
先讲最通俗的比喻,再讲原理,很好懂:
比喻类比(一秒看懂)
把视频比作「固定尺寸的蛋糕」
- 分辨率(宽高像素) = 蛋糕的长宽尺寸(大小固定)
- 帧率 = 1秒内要连续送出多少块蛋糕(每秒数量固定)
- 码率 = 每一块蛋糕,用料的扎实程度
蛋糕长宽不变、每秒送出的数量不变,你完全可以:
- 用料扎实(奶油、果肉足量)= 高码率,口感精致;
- 用料缩水(掺面粉、压缩配料)= 低码率,口感粗糙。
对应视频就是:画面尺寸、每秒画面张数没变,但我们可以人为压缩画面数据,让单帧画面的信息变多/变少,这就是码率的本质。
底层原理:视频是经过「压缩算法」处理的,不是原始原图
你以为的画面:每一帧都是完整无损的原图
实际的视频:会用编码算法(H.264/H.265)大幅压缩画面冗余信息
1. 原始无压缩画面(码率固定)
如果每一帧都保存完全没压缩的原始位图,分辨率、帧率定死,总数据量确实是固定值,码率无法改变。
举例1080P 30帧无损原图码率极高,动辄几百Mbps,体积极其庞大,完全没法网络传输、存储,我们日常使用的视频永远不会用无损格式。
2. 成品压缩视频(码率可人为自定义)
日常的MP4视频,会做大量有损压缩:
- 空间压缩(单帧内) :画面里相近的颜色、相似纹理,可以合并简化。
比如一片蓝天,高码率会保留细微色彩渐变;低码率直接把整片蓝天合并成单一蓝色,丢掉细节,数据直接变少。 - 时间压缩(帧与帧之间):前后画面不动的区域(比如固定镜头的墙壁),不需要重复完整保存,只记录变化的部分。压缩强度可以手动拉满或降低。
简单说:压缩力度,就是我们手动控制码率的开关。
- 压缩力度小 = 保留细节多 = 码率高;
- 压缩力度大 = 大量删减画面细节 = 码率低。
举实际例子(1080P 30帧完全相同规格)
- 低码率版:码率设为
2Mbps,画面快速运动时会出现色块、模糊、马赛克,文件很小; - 标准码率版:码率设为
6Mbps,画质正常清晰,观感舒适; - 高码率版:码率设为
12Mbps,色彩、发丝、纹理细节完整,几乎没有压缩痕迹,文件体积成倍变大。
三者分辨率、帧率一模一样,只是压缩程度不同,码率天差地别。
补充三个关键误区
- 分辨率+帧率,决定码率的「理论上限」,不是固定数值
画面规格越高,能承载的最高码率上限越高,但最低码率可以压得极低。4K视频可以压成极低码率的模糊画面,720P也可以做成高码率的精致画质。 - 编码决定压缩效率
同样1080P 30帧,H.265编码只用一半码率,就能达到H.264编码的画质。编码不同,相同画质对应的码率也不同,进一步说明码率和画面规格没有绑定关系。 - 码率是画质的天花板
分辨率和帧率决定了画面的规格上限 ,而码率决定你能不能完整发挥这个规格的实力。
就算你是4K高分辨率,如果码率压得极低,画质反而不如高码率的1080P。
示例分析

一、先算:这路画面【完全无压缩】每秒原始数据大小
画面参数:分辨率 1921×1080、帧率25fps
安防摄像头原始画面,常用 YUV420 8bit(行业标准原始图像格式),我们来计算裸数据码率:
- 单帧像素总量:$1921 × 1080 ≈ 2074680 像素
- YUV420 每像素占1.5字节,1字节=8bit
单帧比特数: 2074680 × 1.5 × 8 = 24896160 bit 2074680 × 1.5 × 8 = 24896160\ \text{bit} 2074680×1.5×8=24896160 bit - 每秒25帧总码率:
24896160 × 25 ≈ 622404000 bit/s ≈ 622.4 Mbps 24896160 × 25 ≈ \boldsymbol{622404000\ \text{bit/s}} ≈ \boldsymbol{622.4\ \text{Mbps}} 24896160×25≈622404000 bit/s≈622.4 Mbps
换算成网速:无压缩原始画面每秒需要约622Mbps的带宽传输 。
而现在设置的上限仅 2000kbps = 1.95Mbps ,和原始622Mbps相差三百多倍。
结论:必须依靠H.264/H.265视频编码做高强度压缩,才能把码率压到2000kbps,不存在不压缩就能传输的可能。
二、针对的2000kbps码率,详细说明
-
2000kbps就是人为设定的码率上限
摄像头内部的编码芯片(H.264/H.265)会自动做有损压缩,把原始海量画面数据,压缩控制在每秒最高2000千比特。
- 静态简单画面(纯色墙面、不动场景):编码会大幅精简冗余信息,实际瞬时码率会低于2000kbps;
- 动态复杂画面(画面大量移动、光影变化):编码自动拉高码率,最高触顶2000kbps上限,此时画面细节会被强制压缩,就容易出现色块、模糊、马赛克(和截图里画面的方块噪点对应)。
-
截图右上角出现的
558kbps,就是当前实时瞬时码率,当前画面内容简单,只用了不到一半的限额。
三、补充
- 编码格式是压缩的核心
现在的监控画面都是标准的H.264(AVC)或H.265(HEVC) 压缩格式,就是专门用来砍掉画面冗余信息,实现几百倍的压缩率。如果不用压缩编码,以现在的网线、交换机带宽,完全扛不住622Mbps的原始数据流。 - 码率上限的取舍
2000kbps对于1080P 25帧监控属于偏低码率:
- 优点:占用带宽小、硬盘录像占用空间少、多摄像头同时预览不容易卡顿;
- 缺点:夜间、运动画面细节压缩严重,容易糊,想要画质更好,可以适当调高码率上限(比如4000kbps)。
Stride(Pitch 行跨度/行字节数)
一、核心定义
- Stride(别名 Pitch / linesize)
指图像内存里完整一行占用的总字节数 ,包含:有效像素字节 + 末尾填充字节(Padding)。 - 图像原始行字节:
图像宽度 × 单像素字节数,只存放真实画面像素。 - Padding(内存填充):为满足CPU/GPU内存对齐规则,在每行像素的末尾,额外补上的无用空白字节。
- 结论:正常情况下 Stride ≥ 原始行字节宽度,存在填充时,Stride 严格大于画面原始宽度字节。
二、底层原理:为什么必须做内存对齐、加Padding?
CPU、内存控制器读取内存时,是按固定块(16/32/64字节)批量读取,而非单个字节读取:
- 对齐地址读取(地址是对齐值的整数倍):一次内存指令就能读完一行数据,读取效率极高;
- 非对齐地址读取:一行数据横跨两个内存块,CPU需要发起两次内存读取,额外做拼接计算,性能大幅下降;极端情况下嵌入式、硬件编解码芯片会直接报错崩溃。
所以图像框架(FFmpeg、OpenCV、DirectX、摄像头SDK)会强制行字节按照固定字节数对齐(常见16、32、64字节对齐),不足的字节用Padding补齐,这就是Stride大于画面宽度的根本原因。
三、用例题完整演算(638×480 RGB24,16字节对齐)
RGB24格式:1个像素占3字节(R/G/B各1字节)
- 计算原始单行有效字节
原始行字节 = 宽度 × 3 =638 × 3 = 1914 字节 - 判断16字节对齐:1914 ÷ 16 = 119.625,无法整除,不满足对齐要求
- 向上取最近的16的整数倍
向上取整为 1920字节
需要填充Padding字节:1920 - 1914 = 6字节 - 最终结果
本行Stride(linesize) = 1920字节,也就是640 × 3,末尾6个字节为无效填充数据。
四、开发实操核心坑点(代码对错解析)
1. 正确写法(FFmpeg标准读取方式)
c
// frame->linesize[0] 就是Y通道的Stride(每行完整内存跨度)
for(int j=0; j<frame->height; j++)
{
// 每行起始地址 = 首地址 + 当前行数 × 行跨度Stride
fwrite(frame->data[0] + j * frame->linesize[0], ...);
}
逻辑:内存中下一行的起始位置 = 当前行首地址 + Stride,严格按照内存实际排布遍历,会自动跳过末尾的Padding填充字节,只会读取有效像素。
2. 错误写法(高频踩坑)
直接用 宽度 × 单像素字节 当做行偏移,强行按画面宽度连续读写整块内存:
c
// 错误!无视Padding填充字节
fwrite(frame->data[0], 1, frame->width * frame->height, outfile);
问题:
内存里每行末尾都有Padding空字节,你按「纯有效像素宽度」连续读取时,会把下一行开头的像素,误读进上一行末尾的填充区域,最终导出的图片画面错位、花屏、颜色错乱。
五、拓展:YUV格式的Stride特点(FFmpeg帧最常用)
YUV420P分为 Y、U、V三个独立平面 ,三个通道拥有各自独立的linesize[0]/linesize[1]/linesize[2]:
- Y平面:分辨率和原图宽高完全一致,Stride最大;
- U/V平面:宽高均为原图的1/2,拥有单独的行跨度,对齐规则和Y平面相互独立;
- 遍历UV通道时,必须使用
linesize[1]、linesize[2]专属的行跨度,绝对不能复用Y通道的Stride。
六、精简总结
- Stride(Pitch/linesize)= 单行有效像素字节 + 末尾Padding填充字节,是内存中一行完整占用的总长度;
- Padding的唯一目的:满足硬件内存对齐,提升读写性能、兼容硬件编解码;
- 图像处理遍历行的核心公式:
行首地址 = 首指针 + 行数 × Stride,绝对不能用图像像素宽度代替Stride做内存偏移; - 画面分辨率决定有效像素数量,Stride由对齐字节数决定,和画面宽度没有必然相等的关系。