音视频基础概念：采样率、比特率、编码格式、封装格式与色彩空间
各位同学，欢迎来到第二章。说实话，音视频开发这个领域，门槛其实不在代码本身，而在于这些基础概念。你想想看，如果连采样率和比特率都搞不清楚，后面写编码器、调推流参数的时候，肯定会一头雾水。
我个人习惯，在开始任何音视频项目之前，先把这些基础概念过一遍。就像盖房子要先看地基一样，这些概念就是你音视频知识体系的基石。今天我们就来把这些东西彻底讲明白。
2.1 采样率：声音的“像素”
先说说采样率。这个概念其实很简单——它决定了声音的“细腻程度”。
模拟声音是连续的波形，但计算机只能处理离散的数据。采样率就是每秒钟从连续信号中提取多少个样本点。单位是 Hz（赫兹）。
核心公式：采样率 = 每秒采集的样本点数
常见值：8000Hz（电话）、44100Hz（CD音质）、48000Hz（专业音频/视频）
我在项目中遇到过一个问题：客户提供的音频文件采样率是 22050Hz，但我们的播放器只支持 44100Hz。结果播放出来声音变调了，像开了慢速播放一样。嗯，这就是采样率不匹配的典型问题。
奈奎斯特采样定理告诉我们：采样率必须大于信号最高频率的两倍，才能无失真地重建原始信号。人耳能听到的频率范围大约是 20Hz-20kHz，所以 CD 音质的 44100Hz 刚好覆盖这个范围。
避坑指南：我曾经在做一个语音识别项目时，为了省带宽把采样率降到了 8000Hz。结果识别率暴跌。后来才发现，8000Hz 只能覆盖 0-4kHz 的频率范围，很多辅音的细节都丢失了。所以，语音识别至少要用 16000Hz。
2.2 比特率：数据量的“阀门”
比特率，说白了就是每秒钟传输或处理的数据量。单位是 bps（bit per second）。
对于音频来说：
- 未压缩音频的比特率 = 采样率 × 位深度 × 声道数
- 例如：44100Hz × 16bit × 2声道 = 1,411,200 bps ≈ 1.4 Mbps
对于视频来说，比特率就复杂多了。它取决于分辨率、帧率、编码效率、画面复杂度等多个因素。
| 应用场景 | 推荐视频比特率 | 推荐音频比特率 |
|---|---|---|
| 1080p 直播 | 3-6 Mbps | 128-192 Kbps |
| 720p 点播 | 1.5-4 Mbps | 96-128 Kbps |
| 4K 视频 | 15-40 Mbps | 192-320 Kbps |
我个人习惯，在编码时使用 VBR（可变比特率）而不是 CBR（固定比特率）。VBR 能在画面静止时节省码率，在复杂场景时分配更多码率，整体画质更好。但要注意，直播场景下 CBR 更稳定，因为带宽波动会影响推流质量。
2.3 编码格式：H.264 与 AAC
编码格式，说白了就是压缩算法。原始音视频数据太大了，不压缩根本没法存、没法传。
H.264（AVC）——视频编码的“老黄牛”
H.264 是目前最广泛使用的视频编码标准。它发布于 2003 年，但到现在依然是主流。为什么？因为它做到了很好的平衡——压缩率高、兼容性好、硬件支持广泛。
H.264 的核心技术包括：
- 帧内预测：利用空间冗余，减少单帧内的数据量
- 帧间预测：利用时间冗余，只编码帧之间的差异
- 变换编码：DCT 变换 + 量化，去除人眼不敏感的高频信息
- 熵编码：CABAC 或 CAVLC，进一步压缩
H.264 的 Profile 和 Level：
- Baseline Profile：低延迟，适合视频通话
- Main Profile：平衡，适合广播
- High Profile：高压缩率，适合蓝光、流媒体
Level 则限制了分辨率、帧率、码率的上限。比如 Level 4.0 支持 1080p@30fps。
我在项目中遇到过一个问题：用 H.264 High Profile 编码的视频，在旧款手机上无法解码。后来查资料才发现，那些手机只支持 Baseline Profile。所以，做跨平台产品时，Profile 的选择要谨慎。
AAC——音频编码的“标准答案”
AAC（Advanced Audio Coding）是 MPEG-2/4 标准中定义的音频编码格式。它比 MP3 的压缩效率更高，同等码率下音质更好。
AAC 的常见变体：
- AAC-LC：低复杂度，最常用
- AAC-HE：高效编码，适合低码率场景
- AAC-HEv2：在 HE 基础上加入参数立体声，码率可以低到 32Kbps
避坑指南：我曾经在做一个直播项目时，用了 AAC-HEv2 编码音频，结果在部分 Android 手机上播放出来只有单声道。后来才发现，那些手机的音频解码器不支持参数立体声。所以，兼容性优先的话，用 AAC-LC 最稳妥。
2.4 封装格式：MP4 与 FLV
封装格式，说白了就是容器。它把视频流、音频流、字幕、元数据等打包在一起。就像快递盒子，里面装什么都可以，但盒子的规格决定了你能装什么、怎么装。
| 特性 | MP4 | FLV |
|---|---|---|
| 容器类型 | 基于 ISO Base Media File Format | Adobe Flash 专用格式 |
| 支持的编码 | H.264, H.265, AAC, MP3 等 | H.264, AAC, MP3 等 |
| 流式传输 | 支持（需 moov box 前置） | 天生支持 |
| 元数据 | 丰富（封面、章节、字幕） | 有限 |
| 浏览器支持 | 广泛（HTML5 原生） | 需 Flash 插件（已淘汰） |
MP4 是目前最通用的封装格式。但要注意一个坑：MP4 的元数据（moov box）默认放在文件末尾。这意味着播放器需要下载完整个文件才能开始播放。解决办法是在编码时使用 -movflags +faststart 参数，把 moov box 移到文件头部。
FLV 虽然已经过时了，但在直播领域依然有它的位置。RTMP 协议传输的就是 FLV 格式的数据。我做过一个直播项目，推流端用 RTMP 发送 FLV 数据，播放端用 flv.js 解析播放。嗯，这套方案在低延迟场景下还是很稳的。
2.5 YUV 与 RGB 色彩空间
色彩空间，说白了就是描述颜色的数学模型。RGB 和 YUV 是两种最常见的色彩空间。
RGB：人眼感知的“原始语言”
RGB 用红、绿、蓝三个分量来表示颜色。每个分量通常用 8bit（0-255）表示。所以一个像素需要 24bit 存储。
RGB 适合显示设备，因为显示器就是通过红绿蓝三色发光来显示图像的。但 RGB 不适合压缩，因为三个分量的相关性很强，而且人眼对亮度更敏感，对色度不那么敏感。
YUV：视频压缩的“秘密武器”
YUV 把颜色分成亮度（Y）和色度（U、V）两部分。人眼对亮度敏感，对色度不敏感。所以我们可以对色度进行下采样，减少数据量。
常见的 YUV 采样格式：
- YUV444：每个像素都有完整的 Y、U、V 分量，无压缩
- YUV422：每两个像素共享一组 UV，数据量减少 1/3
- YUV420：每四个像素共享一组 UV，数据量减少 1/2，最常用
YUV420 的内存布局：
// 假设图像宽 w，高 h
// Y 平面：w * h 字节
// U 平面：w/2 * h/2 字节
// V 平面：w/2 * h/2 字节
// 总大小 = w * h * 1.5 字节我在项目中遇到过一个问题：从摄像头采集到的数据是 NV12 格式（一种 YUV420 的变体），但编码器要求的是 I420 格式。两者的 UV 排列顺序不同。如果不做转换，编码出来的视频颜色会完全错乱。这个坑我踩过一次，后来写了个转换函数，再也没出过问题。
YUV 与 RGB 的转换
转换公式其实不复杂，但要注意标准。BT.601 是标清标准，BT.709 是高清标准，BT.2020 是超高清标准。不同标准的转换系数不同。
// YUV 转 RGB（BT.601 标准）
R = Y + 1.402 * (V - 128)
G = Y - 0.344 * (U - 128) - 0.714 * (V - 128)
B = Y + 1.772 * (U - 128)
// 注意：结果需要 clamp 到 [0, 255] 范围警告：YUV 和 RGB 转换时，如果使用浮点运算，效率会很低。实际项目中，建议使用查表法或整数运算。我曾经用浮点运算做实时转换，结果 1080p 视频只能跑到 15fps。换成整数查表后，直接跑满 30fps。
知识体系总览
下面这张图，把本章的核心概念串起来了。你可以把它当作一张“地图”，以后遇到具体问题时，回来看看这张图，就能快速定位问题出在哪个环节。
好了，这一章的内容就到这里。采样率、比特率、编码格式、封装格式、色彩空间——这些概念你搞清楚了，后面学编码器参数调优、推流协议、播放器开发的时候，就会轻松很多。
记住一句话：音视频开发，基础不牢，地动山摇。别急着写代码，先把这些概念吃透。