1. 编解码基础：从模拟到数字，我们走了多远

各位同学好，我是这门课的主讲。在正式开始之前，我想先聊聊一个根本问题：视频编解码到底是什么？

说白了，就是把巨大的视频数据「压缩」成小文件，再「解压」回来播放。你想想看，一部4K电影原始数据可能有几个TB，不压缩根本没法存、没法传。我早年做嵌入式开发时，第一次面对未压缩的1080p视频流，那个带宽直接把总线撑爆了——从那以后，我对编解码就有了敬畏心。

编解码技术不是一天建成的。我按时间线梳理了几个里程碑：

1980年代：H.120/H.261 —— 最早的数字视频编码标准。H.261是第一个实用的混合编码标准，引入了运动补偿和DCT变换。说实话，那时候的压缩效率放到今天看，惨不忍睹。
1990年代：MPEG-1/MPEG-2/H.263 —— VCD、DVD、数字电视的基石。MPEG-2至今还在广播电视领域服役。我记得第一次用MPEG-2编码器压DVD，等了整整一个晚上。
2003年：H.264/AVC —— 真正的转折点。压缩效率比MPEG-2提升一倍以上，至今仍是互联网视频的绝对主力。YouTube、Netflix、视频通话，底层都是它。
2013年：H.265/HEVC —— 在H.264基础上再省50%码率。但专利授权问题让它推广受阻，我身边不少团队因为专利费直接放弃了H.265。
2018年至今：AV1 —— 开源、免专利费、压缩率比H.265还高20-30%。Netflix、YouTube、Meta都在推。但编码复杂度极高，软件编码慢到让人抓狂。

核心观点： 每一代新标准都在追求「更小的体积、更好的画质」，但代价是计算复杂度指数级上升。这就是硬件加速登场的根本原因。

这三个标准是目前最主流的。我直接上表格，大家一目了然：

对比维度	H.264/AVC	H.265/HEVC	AV1
发布年份	2003	2013	2018
压缩效率	基准	比H.264省50%码率	比H.265省20-30%码率
编码复杂度	低	中	极高（软件编码慢10倍以上）
专利授权	成熟，需付费	复杂且昂贵	免专利费（开放媒体联盟）
硬件支持	几乎所有设备	中高端设备	较新设备（2020年后）
典型应用	视频通话、直播、蓝光	4K/8K流媒体、UHD Blu-ray	YouTube、Netflix流媒体

这里我想多说一句：压缩效率不是免费的午餐。AV1编码复杂度极高，用CPU软编码4K视频，速度可能只有0.5fps。我曾经在服务器上压一段10分钟的AV1视频，跑了整整6个小时——嗯，从那以后我就坚定地站硬件加速了。

这个问题其实很直接。我分三点来讲：

实时性要求 —— 视频通话、直播、游戏串流，延迟必须控制在毫秒级。纯软件解码在低端设备上根本扛不住。你想想看，手机开个视频通话，CPU全速跑解码，手机烫得能煎鸡蛋，电池半小时见底——这体验能忍？
功耗与散热 —— 专用硬件（ASIC）做编解码，功耗只有CPU的十分之一甚至更低。数据中心里，用GPU或VPU做转码，电费能省一大截。我参与过一个直播平台的项目，从纯CPU转码切换到硬件转码后，服务器数量直接砍掉70%。
解放CPU —— CPU应该去处理业务逻辑、AI推理、渲染这些事，而不是被编解码这种「脏活累活」占满。硬件加速把编解码卸载到专用模块，系统整体吞吐量翻倍。

我的建议： 如果你刚开始接触硬件加速，先从H.264的解码入手。它最成熟、资料最多、调试工具也最完善。H.265和AV1的硬件实现复杂得多，坑也多，后面章节我会逐一拆解。

下面这张图是我自己画的，展示了典型的硬件加速编解码流程：

这张图里，原始视频帧进入硬件编码器，输出压缩码流；解码时反向操作。关键点在于：编码和解码都由专用硬件完成，CPU只负责配置和调度。我在实际项目中见过不少团队把CPU和硬件加速混用，结果调度没做好，性能反而下降——这个坑后面我会专门讲。

我曾经踩过的坑：

分辨率/格式不匹配 —— 硬件加速器通常只支持特定分辨率（如16对齐）和特定色彩格式（如NV12）。你传一个YUV444进去，硬件直接罢工。解决方案：在输入前做格式转换。
驱动版本问题 —— 不同厂商的驱动API差异很大。我遇到过Intel的VAAPI在某个内核版本上解码H.265会花屏，回退驱动版本才解决。建议：锁定驱动版本，不要轻易升级。
多路并发限制 —— 硬件解码器通常有固定的通道数上限（比如4路4K）。超过这个数，要么排队，要么崩溃。设计系统时一定要留余量。

这一章我们走马观花地看了编解码的发展史，对比了H.264、H.265、AV1三个主流标准，也聊了为什么硬件加速是必选项。说白了，没有硬件加速，4K/8K视频、实时通信、云游戏这些都只是纸上谈兵。后面的章节，我会带大家深入硬件加速的底层细节，从API调用到性能调优，一步步把实践能力拉满。