2、RTP头部解析：从比特到音视频流的钥匙
RTP头部，说白了就是音视频数据包的“身份证”。每个字段都承载着关键信息。我刚开始接触WebRTC时，总觉得这些比特位排列很抽象。直到有一次排查丢包问题，盯着Wireshark里的RTP头部看了整整一下午……嗯，从那以后，我再也不敢小看这12个字节了。
今天咱们就把RTP固定头部拆开揉碎，一个字段一个字段地过。你想想看，理解了头部，你就能读懂网络里每一个音视频包的“身世”。
核心要点：RTP固定头部共12字节，每个字段都有明确的职责。理解它们，是调试WebRTC音视频问题的基本功。
2.1 RTP头部结构总览
先看一张整体结构图。我习惯把RTP头部想象成一列火车，每个字段就是一节车厢，各司其职。
2.2 逐字段深度解析
2.2.1 版本号 (V) — 2位
当前RTP版本号固定为2。为什么是2？因为RTP协议从RFC 1889演进到RFC 3550，版本号就从1变成了2。我个人建议，你在解析RTP包时，第一件事就是检查V字段。如果不是2，直接丢弃——这包肯定有问题。
小技巧：Wireshark里过滤RTP包时，可以加上 rtp.version == 2，排除掉那些非标准的流量。
2.2.2 填充位 (P) — 1位
P=1表示RTP包尾部有填充字节。填充字节的最后一个字节表示填充长度。为什么要填充？有些加密算法要求数据块对齐。我在项目中遇到过，某些硬件编码器输出的RTP包会带填充，解析时一定要跳过这些填充字节，否则解码会出错。
注意：填充位为1时，负载数据末尾的填充字节不计入实际音视频数据。解析时务必根据最后一个字节的值跳过填充区域。
2.2.3 扩展位 (X) — 1位
X=1表示RTP头部后面紧跟着一个头部扩展。扩展头部的格式是：
- 2字节：扩展标识（由profile定义）
- 2字节：扩展长度（以4字节为单位）
- 变长：扩展数据
WebRTC中，扩展位用得很多。比如Transport-cc（传输拥塞控制）就通过RTP头部扩展来传递时间戳。我记得有一次调试视频卡顿，发现是扩展头部解析错了，导致拥塞控制算法拿不到正确的反馈信息。
2.2.4 CSRC计数器 (CC) — 4位
CC表示CSRC标识符的数量，取值范围0-15。CSRC是Contributing Source（贡献源）的缩写。在混音场景中，多个参与者混合成一个RTP流，CSRC列表就记录了哪些参与者贡献了数据。
举个例子：一个视频会议中有3个人在说话，混音器生成的RTP包中，CC=3，CSRC列表里就包含这3个人的SSRC。接收端可以根据CSRC列表知道当前包是哪些人的声音混合而成。
2.2.5 标记位 (M) — 1位
标记位的含义由profile定义。在视频流中，M位通常标记一帧的结束。比如H.264编码中，M=1表示当前包是视频帧的最后一个RTP包。音频流中，M位可能标记语音活动的开始。
我建议你在做视频接收端时，利用M位来触发帧渲染。这样可以减少不必要的等待延迟。
2.2.6 负载类型 (PT) — 7位
PT字段告诉接收端，RTP包里的数据是什么编码格式。常见的PT值：
| PT值 | 编码格式 | 说明 |
|---|---|---|
| 0 | PCMU | G.711 μ-law，音频 |
| 8 | PCMA | G.711 A-law，音频 |
| 96 | H.264 | 动态PT，视频 |
| 97 | VP8 | 动态PT，视频 |
| 98 | VP9 | 动态PT，视频 |
| 111 | Opus | 动态PT，音频 |
注意：96-127是动态PT范围，WebRTC中常用的编码格式都落在这个区间。SDP协商时，双方会约定PT值对应的编码参数。
2.2.7 序列号 — 16位
序列号是RTP包的核心标识。发送端每发送一个RTP包，序列号就加1。接收端通过序列号来：
- 检测丢包：如果发现序列号跳变，说明中间有包丢失
- 排序：网络可能乱序，接收端按序列号重排
- 去重：收到重复的序列号，直接丢弃
我曾经遇到过一个诡异的问题：视频花屏，但丢包率很低。排查了半天，发现是发送端序列号重置了——某个中间节点把RTP流重新封装，序列号从0开始，导致接收端以为大量丢包。嗯，这种坑防不胜防。
关键点：序列号是16位无符号整数，范围0-65535。溢出后回绕到0。接收端需要处理回绕逻辑，否则会误判丢包。
2.2.8 时间戳 — 32位
时间戳反映RTP包中第一个字节的采样时刻。注意，它不是绝对时间，而是相对于初始值的增量。时间戳的单位取决于编码格式：
- 音频（如Opus）：48kHz采样率，时间戳单位 = 1/48000秒
- 视频（如H.264）：90kHz时钟，时间戳单位 = 1/90000秒
为什么视频用90kHz？这是历史原因——MPEG标准定的。我个人习惯，在代码里用 uint32_t 存储时间戳，计算差值时注意回绕。
时间戳的作用：
- 播放同步：接收端根据时间戳决定何时播放
- 音视频同步：比较音频和视频的时间戳，调整播放节奏
- 抖动消除：计算网络延迟抖动，用于Jitter Buffer
2.2.9 SSRC — 32位
SSRC（同步源标识符）唯一标识一个RTP流。每个RTP流都有一个独立的SSRC。SSRC是随机生成的，但冲突概率很低（32位空间）。
WebRTC中，每个PeerConnection会为音频和视频分别生成一个SSRC。比如：
- 音频发送流：SSRC = 0x12345678
- 视频发送流：SSRC = 0x9ABCDEF0
接收端通过SSRC区分不同的流。如果两个流SSRC相同，就会发生冲突。WebRTC有冲突检测机制，一旦发现冲突，会重新生成SSRC并发送RTCP BYE。
2.2.10 CSRC — 每个32位，最多15个
CSRC列表只在混音场景中出现。比如一个MCU（多点控制单元）把多个人的音频混合成一个RTP流，CSRC列表就记录了每个贡献者的SSRC。接收端可以知道当前包是哪些人的声音。
在WebRTC的SFU（选择性转发单元）架构中，通常不使用CSRC。因为SFU不混音，只是转发。所以大部分WebRTC场景下，CC=0，CSRC列表为空。
2.3 实战：解析一个RTP包
假设我们从网络上抓到一个RTP包，原始字节如下（十六进制）：
80 60 00 01 00 00 00 02 00 00 00 03
我们来逐字节解析：
| 字节偏移 | 值 | 二进制 | 解析结果 |
|---|---|---|---|
| 0 | 0x80 | 1000 0000 | V=2, P=0, X=0, CC=0 |
| 1 | 0x60 | 0110 0000 | M=0, PT=96 (动态类型) |
| 2-3 | 0x0001 | — | 序列号 = 1 |
| 4-7 | 0x00000002 | — | 时间戳 = 2 |
| 8-11 | 0x00000003 | — | SSRC = 3 |
这个包很简单：版本2，无填充，无扩展，无CSRC，PT=96（可能是H.264或VP8），序列号1，时间戳2，SSRC=3。
实战建议：写代码解析RTP头部时，用位运算提取字段。比如 uint8_t v = (header[0] >> 6) & 0x03; 提取版本号。别用结构体强制转换——不同平台字节序可能不同。
2.4 常见问题与避坑
- 序列号回绕：16位序列号从65535回到0时，接收端要正确处理。我习惯用
uint16_t差值计算，利用无符号整数的回绕特性。 - 时间戳回绕：32位时间戳大约每6.5小时（90kHz时钟）回绕一次。WebRTC会话通常不会那么长，但做录制服务器时要注意。
- SSRC冲突：虽然概率低，但生产环境确实会遇到。接收端要监听RTCP的冲突指示，及时更新SSRC映射。
- 扩展头部解析：X=1时，扩展头部紧跟在固定头部之后。解析时先读2字节标识和2字节长度，再跳过扩展数据。
我曾经在对接一个第三方编码器时，对方把扩展头部长度字段填错了，导致整个RTP包解析偏移。排查了整整两天，最后用Wireshark对比正常包才发现问题。嗯，从那以后，我写RTP解析代码时都会加一层长度校验。
2.5 小结
RTP头部虽然只有12字节，但每个字段都承载着关键信息。版本号、填充位、扩展位、CSRC计数器、标记位、负载类型、序列号、时间戳、SSRC和CSRC——这10个字段构成了RTP协议的基石。理解了它们，你就能读懂网络里每一个音视频包的“身世”。