1、编码基础概念：什么是视频编码？为什么需要编码？编码器与解码器的工作原理
1.1 视频编码到底是个啥？
说白了，视频编码就是把原始视频「压缩」成更小体积的过程。你想想看，一段 1080p、30fps 的原始视频，一秒钟就有将近 150MB 的数据量。要是直接往网上传，别说直播了，连本地播放都费劲。
我刚开始做流媒体那会儿，就吃过这个亏。当时测试一个内部项目，没开编码直接推流，结果带宽直接被打满，服务器差点挂了。嗯，从那以后我才真正意识到——没有编码，流媒体根本玩不转。
核心一句话：视频编码 = 用更少的比特，表达同样的画面内容。
1.2 为什么非编码不可？
我给你算笔账：
| 分辨率 | 帧率 | 色深 | 原始码率（约） | 编码后码率（H.264） |
|---|---|---|---|---|
| 1080p | 30 | 8bit | 1.5 Gbps | 4-8 Mbps |
| 4K | 60 | 10bit | 12 Gbps | 20-40 Mbps |
| 720p | 24 | 8bit | 664 Mbps | 2-4 Mbps |
看到差距了吧？压缩率能达到 200:1 甚至更高。没有编码，你家的千兆宽带连一路 4K 都跑不动。
我个人习惯把编码的必要性总结成三点：
- 节省带宽——直播平台最怕的就是带宽成本，编码直接决定你的 CDN 账单
- 降低存储——录播回放、点播资源，存储空间也是真金白银
- 适配网络——用户手机信号差、WiFi 不稳定，编码后的低码率流才能扛得住
避坑指南：我曾经在一个移动端项目中，为了追求画质把码率设得特别高。结果用户一进电梯就卡死。后来才明白——编码不是越清晰越好，而是要在带宽和画质之间找到平衡点。
1.3 编码器与解码器的工作原理
编码器（Encoder）负责压缩，解码器（Decoder）负责还原。这一对搭档，构成了视频传输的基石。
1.3.1 编码器是怎么工作的？
编码器做的事情，说白了就是「找重复、删冗余」。它主要干掉三种冗余：
- 空间冗余——画面里大片的蓝色天空、纯色背景，没必要逐像素存
- 时间冗余——前后两帧画面变化很小，只记录变化的部分就行
- 视觉冗余——人眼对某些细节不敏感，丢掉一点也无所谓
具体流程我画了张图，你看一眼就明白了：
1.3.2 解码器是反过来跑一遍
解码器做的事情刚好相反：
- 收到码流 → 熵解码 → 反量化 → 反变换 → 重建图像
- 说白了就是「解压缩」，把压缩后的数据还原成可以显示的像素
这里有个坑，我提醒一下：编码器可以很复杂，解码器必须简单高效。因为编码器在服务器端跑，算力充足；解码器在用户手机、电视盒子上跑，性能有限。所以编码标准在设计时，都会把复杂度往编码器倾斜。
注意：解码器必须严格遵循标准规范。我曾经遇到过某个厂商的解码器对 H.264 的某些语法元素解析有 bug，结果特定码流在它家设备上花屏。最后只能靠编码器侧做 workaround——这就是为什么「兼容性测试」在流媒体里特别重要。
1.4 常见的编码标准
目前主流的就是这几家：
| 标准 | 推出时间 | 压缩率提升（相对 MPEG-2） | 典型应用 |
|---|---|---|---|
| H.264 / AVC | 2003 | 2-3 倍 | 直播、点播、视频通话 |
| H.265 / HEVC | 2013 | 4-5 倍 | 4K/8K 视频、HDR |
| AV1 | 2018 | 6-7 倍 | 流媒体平台（Netflix、YouTube） |
| VP9 | 2013 | 3-4 倍 | YouTube、WebRTC |
我个人习惯在项目选型时这么判断：
- 如果兼容性优先（比如面向所有手机用户），选 H.264，稳
- 如果追求极致压缩率（比如 4K 直播），选 H.265，但要考虑专利费
- 如果做开源项目、不想被专利卡脖子，选 AV1，但编码速度慢
1.5 小结一下
视频编码的本质就是「用计算换带宽」。编码器通过预测、变换、量化、熵编码这一套组合拳，把原始视频的体积压缩到原来的几百分之一。解码器再把它还原出来。
你想想看，没有编码的话，我们现在看的抖音、B站、Netflix，全都得卡成幻灯片。所以搞流媒体的人，第一件事就是把编码吃透。后面的章节，我会带你深入每个参数——码率、帧率、GOP、Profile、Level……这些东西怎么调，才能让推流质量最好。