4. H264编码适配基础
在WebRTC中接入H264，并不是“选一个H264编码器”这么简单。浏览器、移动端芯片、SFU媒体服务器之间能否顺利互通，取决于三方是否对同一组H264能力达成一致：使用哪个Profile、哪个Level、哪种打包模式、哪些SDP参数。理解这些约束，是后续H265适配和性能调优的基础。
一、H264 Profile与Level：能力边界的两把尺子
H264标准为了覆盖从视频会议到蓝光播放的广泛场景，定义了大量工具集。Profile（档次）规定“允许使用哪些编码工具”，Level（级别）规定“允许使用多大的码率、分辨率、宏块处理能力”。两者组合，才构成一个可落地的编码能力点。
- Baseline Profile：只使用I帧、P帧，不支持B帧，不支持CABAC，熵编码使用CAVLC。复杂度低、延迟小，适合实时通信。
- Constrained Baseline Profile：在Baseline基础上增加约束，禁止FMO、ASO等不利于RTP打包和错误恢复的工具，是WebRTC中最常见的H264档次。
- Main Profile：支持B帧和CABAC，压缩效率更高，但编码延迟和复杂度上升，在实时RTC中通常不作为首选。
- High Profile：支持8x8变换、量化矩阵等，压缩率最高，多用于点播、直播录制，WebRTC中仅在部分硬件编码器上可选。
Level则用数字表示，如Level 3.0、3.1、4.0、4.2、5.1等。Level越高，允许的最大宏块率、帧率、码率和分辨率越大。例如Level 3.1大致支持720p30，Level 4.2可支持1080p60。WebRTC协商时，如果双方Level不匹配，可能出现“能解码但花屏”“高分辨率下丢帧”等问题。
二、WebRTC支持的H264模式：Packetization Mode是关键
H264码流在RTP中传输时，需要按照RFC 6184进行打包。打包模式（Packetization Mode）决定了NALU如何切分和封装，直接影响MTU适配、丢包恢复和互通性。
- Packetization Mode 0：每个RTP包只能承载一个NALU，且不允许分片。实现简单，但大NALU必须依赖IP分片，丢包时整帧受损，WebRTC中很少使用。
- Packetization Mode 1：允许使用FU-A分片和STAP-A聚合。大NALU可拆成多个RTP包，小NALU可聚合发送，能更好地适配MTU，是WebRTC默认和推荐模式。
- Packetization Mode 2：允许更灵活的NALU顺序和交织，但实现复杂，浏览器和SFU支持不一致，实际部署中基本不采用。
除了打包模式，WebRTC还关注profile-level-id参数。它是一个十六进制字符串，例如42e01f，前两位表示Profile，中间两位表示约束标志，后两位表示Level。接收方通过它判断发送方使用的H264能力，并决定是否接受该媒体流。
a=fmtp:102 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=rtpmap:102 H264/90000其中42e01f对应Constrained Baseline Profile、Level 3.1；level-asymmetry-allowed=1表示允许收发双方使用不同Level，这在移动端与桌面端互通时非常有用。
三、SDP协商关键参数与流程
WebRTC的H264能力通过SDP Offer/Answer交换。发起方在Offer中列出自己支持的H264 payload类型及fmtp参数，应答方选择交集并返回Answer。关键参数包括：
| 参数 | 作用 | 常见取值 |
|---|---|---|
| profile-level-id | 声明Profile与Level | 42e01f、42e01f、4d0032 |
| packetization-mode | RTP打包模式 | 1（推荐）、0 |
| level-asymmetry-allowed | 允许收发Level不同 | 1 |
| max-mbps / max-fs | 限制宏块率和帧尺寸 | 按Level设定 |
| sprop-parameter-sets | 携带SPS/PPS | Base64编码 |
协商流程可以概括为：Offer方按优先级列出H264能力，Answer方逐项匹配，选择双方都支持且优先级最高的组合。若没有交集，H264媒体流将被拒绝，可能回退到VP8或直接失败。
四、典型场景与常见误区
场景一：Chrome与Safari互通。Chrome通常优先使用42e01f，Safari在iOS上对H264支持较好，但可能只接受特定Level。此时level-asymmetry-allowed=1能避免因Level不一致导致协商失败。
场景二：移动端硬编与PC软编互通。移动端硬件编码器可能只支持Constrained Baseline，而PC软编支持High Profile。若Offer中High Profile优先级过高，可能导致移动端无法解码。此时应把Constrained Baseline放在前面。
复盘建议：在SFU或网关中维护一份H264能力表，记录各端支持的profile-level-id和packetization-mode，协商时按“兼容性优先、压缩率其次”的原则排序。对于H265适配，这套“能力声明—交集匹配—参数回退”的思路同样适用，只是参数集和打包方式会更复杂。
掌握H264的Profile、Level、Packetization Mode和SDP参数，是WebRTC视频互通的基本功。只有在能力声明阶段就明确边界，才能在后续的H265适配中少走弯路。