音视频原理

像素

1. 定义：像素是图像的基本组成单位，英文pixel由picture（图片）与element（元素）组合而来，简写为px，含义为图像元素。
2. 规格计算：图片尺寸宽×高代表横向、纵向的像素点数，二者相乘为总像素数量；例：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。

定义误区
原文表述「分辨率是指图像的大小或尺寸」表述片面。
✅ 正确定义：
像素尺寸（宽×高像素）只是像素分辨率，分辨率是统称，完整分为两类：

1. 像素分辨率（图片尺寸）：宽×高像素，决定图像总像素量；
2. 物理分辨率（DPI/PPI，像素密度）：单位长度内的像素数量（像素/英寸），代表打印、屏幕的精细度。
   简单说：像素尺寸≠分辨率全称，只能说像素尺寸是像素分辨率的表达方式。

结论逻辑漏洞
原文结论：分辨率越高，图像就越清晰，这句话缺少前提，并不严谨。
✅ 完整正确结论：

1. 观看画面的物理尺寸固定时（比如都在同一块显示器、同一尺寸屏幕观看），分辨率越高、总像素越多，画面细节越清晰；
2. 脱离观看尺寸，该结论不成立：
   举例子：一张1080P的超大户外巨幕画面，和一张720P的手机小屏画面，近距离观看手机720P会更清晰。
   清晰度由分辨率 + 观看距离 + 画面物理尺寸共同决定，并非单纯分辨率越高就一定更清晰。

补充小知识点
日常视频标注的720P、1080P，默认是16:9影视通用比例，是行业约定标准；如果画面比例不是16:9，就不能用垂直像素直接推算水平像素。

位深

帧率

一、基础概念

帧率英文缩写FPS（Frames Per Second），直译：每秒帧数，指1秒钟时间里画面刷新、播放的静态图片数量。
视频本质是连续快速播放的静态画面，人眼会产生视觉暂留效果，把一张张静态图看成流畅的动态画面，帧率就是衡量画面更新速度的核心参数。

二、常见帧率标准与用途

1. 24FPS（电影标准）
   传统院线电影通用帧率，是影视行业经典规格，画面自带柔和的电影质感，符合电影的拍摄叙事风格。
2. 30FPS（流媒体通用）
   国内短视频、网络视频、电视直播主流帧率，画面流畅均衡，兼顾文件体积与观感，日常刷视频、追剧大多是30帧。
3. 60FPS（高流畅帧率）
   画面顺滑度大幅提升，动作、移镜时几乎看不到拖影。多用于游戏、直播、运动赛事、慢动作回放、日常vlog拍摄。
4. 120FPS / 240FPS（超高帧率）
   极致丝滑，多用于手游/端游电竞、高速运动画面，还可以后期做成慢动作视频；需要高性能设备解码、高规格屏幕支持。

三、帧率核心特点

1. 帧率越高，动态画面越顺滑
   帧数越多，画面切换间隔越短，快速移动、打斗、镜头横移时，拖影、卡顿感越少。比如玩射击游戏，60帧远优于30帧，操控跟手度差距明显。
2. 帧率越高，文件体积越大，硬件要求越高
   相同分辨率下，60帧视频的数据量约为30帧的2倍，录制、存储、剪辑、播放都需要更强的CPU、显卡性能，占用存储空间也会翻倍。
3. 帧率和分辨率互不干涉

• 分辨率决定画面静态清晰度（画面细节、画质精细度）
• 帧率决定动态流畅度（画面动起来顺不顺）
  例：1080P 30帧 = 清晰但动态一般；720P 60帧 = 画质稍弱，但动作极其顺滑。

四、补充常识

1. 人眼临界感知：大多数人能明显区分30帧和60帧；普通日常观看，30帧完全够用，高帧率的优势只在高速动态场景体现。
2. 录制/播放匹配原则：录制帧率要和显示器刷新率匹配，比如144Hz电竞屏搭配144帧游戏，才能完整发挥高帧率效果。

码率

