音视频原理

文章目录



像素

  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
  1. 影响在线播放流畅度
    在线看视频时,视频的实时码率不能超过你的网速带宽
    比如视频实时码率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 分辨率、帧率(三者区别)

  1. 分辨率:管静态画面有多清晰(画面精细度)
  2. 帧率:管画面动起来流不流畅(动态顺滑度)
  3. 码率 :管画质的保存质量 ,是画质的"承载上限"
    举个直白例子:
    把视频比作自来水水管
  • 分辨率=水管口径大小
  • 帧率=水流快慢
  • 码率=水的纯净度,码率越高,水里杂质越少(画面压缩损耗越少)

5、补充关键知识点

  1. 编码会影响码率效率
    新一代编码(H.265/HEVC、AV1)压缩效率更高,同等画质下,H.265只需要H.264一半左右的码率,就能达到相同画质,更省空间、省流量。
  2. 恒定码率CBR / 可变码率VBR
  • CBR恒定码率:全程码率固定,适合直播、实时推流,网速稳定不易卡顿,但复杂画面容易画质不足。
  • VBR可变码率:简单画面自动降码率,画面复杂(打斗、夜景)自动拉高码率,画质利用率更高,本地录制、剪辑首选。
  1. 码率不是越高越好
    超出设备/平台上限后,继续拉高码率画质几乎不会提升,只会白白占用存储空间与网速,按需设置即可。

多角度补充说明

分辨率、帧率固定,码率完全可以自由调节,并不是固定死的

先讲最通俗的比喻,再讲原理,很好懂:

比喻类比(一秒看懂)

把视频比作「固定尺寸的蛋糕」

  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=24896160 bit
  3. 每秒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码率,详细说明

  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标准读取方式)

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]

  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由对齐字节数决定,和画面宽度没有必然相等的关系。
相关推荐
dayuOK63072 小时前
2026年AI生图工具实测:Midjourney、可灵、即梦谁更强?
人工智能·ai作画·aigc·音视频·ai写作
FlightYe2 小时前
FFmpeg移动端硬解机制
linux·网络·ffmpeg·音视频·实时音视频·视频编解码
关于作业的二三事4 小时前
图像和视频处理的核心概念(在新画布上画圆形并保存图像)
音视频
开开心心_Every5 小时前
带OCR识别的电子发票打印工具
运维·自动化·ocr·电脑·powerpoint·音视频·lua
love530love5 小时前
AI Agent + 本地 ComfyUI 无头模式实战:关闭 IDE 后 AI 独立重启并完成图文生成
ide·人工智能·windows·python·音视频·agent·devops
西安老张(AIGC&ComfyUI)1 天前
第021章:ComfyUI文生音频Qwen3-TTS模型数字人音色设计(一)
aigc·音视频·数字人·comfyui
小殊小殊1 天前
一文速通GPU版FFmpeg视频转码的安装使用
ffmpeg·音视频·视频编解码
美狐美颜SDK开放平台1 天前
直播APP平台开发如何降低成本?视频美颜SDK方案解析
人工智能·音视频·美颜sdk·直播美颜sdk·视频美颜sdk·美颜api
luoyayun3611 天前
Qt/QML音视频文件原始十六进制查看器
qt·音视频·十六进制查看