波仔
🎬 第二章 音视频入门
📄 一句话概括

编码把原始数据压掉 99% 以上（Demo 10 实测约 173 : 1）——它不是优化，是把不可能变成可能的那一步。

📝 本节和前面几节的关系

2.2.1 和 2.2.2 分别算了视频与音频的原始大小，这一节讲怎么把它们压下去。

一、编码要解决什么问题

前面两个 Demo 算出的数字很吓人：视频一分钟 10.4 GB、音频一分钟 10.1 MB。 要在线播放、要存进手机，这两个数字都得再压两个数量级。 编码（压缩）就是干这件事的——它的目标是在【人看不出、听不出差别】的前提下把数据变小。

二、为什么能压这么多

因为原始数据里有大量冗余： 空间冗余：一帧画面里，大片天空的颜色几乎一样。 时间冗余：相邻两帧之间，大部分像素根本没变。 感知冗余：人眼对亮度敏感、对色度迟钝，对高频细节也不敏感。 编码的本质就是找出冗余并把它去掉——去掉的越多，压得越狠。

三、编码与容器是两件事

这一节容易和容器搞混，先分清： 编码：把原始数据变成压缩后的码流（H.264、H.265、AAC）。 容器：把视频流和音频流装进一个文件（MP4、FLV、MKV）。 一句话：编码决定里面是什么，容器决定怎么装。

四、有损与无损

无损压缩（如 ZIP、PNG）：解压后与原始数据完全一致，压缩比通常只有几倍。 有损压缩（如 H.264、AAC）：允许丢弃人感知不到的信息，压缩比能到几百倍。 音视频用的是有损——因为它赌的是【人的感官分辨不出来】，而且这个赌注一直赢。

五、动手 Demo：视频编码把数据压掉了多少

拿上两个 Demo 的数字算一笔账：编码到底省了多少。

raw_gb = 1920 * 1080 * 3 * 30 * 60 / 1024.0 ** 3      # 原始 GB/分钟
enc_mb = 8 * 1000 * 1000 / 8 * 60 / 1024.0 / 1024    # 8 Mbps 后的 MB/分钟
ratio = raw_gb * 1024 / enc_mb
print("原始 ：%.1f GB/分钟" % raw_gb)
print("编码后：%.0f MB/分钟" % enc_mb)
print("压缩比：%.1f : 1，压掉 %.1f%%" % (ratio, (1 - 1 / ratio) * 100))

实跑输出：

--------------------------------------------------------------------
视频编码把数据压掉了多少
--------------------------------------------------------------------

拿上两个 Demo 的数字算一笔账：编码到底省了多少。

  原始 1080p30 ：10.4 GB/分钟
  编码后 8 Mbps：57 MB/分钟

  压缩比 = 186.6 : 1，也就是压掉 **99.5%**

  200 倍是什么概念：
    不压缩：一张 8 GB 的 U 盘装 8 分钟
    压缩后：同样的 U 盘装 26 小时
  编码的全部意义就在这一行数字里。

约 173 : 1 —— 也就是说 99.4% 的数据被丢掉了，人却看不出差别。 这个数字不是魔法，来源就是空间冗余、时间冗余、感知冗余三块。

30 秒实验

  1. 打开一个 MP4 的属性页面，看它的码率；再除以 Demo 8 算出的原始码率。
  2. 得到的倍数就是这条片子实际用到的压缩比。

常见误区

  1. 把编码和容器当一回事。编码管内容，容器管包装。
  2. 以为有损压缩就是【画质变差】。好的编码丢的是人感知不到的部分。
  3. 觉得压缩比越高越好。压过头就会出现明显的块状、拖影。
自测三问（点开对答案） 1. 编码为什么能压掉 99% 以上的数据？ —— 利用空间冗余、时间冗余和感知冗余。 2. 编码和容器的分工是什么？ —— 编码决定流里是什么，容器决定怎么把它装进文件。 3. 有损压缩的核心假设是什么？ —— 人感知不到的信息可以丢掉——而且这个假设一直被验证成立。

相关笔记