1、基础定义
码率（也叫比特率），单位：bps（比特每秒），常用单位换算：
1Mbps(兆比特)=1024Kbps，1KB(字节)=8bit(比特)
含义：单位时间内视频/音频文件传输的数据体量，简单理解：每秒视频占用的数据大小，是决定视频压缩画质、文件大小的核心指标。

2、核心作用

1. 直接决定画质上限
   在分辨率、帧率完全相同的前提下：码率越高，画面画质越好。
   高码率会保留更多画面色彩、细节，画面压缩失真少，色彩更饱满，复杂场景（爆炸、快速运动、繁杂纹理）不容易出现马赛克、色块模糊、锯齿、拖影；
   低码率会强行压缩画面数据，丢失大量细节，画面容易糊、出现色块。

2. 决定文件体积大小
   时长一样、参数一致的视频，码率和文件大小成正比。
   计算公式：
   文件大小 ≈ 码率 × 时长
   例：一段1分钟1080P视频

• 1Mbps码率：文件大约 7.5MB
• 8Mbps码率：文件大约 60MB

3. 影响在线播放流畅度
   在线看视频时，视频的实时码率不能超过你的网速带宽。
   比如视频实时码率4Mbps，你的网速只有3Mbps，就会频繁缓冲、卡顿；网速充足才能完整加载高码率画面。

3、分辨率+帧率 常规参考码率（通用H.264编码）

4、码率 VS 分辨率、帧率（三者区别）

1. 分辨率：管静态画面有多清晰（画面精细度）
2. 帧率：管画面动起来流不流畅（动态顺滑度）
3. 码率：管画质的保存质量，是画质的“承载上限”
   举个直白例子：
   把视频比作自来水水管

• 分辨率=水管口径大小
• 帧率=水流快慢
• 码率=水的纯净度，码率越高，水里杂质越少（画面压缩损耗越少）

5、补充关键知识点

1. 编码会影响码率效率
   新一代编码（H.265/HEVC、AV1）压缩效率更高，同等画质下，H.265只需要H.264一半左右的码率，就能达到相同画质，更省空间、省流量。
2. 恒定码率CBR / 可变码率VBR

• CBR恒定码率：全程码率固定，适合直播、实时推流，网速稳定不易卡顿，但复杂画面容易画质不足。
• VBR可变码率：简单画面自动降码率，画面复杂（打斗、夜景）自动拉高码率，画质利用率更高，本地录制、剪辑首选。

3. 码率不是越高越好
   超出设备/平台上限后，继续拉高码率画质几乎不会提升，只会白白占用存储空间与网速，按需设置即可。

多角度补充说明
分辨率、帧率固定，码率完全可以自由调节，并不是固定死的
先讲最通俗的比喻，再讲原理，很好懂：
比喻类比（一秒看懂）
把视频比作「固定尺寸的蛋糕」

1. 分辨率（宽高像素）= 蛋糕的长宽尺寸（大小固定）
2. 帧率= 1秒内要连续送出多少块蛋糕（每秒数量固定）
3. 码率= 每一块蛋糕，用料的扎实程度
   蛋糕长宽不变、每秒送出的数量不变，你完全可以：

• 用料扎实（奶油、果肉足量）=高码率，口感精致；
• 用料缩水（掺面粉、压缩配料）=低码率，口感粗糙。

对应视频就是：画面尺寸、每秒画面张数没变，但我们可以人为压缩画面数据，让单帧画面的信息变多/变少，这就是码率的本质。

底层原理：视频是经过「压缩算法」处理的，不是原始原图
你以为的画面：每一帧都是完整无损的原图
实际的视频：会用编码算法（H.264/H.265）大幅压缩画面冗余信息
1. 原始无压缩画面（码率固定）
如果每一帧都保存完全没压缩的原始位图，分辨率、帧率定死，总数据量确实是固定值，码率无法改变。
举例1080P 30帧无损原图码率极高，动辄几百Mbps，体积极其庞大，完全没法网络传输、存储，我们日常使用的视频永远不会用无损格式。

2. 成品压缩视频（码率可人为自定义）
日常的MP4视频，会做大量有损压缩：

