4. 主流音频Codec概览

做音视频开发这些年，我见过太多团队在Codec选型上栽跟头。有人为了省带宽，硬上H.265做实时通话，结果延迟高到没法用。也有人图省事，直播全用H.264，码率浪费得心疼。

说白了，没有万能的Codec。直播、点播、实时通信，这三个场景对编码器的要求完全不同。你想想看，直播要低延迟，点播要压缩率，实时通信既要低延迟又要抗丢包——怎么可能一个编码器通吃？

这一章，我就带你走一遍选型的决策树。咱们从业务场景出发，一步步推导出最适合的Codec。

4.1 三个核心场景的底层差异

先搞清楚一件事：为什么场景不同，Codec的选择就不同？

我习惯从三个维度来拆解：延迟容忍度、码率约束、终端覆盖。

场景	延迟容忍度	码率约束	终端覆盖要求	典型Codec
直播	3-10秒（可接受）	中等，可动态调整	高（PC、手机、电视）	H.264 / H.265 / AV1
点播	无实时要求	宽松，可做多码率	极高（全平台）	H.265 / AV1 / VP9
实时通信	< 400ms（硬性要求）	严格，受网络波动影响	高（WebRTC生态）	VP8 / H.264 / AV1

嗯，这里要注意：延迟容忍度是硬门槛。实时通信如果延迟超过400ms，用户就会明显感觉到卡顿和不同步。我在项目中遇到过客户坚持用H.265做视频会议，结果编码耗时直接飙到80ms，加上网络传输，延迟直奔500ms+，最后不得不切回H.264。

4.2 决策树：从业务需求到Codec选择

下面这张图是我自己总结的选型决策树。每次做新项目，我都会先走一遍这个流程。

走完决策树，你大概能锁定2-3个候选Codec。接下来，咱们逐个场景拆解。

4.3 实时通信场景：VP8 vs H.264 vs AV1

实时通信是我踩坑最多的领域。延迟是红线，超过400ms用户就跑了。

H.264：硬件编码支持最广，几乎所有手机和电脑都有硬编硬解。延迟可以做到50ms以内。缺点是压缩率一般，同等画质下码率比H.265高30%左右。

VP8：WebRTC的默认选择。我早期做视频会议时，VP8在弱网下的表现让我印象深刻。它的抗丢包机制比H.264更灵活，但画质上限不如H.264。

AV1：压缩率确实牛，但编码复杂度太高。软件编码在手机上跑不动，硬件编码还没普及。目前只适合做服务端转码，不适合端到端实时通信。

4.4 直播场景：H.264还是H.265？

直播的延迟容忍度比实时通信宽松得多，3-10秒都算正常。这时候，压缩率就成了关键指标。

我做过一个对比测试：同样1080p 30fps的视频，H.264需要4Mbps才能达到的清晰度，H.265只要2.5Mbps。对于带宽成本敏感的平台，这个差距就是真金白银。

但问题来了：H.265的专利授权是个坑。我记得2018年帮一家直播平台做选型，因为H.265的专利费问题，最后不得不放弃。后来他们选了AV1，但编码速度又成了瓶颈。

4.5 点播场景：压缩率至上

点播没有实时压力，可以慢慢编码。这时候，压缩率就是王道。

我习惯按这个优先级选型：

1. AV1：压缩率最高，比H.265再省30%码率。适合存储成本敏感的场景。
2. H.265：压缩率优秀，硬件支持比AV1好。适合主流点播平台。
3. VP9：YouTube在用，压缩率介于H.265和AV1之间。适合不想碰专利费的项目。

嗯，这里要注意：点播场景一定要做多码率自适应。我见过有人只压一个4Mbps的H.265流，结果用户在2G网络下根本播不了。多码率+自适应切换，才是点播的正确姿势。

4.6 选型检查清单

每次做选型，我都会过一遍这个清单。你可以直接拿来用。

检查项	说明	优先级
延迟要求	实时通信 < 400ms，直播 < 10s，点播无要求	高
终端覆盖	目标用户的设备是否支持硬编硬解	高
带宽成本	同等画质下，码率越低越好	中
专利授权	H.265/AV1有专利池，VP9/AV1开源	中
编码复杂度	软件编码还是硬件编码？服务器能否扛住	低