1. 课程导入
WebRTC（Web Real-Time Communication）是一套由浏览器原生支持的实时音视频通信能力集合，它把采集、编码、传输、解码、渲染整条链路封装在统一的 API 之下。开发者只需调用 RTCPeerConnection、getUserMedia 等接口，就能在网页中实现点对点通话、屏幕共享、直播连麦等场景。但“能通”与“通得好”之间，往往隔着编码适配这道关键门槛。本课程聚焦 WebRTC 中 H.264 与 H.265 两种主流视频编码的适配实践，帮助你把实时通信从可用推进到稳定、清晰、低延迟。
一、WebRTC 实时通信架构概览
理解编码适配，首先要看清 WebRTC 的整体数据通路。一次典型的 WebRTC 通话，媒体数据会经历如下环节：
- 采集层：通过摄像头、麦克风或屏幕捕获获得原始音视频帧，通常为 YUV 或 RGB 格式。
- 编码层：将原始帧压缩为 H.264、H.265、VP8、VP9、AV1 等码流，这是本课程的核心战场。
- 封装与传输层：编码后的 NAL 单元被封装为 RTP 包，经 SRTP 加密后通过 ICE/DTLS 建立的通道传输。
- 接收与解码层：对端完成 RTP 重组、抖动缓冲、丢包恢复后送入解码器，还原为可渲染帧。
- 渲染层：通过
<video>标签或 Canvas 呈现画面。
其中，编码层直接决定带宽占用、画质上限和端到端延迟。H.264 与 H.265 作为国际标准编码，在硬件兼容性、压缩效率、专利授权等方面各有取舍，这正是 WebRTC 适配工作需要权衡的重点。
二、H.264 与 H.265 在 WebRTC 中的定位
H.264（AVC）是 WebRTC 事实上的“通用语言”。几乎所有浏览器、移动芯片和硬件编码器都支持 H.264，且其专利池授权模式相对清晰，因此在默认协商中往往优先被选中。H.265（HEVC）则在压缩效率上更进一步，同等画质下码率可降低约 30%～50%，特别适合 4K、高帧率或带宽受限的场景。但 H.265 的浏览器支持并不统一，硬件解码覆盖度也不如 H.264，且专利授权复杂，这导致它在 WebRTC 中更多作为“可选增强”而非默认方案。
两者在 WebRTC 中的定位可以用一句话概括：H.264 保底兼容，H.265 提质增效。实际项目中，通常需要根据终端能力、网络条件和业务画质要求，动态选择或回退编码方案。
三、核心原理：编码适配到底在适配什么
WebRTC 的编码适配并非简单“选一个编码器”，而是贯穿协商、编码、传输、解码全链路的系统工程。核心适配点包括：
- SDP 协商：通过 Offer/Answer 交换
m=video行中的 payload type、rtpmap、fmtp参数，确定双方共同支持的编码及 profile-level-id。 - 能力探测：利用
RTCRtpSender.getCapabilities('video')获取浏览器支持的编码列表，结合MediaCapabilities判断硬件是否支持流畅编码。 - 参数配置：设置码率、帧率、分辨率、关键帧间隔（GOP）、profile（Baseline/Main/High）等，直接影响画质与延迟。
- 传输适配：根据丢包、抖动、带宽估计（REMB/TWCC）动态调整编码码率和分辨率。
- 解码回退：当对端不支持 H.265 时，需能自动回退到 H.264，避免黑屏或协商失败。
关键认知：编码适配的成败，往往不取决于编码算法本身，而取决于协商参数是否匹配、硬件能力是否被正确识别、以及网络波动时能否及时调整。
四、典型场景与适配清单
不同业务场景对编码选择的要求差异明显。下表给出常见场景的适配建议：
| 场景 | 推荐编码 | 关键考量 | 风险点 |
|---|---|---|---|
| 1v1 视频通话 | H.264 Baseline | 兼容性优先，延迟敏感 | 低端设备硬解能力不足 |
| 多人会议 | H.264 Main / H.265 可选 | 带宽汇聚，需 simulcast | H.265 支持不一致导致回退 |
| 4K 屏幕共享 | H.265 Main | 压缩率优先，画质要求高 | 浏览器与硬件解码覆盖有限 |
| 低带宽移动端 | H.264 Baseline | 码率低，抗丢包强 | 画质下降明显 |
| 直播连麦 | H.264 High / H.265 | 画质与带宽平衡 | CDN 与终端解码能力差异 |
五、常见误区与复盘
误区一：认为“支持 H.265 就一定更好”。实际上，若对端硬件不支持 H.265 硬解，软解会带来高 CPU 占用和延迟抖动，反而劣于 H.264。
误区二：忽略 profile-level-id 的匹配。H.264 的 Baseline、Main、High profile 在 SDP 中必须一致，否则协商失败或解码异常。
误区三：只关注编码格式，不关注码率控制。即使编码相同，CBR/VBR、关键帧间隔、初始码率设置不当，也会导致卡顿或花屏。
复盘时建议重点检查三件事：SDP 中实际协商成功的编码是什么、浏览器能力探测结果是否与预期一致、网络波动时码率调整是否生效。这三项往往能定位 80% 以上的编码适配问题。
六、学习目标与整体课程框架
通过本课程，你将掌握以下能力：
- 理解 WebRTC 媒体链路中编码层的职责与上下游关系；
- 掌握 H.264 与 H.265 的关键参数、profile 差异及适用场景；
- 能够通过 SDP 与 API 完成编码协商、能力探测与回退策略；
- 能够配置码率、分辨率、GOP 等参数并评估性能；
- 能够排查协商失败、花屏、卡顿、黑屏等典型编码问题。
课程整体按照“认知 → 原理 → 协商 → 适配 → 调优 → 排障”的主线展开，共 30 章。本章作为导入，帮助你建立全局视角；后续章节将逐步深入到 SDP 字段解析、硬件编解码调用、码率控制算法、多平台兼容性测试等具体实践。建议在学习过程中同步搭建一个可运行的 WebRTC Demo，边学边验证，效果最佳。
// 快速查看浏览器支持的视频编码能力
const caps = RTCRtpSender.getCapabilities('video');
caps.codecs.forEach(c => {
console.log(c.mimeType, c.clockRate, c.sdpFmtpLine || '');
});
// 输出示例：
// video/H264 90000 profile-level-id=42e01f;packetization-mode=1
// video/H265 90000 profile-id=1
// video/VP8 90000