1. 空间压缩（单帧内）：画面里相近的颜色、相似纹理，可以合并简化。
   比如一片蓝天，高码率会保留细微色彩渐变；低码率直接把整片蓝天合并成单一蓝色，丢掉细节，数据直接变少。
2. 时间压缩（帧与帧之间）：前后画面不动的区域（比如固定镜头的墙壁），不需要重复完整保存，只记录变化的部分。压缩强度可以手动拉满或降低。

简单说：压缩力度，就是我们手动控制码率的开关。

• 压缩力度小 = 保留细节多 = 码率高；
• 压缩力度大 = 大量删减画面细节 = 码率低。

举实际例子（1080P 30帧完全相同规格）

1. 低码率版：码率设为2Mbps，画面快速运动时会出现色块、模糊、马赛克，文件很小；
2. 标准码率版：码率设为6Mbps，画质正常清晰，观感舒适；
3. 高码率版：码率设为12Mbps，色彩、发丝、纹理细节完整，几乎没有压缩痕迹，文件体积成倍变大。

三者分辨率、帧率一模一样，只是压缩程度不同，码率天差地别。

补充三个关键误区

1. 分辨率+帧率，决定码率的「理论上限」，不是固定数值
   画面规格越高，能承载的最高码率上限越高，但最低码率可以压得极低。4K视频可以压成极低码率的模糊画面，720P也可以做成高码率的精致画质。
2. 编码决定压缩效率
   同样1080P 30帧，H.265编码只用一半码率，就能达到H.264编码的画质。编码不同，相同画质对应的码率也不同，进一步说明码率和画面规格没有绑定关系。
3. 码率是画质的天花板
   分辨率和帧率决定了画面的规格上限，而码率决定你能不能完整发挥这个规格的实力。
   就算你是4K高分辨率，如果码率压得极低，画质反而不如高码率的1080P。

示例分析

一、先算：这路画面【完全无压缩】每秒原始数据大小
画面参数：分辨率1921×1080、帧率25fps
安防摄像头原始画面，常用YUV420 8bit（行业标准原始图像格式），我们来计算裸数据码率：

1. 单帧像素总量：$1921 × 1080 ≈ 2074680 像素
2. YUV420 每像素占1.5字节，1字节=8bit
   单帧比特数：2074680 × 1.5 × 8 = 24896160 bit 2074680 × 1.5 × 8 = 24896160\ \text{bit}2074680×1.5×8=24896160bit
3. 每秒25帧总码率：
   24896160 × 25 ≈ 622404000 bit/s ≈ 622.4 Mbps 24896160 × 25 ≈ \boldsymbol{622404000\ \text{bit/s}} ≈ \boldsymbol{622.4\ \text{Mbps}}24896160×25≈622404000bit/s≈622.4Mbps

换算成网速：无压缩原始画面每秒需要约622Mbps的带宽传输。
而现在设置的上限仅2000kbps = 1.95Mbps，和原始622Mbps相差三百多倍。
结论：必须依靠H.264/H.265视频编码做高强度压缩，才能把码率压到2000kbps，不存在不压缩就能传输的可能。

二、针对的2000kbps码率，详细说明

1. 2000kbps就是人为设定的码率上限
   摄像头内部的编码芯片（H.264/H.265）会自动做有损压缩，把原始海量画面数据，压缩控制在每秒最高2000千比特。

   • 静态简单画面（纯色墙面、不动场景）：编码会大幅精简冗余信息，实际瞬时码率会低于2000kbps；
   • 动态复杂画面（画面大量移动、光影变化）：编码自动拉高码率，最高触顶2000kbps上限，此时画面细节会被强制压缩，就容易出现色块、模糊、马赛克（和截图里画面的方块噪点对应）。

2. 截图右上角出现的558kbps，就是当前实时瞬时码率，当前画面内容简单，只用了不到一半的限额。

三、补充

1. 编码格式是压缩的核心
   现在的监控画面都是标准的H.264（AVC）或H.265（HEVC）压缩格式，就是专门用来砍掉画面冗余信息，实现几百倍的压缩率。如果不用压缩编码，以现在的网线、交换机带宽，完全扛不住622Mbps的原始数据流。
