📄 一句话概括
视频就是连续播放的图片,原始尺寸大得吓人——一分钟 1080p 要 10.4 GB,这也是压缩为什么是必需而不是可选。
📝 本节和前面几节的关系
行业背景讲完了,从这一节起进入技术本体。先弄清【视频】这个最基础的概念。
一、视频的本质:一秒钟很多张图
视频不是什么新东西,它就是一串按时间排好序的图片,快速播出来让人眼产生连续感。 这个【连续感】有生理基础:人眼大约在每秒 16 帧以上就会把断续的画面看成动的。 所以视频的三个基本参数是:宽度、高度、帧率——合起来决定它每秒要处理多少像素。
二、帧率:够用就好
电影 24 fps、电视 25/30 fps、游戏 60 fps 以上——不是越高越好,是够用就好。 帧率翻倍,数据量就翻倍,而人眼能分辨的提升却很有限。 选帧率的原则:内容里【动得快不快】决定要不要高帧率,静物访谈 25 fps 完全够。
三、为什么原始视频那么大
算一笔账就明白了:1920 × 1080 个像素,每个像素存 RGB 三个通道各 1 字节。 一帧就是 6.2 MB;30 fps 一秒 186 MB;一分钟 10.4 GB。 一张 100 GB 的硬盘装不下 10 分钟的原始 1080p——这就是压缩存在的全部理由。
四、分辨率、帧率、码率的关系
三个词容易混,分清楚: 分辨率:一帧有多少像素(空间上的密度)。 帧率:一秒多少帧(时间上的密度)。 码率:一秒传多少比特(压缩之后的体积)。 前两个是内容属性,第三个是压缩结果——同样的分辨率和帧率,码率可以差很多。
五、动手 Demo:一分钟 1080p 原始视频有多大
视频在没压缩之前,就是一张张图。先算清它到底多占地方。
W, H, fps, sec = 1920, 1080, 30, 60
per_px = 3 # RGB 三通道
per_frame = W * H * per_px
per_sec = per_frame * fps
per_min = per_sec * sec
print("单帧 = %s 字节" % format(per_frame, ","))
print("一秒 = %s 字节" % format(per_sec, ","))
print("一分钟 = %s 字节 = %.1f GB" % (format(per_min, ","), per_min / 1024.0 ** 3))
实跑输出:
--------------------------------------------------------------------
一分钟 1080p 原始视频有多大
--------------------------------------------------------------------
视频在没压缩之前,就是一张张图。先算清它到底多占地方。
分辨率:1920 x 1080
每像素:3 字节(RGB24)
帧率 :30 fps
时长 :60 秒
单帧 = 1920 x 1080 x 3 = 6,220,800 字节
一秒 = 单帧 x 30 = 186,624,000 字节
一分钟 = 一秒 x 60 = 11,197,440,000 字节 = 10.4 GB
一张 100 GB 的硬盘,只够放 **不到 10 分钟** 的原始 1080p。
这就是为什么【压缩不是优化,是必需】——第 6 章会讲怎么把它压下去。
单帧 6.2 MB、一秒 186 MB、一分钟 10.4 GB。 一张 100 GB 的硬盘只够放不到 10 分钟的原始 1080p——压缩不是优化,是必需。
30 秒实验
- 用手机拍一段 10 秒视频,看文件多大;再跟 Demo 8 算出的理论值比一比。
- 差额就是编码替你省下的——感受一下这个倍数。
常见误区
- 以为视频是什么特殊的数据结构。它就是按顺序排的图片。
- 盲目追高帧率。帧率翻倍数据量就翻倍,人眼却未必分得出来。
- 把码率和分辨率混为一谈。分辨率是内容属性,码率是压缩结果。
自测三问(点开对答案)
1. 视频的本质是什么? —— 按时间顺序排列的连续图片,快速播放产生连续感。 2. 视频的三个基本参数是什么? —— 宽度、高度、帧率。 3. 为什么说压缩是必需的? —— 原始 1080p 一分钟就有 10.4 GB,不压缩根本存不下也传不动。- ☐ 下一节(2.2.2 音频)
相关笔记
- 音频 — 另一半数据
- 音视频编码 — 怎么把这么大的数据压下去
- 🖥️ 服务器工作原理 · 索引 — 数据怎么被处理和存储
- 🎬 FFmpeg入门详解 · 索引