如何选择 RTC 推流的编码格式？

立项时很少人会纠结编码格式，出问题时所有人都会。主播的 iPhone 推流被 CDN 拒收，观众在老旧安卓机上看到花屏，转推录制后视频无法剪辑，这些事故的根源往往是同一个：推流编码格式和接收生态不匹配。编码格式不是纯技术喜好，它决定了画质、带宽成本、设备兼容面和你能接入哪些分发渠道。

先厘清：编码格式到底在选什么

RTC 推流里编码决策其实包含两层。第一层选压缩标准：视频选 H.264、H.265、VP8，音频选 AAC 或 Opus。第二层选编码参数：分辨率、帧率、码率的组合。两层相互关联，标准决定”能不能看”，参数决定”好不好看”。

视频编码格式对比：没有全能的格式

主流的实时视频编码格式有四类，各自的能力边界如下表。

编码格式	压缩效率	端到端兼容面	典型定位	主要代价
H.264	基准	几乎全覆盖：iOS、Android、Web、播放器、CDN、录制均支持	默认选项，业界事实标准	同等画质下码率偏高
H.265	比 H.264 高约 30%-50%	硬件解码普及，但 Web 端依赖新版本浏览器与硬件加速，CDN 转码支持参差	自研 App 端为主的省带宽方案	兼容缺口需要转码兜底，生态支持因服务商而异
VP8	与 H.264 相当	浏览器原生支持好，原生端支持较弱	WebRTC 纯网页互通	原生端与分发生态支持弱
AV1	最高	极不均衡，软编功耗高	未来方向，实时场景尚未普及	实时编码成本过高

这张表的含义是：H.264 是唯一”推出去哪都能收”的格式，也因此成为 RTC 行业的默认推流格式。选择其他格式本质是在用兼容性换带宽，或者为特定生态妥协。以服务端的实际支持为例，即构（ZEGO）等主流厂商的云端混流默认输出 H.264，H.265 与 VP8 作为可选输出，需要开通相应配置后使用，这也侧面说明了一个规律：格式越新，链路里需要打通的环节越多。

音频编码格式：被低估的决策

视频格式有人管，音频格式常常没人管，于是默认值决定了体验。RTC 交互场景建议优先 Opus，它在 20kbps-510kbps 的码率范围内都有稳定表现，对语音的清晰度与抗丢包友好，WebRTC 生态默认支持。需要与 CDN 直播、第三方播放器深度打通时，AAC 的兼容性更保险，许多厂商的直播场景预设会默认 AAC。一个经验法则：交互为主选 Opus，分发为主选 AAC，两者都需要的场景交给服务端的转码去解决。

参数选择：比格式更容易翻车的地方

编码参数选错更隐蔽。业内共识的匹配逻辑是：码率跟着分辨率走，分辨率决定码率下限，帧率决定流畅度上限。360p 配 600kbps、540p 配 1000kbps、720p 配 1500kbps、1080p 配 2000kbps，是直播与 RTC 行业通用的经验档位，各家厂商的默认转码模板基本都落在这个区间，可以作为起步参考。

三个常见误区值得点名：

码率不是越高越好。码率超过画面内容所需的上限后只是浪费带宽，还会挤压上行链路、推高卡顿概率。
1080p 不是默认选项。主播上行带宽有限，多数直播场景 720p 以内的体验与成本比最优，ZEGO 等厂商的 SDK 对普通直播场景默认配置在 540p 左右，恰恰说明主流商业实践不在顶配。
固定参数不如动态策略。真正影响体验的是弱网时的降级顺序，优先保流畅还是保清晰，要在编码策略里显式声明，而不是让网络替你随机决定。