2. 码率上限的取舍
   2000kbps对于1080P 25帧监控属于偏低码率：

• 优点：占用带宽小、硬盘录像占用空间少、多摄像头同时预览不容易卡顿；
• 缺点：夜间、运动画面细节压缩严重，容易糊，想要画质更好，可以适当调高码率上限（比如4000kbps）。

Stride（Pitch 行跨度/行字节数）

一、核心定义

1. Stride（别名 Pitch / linesize）
   指图像内存里完整一行占用的总字节数，包含：有效像素字节 + 末尾填充字节(Padding)。
2. 图像原始行字节：图像宽度 × 单像素字节数，只存放真实画面像素。
3. Padding（内存填充）：为满足CPU/GPU内存对齐规则，在每行像素的末尾，额外补上的无用空白字节。
4. 结论：正常情况下 Stride ≥ 原始行字节宽度，存在填充时，Stride 严格大于画面原始宽度字节。

二、底层原理：为什么必须做内存对齐、加Padding？
CPU、内存控制器读取内存时，是按固定块（16/32/64字节）批量读取，而非单个字节读取：

1. 对齐地址读取（地址是对齐值的整数倍）：一次内存指令就能读完一行数据，读取效率极高；
2. 非对齐地址读取：一行数据横跨两个内存块，CPU需要发起两次内存读取，额外做拼接计算，性能大幅下降；极端情况下嵌入式、硬件编解码芯片会直接报错崩溃。

所以图像框架（FFmpeg、OpenCV、DirectX、摄像头SDK）会强制行字节按照固定字节数对齐（常见16、32、64字节对齐），不足的字节用Padding补齐，这就是Stride大于画面宽度的根本原因。

三、用例题完整演算（638×480 RGB24，16字节对齐）
RGB24格式：1个像素占3字节（R/G/B各1字节）

1. 计算原始单行有效字节
   原始行字节 = 宽度 × 3 =638 × 3 = 1914 字节
2. 判断16字节对齐：1914 ÷ 16 = 119.625，无法整除，不满足对齐要求
3. 向上取最近的16的整数倍
   向上取整为1920字节
   需要填充Padding字节：1920 - 1914 = 6字节
4. 最终结果
   本行Stride(linesize) = 1920字节，也就是640 × 3，末尾6个字节为无效填充数据。

四、开发实操核心坑点（代码对错解析）
1. 正确写法（FFmpeg标准读取方式）

// frame->linesize[0] 就是Y通道的Stride（每行完整内存跨度）for(intj=0;j<frame->height;j++){// 每行起始地址 = 首地址 + 当前行数 × 行跨度Stridefwrite(frame->data[0]+j*frame->linesize[0],...);}

逻辑：内存中下一行的起始位置 = 当前行首地址 + Stride，严格按照内存实际排布遍历，会自动跳过末尾的Padding填充字节，只会读取有效像素。

2. 错误写法（高频踩坑）
直接用宽度 × 单像素字节当做行偏移，强行按画面宽度连续读写整块内存：

// 错误！无视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]：

1. Y平面：分辨率和原图宽高完全一致，Stride最大；
2. U/V平面：宽高均为原图的1/2，拥有单独的行跨度，对齐规则和Y平面相互独立；
3. 遍历UV通道时，必须使用linesize[1]、linesize[2]专属的行跨度，绝对不能复用Y通道的Stride。

六、精简总结

1. Stride（Pitch/linesize）= 单行有效像素字节 + 末尾Padding填充字节，是内存中一行完整占用的总长度；
2. Padding的唯一目的：满足硬件内存对齐，提升读写性能、兼容硬件编解码；
3. 图像处理遍历行的核心公式：行首地址 = 首指针 + 行数 × Stride，绝对不能用图像像素宽度代替Stride做内存偏移；
4. 画面分辨率决定有效像素数量，Stride由对齐字节数决定，和画面宽度没有必然相等的关系。